实战攻略：如何从0到1构建 CMDB？

作者 | 刘冰

来源 | AIOps 智能运维（ID：AI_Ops）

服务管理在应用程序管理层面支持监控、部署多个运维平台，在运维过程中起到了重要的枢纽作用。 除了应用程序管理以外，运维还需要包括机器、交换机、路由器等设备类的管理，而这些实际上都属于运维 CMDB（配置管理数据库）的范畴。 接下来我们会从业务场景展开说明构建完整的 CMDB 的流程。

如何构建 CMDB  

一个业务系统在发展初期，可能只需要一台或几台机器，只需要很少的运维人员，日常工作也只需关注机器是否死机、网络是否畅通、服务是否存活，运维场景比较简单。随着业务的发展，规模持续增长，运维场景变得越来越复杂，比 如部署变更过程中需要分级发布，监控管理需要多维度业务监控，业务需要容量规划，故障止损和诊断等等。应对大规模设备和服务运维，如何对各类运维资源进行高效的组织管理，并结合各类运维平台 提升运维效率 是CMDB的核心价值所在。

CMDB是配置管理的缩写，常常被认为是构建其他ITIL（IT基础架构库）流程的基础，承担着数据整合、同步、可视化这几个关键功能。运维CMDB的构建通常需经历以下3个步骤：

1. 资源管理模型抽象：运维对象涉及机房、机器、网络设备、应用程序等多种资源对象，如何对这些运维资源进行抽象和建模以支持更多运维场景？

2. 资源数据整合同步：运维资源需要经历复杂的流程和生命周期来支撑整个运维工作，例如一台机器从预算申请到采购入库，再到上架、部署服务，进行业务监控，整个流程会涉及资产、部署、监控等多个运维平台，如何对资源数据进行整合以提升运维效率并保证数据的一致性和准确性？

3. 支撑上层业务运维：运维CMDB建设好之后并不等于结束，相反，这只是开始，数据一定要有价值/场景消费导向，才能为业务发挥更大的作用，例如在数据可视化方面，自动化、智能化运维方面、数据化运营方面等等，CMDB应该怎样支撑上层业务运维以使资源数据的价值达到最大化呢？

下面我们分别进行阐述。

资源管理模型  

首先运维的对象分两大类，一类是基础设施，包括机房、机架、服务器、网络设备、安全设备等，另一类是构建在基础设施之上的服务，包括应用程序、中间件、域名等等。资源管理模型主要分两部分，一部分是各类型资源的抽象建模和关联关系，另一部分是资源之间的组织管理，下面我们分别进行解释：

资源抽象模型  

以机器运维为例，其生命周期如下图所示：

由以上流程可知，机器资源有以下几类信息：

1. 基本属性信息，如：SN、厂商、型号等硬件信息，生产日期、保修期等维保信息；

2. 配置信息，如：安装的操作系统、分配的IP地址等；

3. 运行时状态信息，如：机器运行状态、资源利用率等。

再来看下业务运维，典型的一个应用生命周期如下图所示：

由以上流程可知，一个业务资源同样有以下几类信息：

1. 基本属性信息，如：服务名、服务描述信息、负责人、维护人等；

2. 配置信息，如：部署版本、部署路径、启动参数、开放端口等；

3. 运行时状态信息，如：服务运行状态、资源使用率等。

通过以上分析，我们发现无论基础物理设施资源还是服务、域名等虚拟资源，基本都包含以下3类信息：

1. 基本属性属性：用来对资源进行描述；

2. 配置信息：用来表示对资源使用的方式；

3. 运行时状态信息：表示资源当前的状态。

其实除了以上信息，还有一类重要的信息是资源之间的关联关系，也可叫做资源知识图谱，例如：一个对外提供Web服务的业务会使用一个域名资源，会依赖一个MySQL数据库服务，会部署在一组机器上，机器安装在机房，并且连接了某些网络设备，如下图所示：

以上只是一个简单示例，完整的资源知识图谱比以上要复杂的多，可以提供更加丰富的关系数据，给运维带来更大的价值。但是通常我们需要的只是某个层面的 拓扑结构（视图）。例如：机器、交换机等组成的网络拓扑主要用在网络运维上，服务之间的上下游调用关系拓扑主要用在业务运维上，可以帮助进行故障诊断等。

最终我们可以得到完整的资源管理模型如下图所示：

资源组织管理  

有了以上资源管理模型，我们更多还是从组织和人的角度来对资源进行分类组织管理，以提升日常运维的效率。一般在大中型企业，对于机房、机器、网络等会有专门的系统部进行统一运维，对于业务系统会有专门的运维部SRE进行运维，因此基于运维模式我们将资源分为基础设施资源和业务资源2大类进行组织管理：

1. 基础设施资源：同样拿机器运维来举例，对于故障维修场景，我们需要对机器按厂商进行分类管理，对于硬件监控场景，我们需要对一批支持相同采集协议的服务器批量配置监控，因此机器需要进行不同维度的分组管理。

2. 业务资源：通常会复杂一些，对于一个业务系统，可能会包含大量应用程序，多个应用程序还可能组成业务子系统。业务监控通常以模块为配置单元，生效在模块下所有实例上，业务部署却不一样，可能按照环境不同分集群部署，也可能按照机房粒度分级发布，或者按照用户分类进行A/B测试，这实际对应了不同运维场景对不同资源视图的管理需求。

最后无论基础设施资源还是业务资源，都会有资源隔离需求，例如一个业务系统需要独占一批机器资源，避免其他业务系统抢占资源导致服务性能下降。这实际是分租户进行资源隔离的需求。我们根据百度内网多年的运维经验，以业务为核心，针对机器等设备管理场景和业务服务管理场景，抽象出设备树+业务树形式的资源组织管理模型，具体如下图所示：

