巧妙的CMDB设计，减少告警对运维的轰炸

本文主要介绍运维CMDB的设计思路，恰当的CMDB设计，对运维效率的提升，如收敛告警和故障自愈等，有着意向不到的效果。

在运维自动化平台的设计理念中，我们一直提倡“减少运维对象”，并将运维对象进行抽象化、模型化、配置化的录入CMDB中管理，进而让运维工具有途径消费CMDB中的数据，让运维自动化流程能够通过接口维护CMDB中，各个运维对象的属性与状态，这是构建自动化运维体系的配置基础。

那么CMDB主要记录怎样的内容，在织云面向业务架构的CMDB实践中，将CMDB的配置数据主要分为几类（更多配置需求可扩展）：

• 业务对象：业务树、架构层等
• 硬件对象：主机、网络设备等
• 应用对象：软件包、配置文件、脚本等
• 自定义对象：变更信息、密码库等

每种运维对象都包含其各自的属性和状态配置，如：

• 业务树：业务层级关系、负责人、重要级别等
• 主机：IP地址、主机名、操作系统、上联交换机端口等
• 软件包：版本、部署实例、进程、端口、清理策略等
• 变更信息：时间、IP、操作内容、操作人员等

运维对象与运维对象之间需要建立规则或关系，如下图：

言归正传，CMDB的设计与告警收敛和故障自愈有什么联系呢？让我们一起对运维常遇到的基础告警做一些问题归类：

• 容量告警：CPU、流量指标告警等
• 进程端口告警：进程不存在、僵尸进程等
• Ping、死机告警：ping探测、agent上报超时等
• 硬盘告警：硬盘容量满、硬盘只读等

该面向业务架构设计的CMDB系统发挥功效的时候了，让我们一起看一个简单的示例：

承载着运维标准化规则的CMDB，每个字段都包含着一定的运维管理逻辑与自动化处理的能力，如：

• 架构层：逻辑SPP意味着是标准开发框架，是标准化的服务，有框架自带的监控数据。
• 运营状态：运营中意味着需要正常告警，此字段还有故障中、测试中、待申请等状态，可对应不同的运维工作操作。
• 负责人：大梁为该业务运维负责人，该业务下的设备自动继承负责人信息。
• 软件包：ngnix-1.9表示软件的版本，可扩展到安装路径、启停操作等等。
• 端口：此字段信息可用户端口监控，可结合部署检测、故障自愈等运维操作。
• IP集群：该业务模块部署的IP地址，可基于CMDB的配置信息，可基于规则实
• 自动巡检、故障自愈、架构规划、容量一致性等标准化运维管理的功能。

织云构建的体系化运维能力，在大量的基础告警爆发时，基于运维规则与CMDB的配置记录，我们将会得到如下场景的运维自动化能力：n容量去阈值：将IP集群的容量，按业务的纬度收敛成为单指标，metis单KPI智能精准分析，无需阈值管理。

• 指标预测：每小时指标增长斜率的告警，去阈值的一种实现。
• 容量一致性：IP集群的容量如不一致，则视为异常，在日常运维工作需主动修复中。
• 故障精准通知：无需维护IP负责人，准确将告警推送给业务运维负责人。
• 进程/端口告警自愈：主动ps检测，发现进程/端口不存在，结合软件包规则自动拉起，修复该故障。
• Ping/死机告警自愈：结合CMDB的架构层和运营状态的信息，对无状态服务自动调用负载均衡接口踢出该主机，自动重启主机，修复问题后，重新加入负载均衡服务。
• 硬盘告警自愈：结合主机数据/日志管理规则，举一反三的将硬盘容量告警的清理策略自动执行，针对硬盘只读的告警可自动执行重启操作。
• 主动巡检：基于CMDB的配置信息，如软件包版本、各IP的负载容量、运行进程端口等信息，定制主动巡检的运维工具，每天生成报表，让运维防火成为日常例行工作，减少因生成环境不一致火灾抢险的发生几率。

正如上述简单的CMDB案例所达到的运维能力，对告警收敛和故障自愈的效果是显著的。在此，笔者希传递CMDB的设计思路：

• CMDB是运维体系的基础数据配置中心，在运维平台的架构地位很关键
• CMDB避免大而全的设计，记录有限的信息就能帮上大忙，从小做起
• 自动发现并非万能的，运维对象的管理需要双管齐下
• CMDB中对象的管理关键在于保证信息的准确与生产的一致性
• CMDB要提供统一的接口服务，利用自动化的工具或流程来维护配置信息
• 不要拘泥于唯一的或形式上的CMDB，只要表结构扩展，配置数据就能被持续利用
• 泛CMDB的概念能助你更好的理解CMDB和落地CMDB

简单的CMDB设计不仅可承载大量的运维标准化规则，在腾讯织云的运维实践经验中，对CMDB中的数据加以利用，更能在AIOps时代发挥更大的威力。

从运维技术转型到运维产品经理，让我有机会从一个全新的角度来看待和总结过去做过的运维系统。在和很多企业客户沟通时，我发现了一个典型的问题，传统的运维思路总习惯于“头痛治头脚痛治脚”。回顾近10年在腾讯的运维技术实践中，腾讯织云运维体系的建成，是有意或无意的由业务运维主导进化而来的，下次有机会再深入和大家探讨CMDB在更多运维场景的实践。