租户：用来进行资源隔离，租户内包含多种运维资源，也可以称作是资源的命名空间。

设备树：对各类物理设备进行组织管理。

• 设备：交换机、路由器、防火墙、服务器等物理设备的统称。可对应上面资源建模里面的各类物理设备模型。

• 设备组：根据运维需求划分出来的若干设备的集合，如机器运维人员可以按照机器型号划分机器，网络运维人员可以按照类型对网络设备进行分组等。

业务树：对各类业务资源进行组织管理。

• 实例：实例是部署和监控的最小单元，实例上可以打Tag组合成服务满足灵活的管理需求。例如业务监控场景会对同机房的实例数据进行汇聚，业务部署场景会根据测试环境、生成环境分别进行部署升级等。

• 应用：应用是一类提供相同服务实例的集合，概念上和日常所说的模块概念类似，例如一个Web应用。

• 服务：服务是由一组具有相同维度组合实例的集合，由Tag Selector决定，代表应用的某个维度视图，例如按集群划分为开发环境集群、测试环境集群、生产环境集群；按机房分为南京机房、上海机房；按版本分为V1、V2、V3等等。

• 子系统：对于大的业务系统，可能会部署很多应用模块，子系统是应用的分组，方便进行组织和管理。

有了以上资源抽象模型和组织管理方法，我们以某中型电商类公司运维为例简要实际说明以下资源组织管理的方式。假设公司分系统部和运维部两个部门，系统部负责机器运维和网络运维，运维部负责业务运维。

• 系统部运维人员职责：机器运维分厂商监控全公司机器，确保机器处于正常运转状态，网络运维保障所有网络设备处于正常工作状态。

• 运维部运维人员职责：业务运维负责网上商城系统业务的变更管理、监控管理、容量规划和故障管理，并且为了安全性希望对不同的应用设置不同人员管理，对应的资源管理模型如下图所示：

资源数据整合  

有了资源组织管理的方式，下面就要考虑资源数据的维护，通常情况下我们采用人工+流程+自动发现三种方式进行资源数据的维护：

人工维护  

对于资源的基本信息数据维护通常会使用人工维护的方式，例如业务模块的命名和组织管理方式只能人工自行定义，好在这部分数据的维护成本较低，一次性创建且后续变动较小。且这部分资源数据只会在CMDB中定义和维护。

流程规范  

运维离不开人的参与，有人参与的活动都难免出现各种差错，所以对于资源的配置属性通常需要流程的严格定义，例如：机器上下架、改名、重装、网络规划等等，通过标准化的流程，配置信息数据在多个平台之间流动对接，保证了数据的一致性和准确性。

自动注册 / 自动发现  

对于资源的状态属性通常有监控系统自动更新，部分配置属性，例如机器运行的系统环境变量等信息也可由监控系统自动采集上报；服务关系拓扑可由RPC（远程过程调用协议）间的调用关系链进行自动更新；网络拓扑可以通过网络设备的自动发现机制进行自动更新等等。自动注册/发现机制提升了数据管理的效率，也避免了人工干预造成的数据不一致或准确性问题。

CMDB 支持上层业务运维  

最后我们再来简单聊下运维CMDB如何支持上层业务运维。运维CMDB模型和数据构建完成之后，重要的还在于场景的联动和数据的消费，例如：

• 业务全景图：在可视化场景为运维人员提供业务拓扑、业务树、网络拓扑等组织管理形式，方便运维人员对整个业务系统运行状态和部署架构全局一览，清晰便捷。

• 运维场景联动：构建自动化运维流程，打造业务联动场景，如：在业务升级部署前自动屏蔽报警，升级完成后解屏蔽报警，实现自动化服务部署升级和监控进行联动等。

• 智能化运维：根据服务拓扑和变更历史记录进行辅助故障诊断、根因定位。例如某个应用故障时查询依赖的关联服务是否有故障；如果某个应用的故障实例集中在某个机房，则可以进一步定位该机房的其他服务是否有变更等。

• 数据化运营：支持服务容量规划、成本核算、业务运营分析。例如根据上下游服务调用量分析，监控系统可提供服务整体资源利用率数据和分业务使用量分析数据等。

CMDB通过提供各种类型查询API来支持各种业务可视化和分析场景，通过数据变更API和灵活的变更通知机制实现了自动化场景联动，最终支撑了上层业务运维。

   总结     

本文从业务分析角度说明了运维CMDB的构建流程，先从业务场景出发进行资源抽象和建模，然后通过一系列的运维流程和规范加上自动注册/发现机制进行高效数据整合，最后通过挖掘各种运维场景的联动支持了上层业务运维的不断发展，体现了CMDB的价值。

限于篇幅，这里介绍的只是CMDB的一些基础功能，运维CMDB系统的构建是个持续迭代的过程，只要始终坚持以业务场景为出发点进行不断改进和扩展，CMDB一定能在运维中发挥巨大的价值。本文抛砖引玉，欢迎各位提出宝贵意见，谢谢。

作者介绍

刘冰，百度资深研发工程师，负责百度智能运维产品（Noah）的 CMDB、监控系统相关的设计研发工作，在平台架构、监控业务分析等方面有大量实践经验。

---

活动推荐

月活用户7.55亿，阿里淘系如何在后流量时代引爆用户增长？10月18日（周五）晚18:30-21:00，QCon上海特色技术晚场阿里“淘系技术嘉年华——用户增长突围之夜”，四位来自阿里巴巴的高级技术专家将与你“零距离”沟通，深度探讨用户增长的那些事儿。点击文末阅读原文或者识别下方二维码即可免费参加，晚场活动席位有限，以后续审核通知为准。