作者介绍

彭华盛，《运维数字化转型：构建四位一体的数字化运维体系》《运维数据治理》等书、“运维之路”订阅号作者。

CMDB（Configuration Management Database，配置管理数据库）比较被认可的定义为：存储与管理企业IT架构中生产对象的各种配置信息。CMDB通过识别、控制、维护，检查企业的IT资源，可以在线控制与管理不断变化的IT基础架构与IT服务，为事故管理、问题管理、变更管理、发布管理等流程提供准确的配置信息。CMDB与所有服务支持、服务交付流程紧密相连，配置数据让分散独立的流程能够互联互通。依赖于各类流程的配置消费，也让CMDB配置数据由“死”数据“活”起来，提升配置数据准确性。

一、CMDB 四步走

从运维体系看，CMDB是运维数字世界的数字地图。运维组织规模小时，运维流程与协同可以通过线下沟通解决。随着内外部环境复杂度越来越高，线下协同方式无法适应当前面临的挑战。运维数字世界的构建就是为了应对人员数量、系统数量、主机数量、服务数量、数据量越来越大，架构链路与沟通关系越来越复杂的挑战。从运维平台架构看，CMDB承担了描述运维对象的职能，CMDB是IT资源（设备、组件、系统）及其关系的数学抽象，是IT资源的“高德地图”，是IT运维及IT运营的数字基石，是运维工作展开的底层支撑。分析CMDB，首先从行业CMDB发展看看CMDB（见图23-1），大体可以梳理4段过程。

图23-1 CMDB发展四阶段

CMDB1.0实现IT资源的电子化管理。2001年，CMDB出现在ITIL V2.0中，并定义：配置管理数据库，是与IT系统所有组件相关的信息库，它包含IT基础架构配置项的详细信息。CMDB的发展与运维的发展息息相关，运维组织从手工操作式运维，向平台运维、IT运营的方式演进，CMDB也伴随着运维组织演进。2001年到2008年，出现了以配置信息电子化为特征的CMDB1.0。随着以BMC、IBM、CA、HP为代表的Big4传统软件巨头在自家ITSM相关产品中推出第一代CMDB管理的产品和解决方案，CMDB逐渐在国内得到应用及实施。然而，由于企业对CMDB理解不深及技术局限，CMDB沦为侧重于配置（资产）管理和数据查询的工具，注重配置信息的电子化，往往表现为设备台账、清单、报表代替原来电子表格管理配置的过程。这阶段，CMDB已经管理了运维组织涉及的各种对象，包括：从生产环境涉及的基础设施、平台软件、应用系统 、以及IT运营管理涉及角色、人员、所属组织等。

CMDB2.0促进技术平台化管理互通。2008年前后，以银行、运营商为代表的企业开始侧重于CMDB与其他流程的协同以及故障、变更影响分析等诊断场景，由于场景驱动推动CMDB配置数据范围扩展，出现了以数据管理闭环为特征的CMDB2.0。由于场景与实际运维工作息息相关，需要保证配置数据的准确性与配置保鲜，驱动了配置自动化发现技术的发展，与配置流程管理的建设。所以，在这个阶段，CMDB重点围绕标准化、数据建模、配置自发现、配置流程整合、配置数据运营等方式建设。这阶段，CMDB理念开始深入人心，运维领域不同条线都有意识的建设配置管理，出现了应用系统层面的配置管理、网络层面配置管理、硬件服务器层的配置管理等，企业内多个配置管理实现了互联互通。

CMDB3.0紧扣业务价值。2017年前后，随着企业数字化转型的驱动，领先企业的运维组织开始从技术保障到技术运营转变，运维更多的考虑到业务价值，CMDB角色也发生变化。此时，运维对象在深度和广度上都发生了变化，即伴随着互联网、运营商、金融业等行业技术架构的快速演变，运维组织价值的广度与深度都发生了变化。在广度上，从单一的业务连续保障价值，增加了加快IT交付、提升客户体验、提高IT服务质量的价值。在深度上，以业务连续性保障为例，原来主要围绕服务可用性，现在需要深入到逻辑正确性，数据准确性上。从运维对象数据看，需要在原有围绕IT资源为主的CMDB之上扩展，向上扩展到应用、业务、客户体验，比如将应用的进程、服务、集群、功能号、组件、程序、版本、端口、应用配置、参数、证书、用户、节假日、关键指标等配置对象纳管。在横向关系上，云原生、APM、可观测系统为CMDB提供动态的链路关系，以及深入到程序、接口、函数、日志的粒度。此时，就出现了以业务为中心的CMDB3.0。CMDB3.0以各种业务运维场景驱动，梳理和分析运维对象及关系，从物理层、逻辑层、应用层、业务层分层构建模型，既能够支撑企业IT管理的重点从面向资源转移为面向业务，又要实现企业对CMDB的期望：

更全面地管理运维对象，实现“资源视角+应用视角”的数据源管理，具备模型扩展、流程引擎、在线采集、智能校验、关系构建等能力。以场景为驱动，基于对象属性与关系的结合，赋能业务影响分析、故障根源定位、容量管理、业务连续性管理及可用性管理。走出运维，将CMDB作为企业数字化运营管理中业务与IT运营之间的纽带。

CMDB4.0是描述运维数字世界的数字地图。以业务为中心的CMDB之后是什么呢？笔者认为应该是在现有运维对象与对象关系管理的基础上，增强运维知识的管理能力，也就是说下一代CMDB应该类似于运维数字世界中的数字地图。这和我们生活体验类似，以周末出去吃饭为例。十几年前，人们通常靠自己经验或口口相传的方式来引导我们获得信息，此时人们主要生活在一个已知世界。今天，国家快速发展，人们生活水平得到长足的提升，社会为我们提供越来越丰富的选择，人们需要在未知的世界中找到最佳的选择，包括：适合口味的馆子，馆子在哪个位置，如何到达到目的地。很明显你会用到数字地图，或在整合了数字地图的生活应用中获得答案。本质上，数字地图是应对社会信息丰富多样化发展的需要，通过数字技术提供更加准确的信息，提供在线修改、检索、传输信息的方式，数字地图成为描述数字世界的关键手段。运维也要数字地图，用于解决运维数字世界复杂性问题。运维数字地图协助支撑运维数字世界中运维协同流程线上化，交付方式服务化，操作自动化，以及机器、系统、客户体验运行状况与运营效能指标化。如何将运维对象、关系、人的知识关联在一起是CMDB4.0的关键。

二、CMDB系统关键能力

以下梳理CMDB的四个关键能力（见图23-2）：配置建模、数据接入、数据运营、数据消费。

图23-2 CMDB系统四大关键能力

1、配置建模

配置建模主要指识别CI项，包括CI项的分类、CI命名规划、CI项属性、CI项之间的关系，以及基于CI关系构建的全局性关系等。在配置建模能力上，企业需考虑从全局、关系、对象角度综合评估。

1）从全局角度看，配置管理在行业中强调得多，但是真正把配置管理用得很好的并不多，从技术上大致有以下原因：

配置数据缺乏持续的优化所需要的流程和工具支撑。数据没有消费场景，配置数据生成后即处于无法流动的“死”数据。配置库中包括的数据过多，技术架构与配置数据复杂，数据未形成闭环管理。

第1、2点需要CMDB工具平台运营与配置数据治理整体开展，第3点关于配置库过重问题，由于不同运维职能线团队或多或少已经在条线的工具系统存放了相应配置信息，比如IDC运维的环控系统、网络运维的网管系统、服务器与存储的云管系统等。将条线工具系统的配置信息与最核心的CMDB配置库关联（如图23-3），将形成一个配置联邦的全局式的配置模型。联邦式的配置管理模型基于某个领域的CMDB为中心，关联其他领域运维平台的配置数据。联邦方式在运维组织落地阻力较小，一方面，运维组织中基础设施、网络、平台、应用等职能团队通常会有相关专业领域的运维平台，通常平台软件会自带具备CMDB配置管理的模块或商业套件；另一方面，配置管理过程最重要的是配置数据管理，确立配置数据owner，每个领域团队负责对应配置数据质量是行业比较认可的方法；同时，很多配置项目失败的原因是将CMDB的CI项范围定义得过大，导致阻力过大。

图23-3 联邦配置模型

在联邦的配置结构中，应用软件、基础设施、应用平台通常是CMDB中心的选择之一。选择哪个作为组织的CMDB中心的方法有很多，比如以哪个领域的运维平台建设更完备作为选择标准，如果IaaS做得好可以考虑用基于主机为中心进行扩展，如果应用运维平台更好可以考虑基于应用系统为中心；也可以考虑基于CMDB规划建设思路，即如果以业务为中心为规划目标则以应用系统为中心，如果以云计算为中心为规划目标则以平台为中心。

2）从配置关系角度看，配置模型可以分为纵向部署关系与横向链路关系。

纵向部署关系是传统CMDB经常使用的模型，通常表现为归属、包含的关系，在运维平台化过程中得到广泛的配置关系消费，比如，源端监控系统要实现监控策略的自动化，会将纵向关系作用监控对象节点；自动化操作工具、云管平台、应急预案工具等对于主机的管控；统一监控告警工具会使用纵向的关系数据进行收敛、抑制、丰富管理。纵向部署关系重点关注运维对象的分层，包括：基础设施层、平台软件层、应用系统层、业务服务层。其中，基础设施主要针对IDC机房、机柜、网络、服务器、存储等；平台软件主要针对PaaS层的应用平台、容器、数据库、中间件、操作系统等；应用层主要针对系统、应用、服务、集群等；业务服务层主要针对功能、订单等。这些运维对象之间有一个纵向归属或包含的关系，比如：业务服务涉及的功能、订单归属于应用系统，应用系统由多个主机的集群组成，应用部署在集群的操作系统或容器中，虚拟机节点由某个物理主机虚拟化，物理主机安装在服务器中并使用了部分存储，服务器分配在配些网段中并安装在某个IDC的某个机柜。

横向链路关系是面向以业务为中心配置管理的补充，以分布式链路追踪技术为例，分布式追踪技术是云原生架构下横向关系数字化的重要手段，对于当前复杂架构有极大的效益。随着企业应用系统越来越多，业务逻辑越来越复杂，系统与系统之间的依赖关系变成一个很关键的描述对象的数据。以银行的网上支付为例，一个支付业务涉及超过10个以上的应用系统，交易流转过程中涉及的应用系统节点异常将直接影响交易的正确完成。链路的复杂性在当前云原生微服务架构下更加突出，一次后端请求，可能历经了多个服务才最终响应到客户端，如果在调用链的某一环节出现了问题，排查起来很复杂。这种上下游依赖的关系是对象之间的横向关系，不同类型的对象会有不同的依赖关系，比如系统级别、应用级别、服务级别、接口级别、函数级别等。在技术上，借鉴可观测理念，横向关系信息可以通过NPM、APM、分布式链路、应用日志等数据分析中获取为主，并增加人工绘制的辅助。

3）从配置对象角度看，配置模型映射生产环境业务运行所需要的硬件与软件的配置数据，采用分层的角度看待生产环境，可以分为：基础设施层、平台软件层、应用系统层、业务及体验层。配置对象数据针对这几层数据的数据描述。

基础设施层的配置对象面向数据中心层面，重点关注数据中心中部署的数据处理、数据传输和网络通信、服务器、存储设备等多种IT设备，以及为IT设备服务的电力、空调、传输管路等相关系统及设备。需要对应机房环境设施管理、网络运维管理、存储资源管理、服务器运行管理、虚拟化管理等涉及的配置信息进行有效管理。

平台软件层的配置对象面向商业套件，重点关注的平台软件包括：各种操作系统、数据库、中间件、备份软件、应用容器云平台等。通常成熟的商业套件都有相应的配置数据，比如：操作系统管理重点关注操作系统层版本、用户、权限、文件、磁盘等配置数据；数据库管理重点关注数据库规划相关配置，比如数据库进程、表空间、日志、数据库锁等配置数据。

应用系统层的配置对象面向应用系统，以及应用系统有效运营需要的具体配置数据，比如运行保障需要应用端口监听、进程状态、容器服务及集群状态、应用软件版本、软件发布时间、调度任务时间、任务状态、开业状态等配置管理。对应的配置模型包括：系统、应用、应用服务、应用端口、程序进程、容器服务、容器集群、应用版本、应用日志、应用目录、证书、网络IP、关联团队角色等。

业务及体验层的配置对象重点面向终端、性能管理。数字化转型的大背景下，企业的运维需要向业务及体验层扩展，需要运维工程师具备数据思维，能够让系统运行，业务运作，客户体验，流程管理等数字化，并利用掌握的运营数据驱动研发，测试，业务运营的持续优化。从配置对象看点，需要从用户旅程作为切入点，对于终端设备配置、终端软件版本等配置信息进行管理。

通过上面全局、关系、对象三个角度的配置模型分析，在CMDB配置模型能力的选型时建议关注：免代码的方式配置CI模型，支持随时对资源对象、属性、关系的定义、约束条件进行增删改查，支持随时根据业务发展的新需求，对资源属性进行增、删、改、查等操作；支持基础设施、服务器、网络、应用、客户体验层的配置模型设计，并与关联系统进行配置关联；支持灵活的资源配置查询，比如按资源对象继承关系树状浏览资源等对象的模型定义；具备清晰的配置项及属性的元数据管理，能够查看相关元数据定义，比如：名称、描述、父类、数据库表、图标等；支持资源多维度管理，实现资源审核、回溯、基线功能；支持配置模型之间关系的发现与可视化管理，通常包括横向的业务拓扑与纵向的物理拓扑。

2、数据接入

CMDB虽然是管理生产对象配置的信息系统，但CMDB自身不生产对象数据，需要采集或接收各源端生产系统的数据，根据配置模型落地为配置数据。CMDB的数据接入能力需要解决配置原始数据的统一采控，通常包括技术层面的自动化采控与线上流程层面管理的配置准入。

1）数据接入的常见方法如下

配置数据分散在多个不同的源端，比如IaaS层面的多云管理云管平台，PaaS层的容器平台、数据库平台、中间件平台，OS层面的主机等。要实现配置数据的统一管理，需要建立统一的数据采集与控制能力。数据接入方法通常有两种，一种是基于CMDB代理或无代理网络协议主动的对源端主机进行采控，另一种是由服务端对企业相关平台软件进行集中同步。

前者，对源端对象的配置数据采集通常采用agent代理或某些网络协议，通过执行脚本或命令实现服务端到源端数据源标准化的数据采集与管控。数据采集后，CMDB将根据配置模型，对源数据进行清洗、转换等处理动作，并存储入库。

后者，结合前面提到的配置联邦思路，从平台软件层面获取配置数据。比如针对于硬件层面的配置，由云管平台实现数据中心、资源池、集群、宿主机、虚拟机、虚拟存储、虚拟磁盘、虚拟交换机、VLAN、虚拟网卡、物理设备、设备部件、系统软件等配置属性和关系，CMDB根据配置数据时效性批量采集云管平台数据。

2）配置自发现方法如下

配置数据准确性决定CMDB的成败，流程控制与配置自发现是实现配置数据准确与保鲜的方法。其中，配置自发现建立在上节提到的两种数据接入能力上，实现定期或实时配置数据采集与配置发现策略。比如，通过服务端定期扫描网络，把新增IP资源采集到CMDB中，为资源管理提供最准确的IP地址库等；通过自定义脚本发现对象属性的自定义扩展等；通过脚本方式，实现自动获取包含网络设备、存储设备、数据库、中间件，以及获取更详细的资源信息；通过部署程序埋点或拦截器注入SDK后，实现应用关系自动发现等。

在配置自发现中，相比配置属性的自发现，关系配置一直是一个难点。目前主流的CMDB采取了一些技术手段，支持对象层面配置与对象纵向的部署关系的自发现，比如：

存储、交换机、服务器的部署关系虚拟机与宿主机之间的部署关系进程与操作系统运行关系数据库与操作系统运行关系中间件与操作系统的运行关系交换机和路由器的网络连接关系物理机与交换机的物理间接关系网络设备与网络端口的组成关系

随着以业务为中心CMDB3.0的出现，下一步需要增强横向业务、应用、服务、接口等维度关系的自发现能力。要实现横向关系，仅仅依靠CMDB的产品的关系建模与数据分析还不够，还需要推动应用架构与可运维性相关工作的前移，与研发团队在应用系统设计层面加以数据埋点（详细思路参见第22章可观测的介绍）。

3）不是所有配置都能自发现

从平台自动化优先的指导思路看，所有配置均能自发现是最好的选择，但实际上还有不少配置需要手工配置维护，比如：应用系统与主机的关系，应用系统下的人员角色、系统概述等配置信息。由于靠手工配置维护容易出现“遗忘”“漏做”导致的配置错误情况，也就是配置“黑户”，需要建立在线的流程机制确保手工维护的配置项得到有较落地，比如上面提到的几个配置数据可以考虑以下流程：

在CMP的资源申请环境的流程中，建立资源与应用系统之间的关系。在应用系统新系统上线或项目管理立项等流程中，增加应用系统名称、说明、人员角色等配置信息。

当然，好的流程设计，在流程过程的表单数据录入环节应该建立起对应配置模型的原始数据，在流程结束后能够自动化触发配置数据自动落库。这个方案需要ITSM系统的流程支持自动化触发CMDB配置入库接口的平台能力。

3、数据运营

配置数据运营也可以理解为配置数据治理，目标是让配置数据更加准确，是CMDB项目投入最大、难度最大的工作环节。相关解决思路在下一章的CMDB数据治理中有详细介绍，这里从系统功能角度看数据运营需要的能力概述：

管理配置数据目录，建立配置项及属性的owner关系。支持对配置项及属性质量的在线监测，并触发配置质量的跟进闭环机制。支持对各类资源对象数量及其变化趋势、资源动态、资源变更次数和变更频率的数据统计。支持配置消费运营看板或报表，比如主机、应用功能、配置、证书等配置主题的数据统计，从数据消费数据分析配置数据质量。支持部分配置管理对象的个性化监测，比如资源维保到期、证书到期、系统维护状态等个性化的管理闭环。支持资源、服务、运行状态的监测，从平台整体稳定性层面，保证配置数据管理。

4、数据消费

曾鸣在《智能商业》中曾提出了一个“活数据”概念。他认为活数据应该具备“数据是活的”与“数据是被活用的”，前者指数据是在线的，可以随时被使用；后者指数据是在不断地被消化、处理，产生增值服务，同时又产生更多的数据，形成数据回流。配置数据基于数据接入层面的自发现与在线流程管理实现了基本的配置数据在线，下一步要通过配置数据消费让配置被活用。

随着平台化建设的不断推进，CMDB配置在很多场景得到应用，以故障管理场景为例，由于故障管理极为复杂，需要整合大量工具能力与流程机制，在故障发现、响应、定位、处置、恢复、复盘各个环节都需要CMDB配置支持，比如在应用程序最小颗粒的应急预案中，当一个主机部署的应用出现异常时，需要CMDB告知应急场景异常应用归属于哪个信息系统、应用部署在哪些主机、触发部署主机恢复动作时需要向自动化脚本输入什么主机地址、在操作执行后根据哪些配置与监控系统关联获知是否恢复、如何触发哪些下游系统验证。除了故障场景，CMDB还广泛被应用于以下场景。

值班管理场景中，排班、交接班等功能消费信息系统所属团队、角色等配置信息，值班例行任务功能消费团队汇报链、操作任务涉及的系统、主机等配置信息。

巡检管理场景中，自动化巡检任务功能消费基础设备、服务器、平台软件、主机，以及应用系统相关配置，手工巡检任务功能消费系统、团队、角色等配置信息。

监控管理场景中，源端监控策略要实现自动化配置需要建立在CMDB基础上，统一告警在数据采集后涉及的数据标准化、丰富、收敛、抑制，以及告警的处置环节的组织架构与信息触达相关消费配置信息。

常规工单处理与服务台中，需要消费信息系统、应用、角色等基本配置信息，故障管理涉及大量工作场景，主要围绕事前、事中、事后建立起来。

另外，在变更管理的运维前移、CAB评审、变更审批、软件发布、灰度发布、资源扩容、参数维护、数据维护、服务目录、服务台管理、可用性管理、环境管理、成本管理、知识管理、信息发布、以及各种数据运营报表中也需要广泛消费CMDB，此处暂不一一列举。

除了场景层，CMDB还需要关注技术层面对配置消费能力建设，包括面向机器与面向人两种方式。前者关注API，后者关注可配置化、敏捷落地的配置功能。

面向机器的API。CMDB在运维体系中承担体系元数据与资源对象与关系主数据的角色。系统通过接口的方式，向第三方系统提供资源对象、资源对象关系视图，供第三方系统进行自动化操作、故障定位、影响分析等消费。技术上，API采用开放式的API接口，接口类通常包括：资源模型接口、资源维护接口、资源数据查询及资源关系视图调用等接口。

面向人的配置数据消费功能。CMDB需要提供用户快速检索相关配置数据，支持在海量资源数据中快速检索到所需要的资源数据，支持对资源的附件信息进行检索，提供个性化功能，比如：能够将最近、最常用的所搜关键字进行记录并保存。

无论是API，还是数据消费功能，CMDB需要能够支持配置化的接口或功能新建，能够记录数据消费的次数、频率等运营数据，用于CMDB的配置运营。

三、运维数字地图

数字时代，运维对象在深度和广度上都发生了变化。伴随着互联网、运营商、金融业等行业技术架构的快速演变，运维组织价值的广度与深度都发生了变化。在广度上，从单一的业务连续保障价值，增加了加快IT交付、提升客户体验、提高IT服务质量的价值。在深度上，以业务连续性保障为例，原来主要围绕服务可用性，现在需要深入逻辑正确性、数据准确性。从运维元数据全局的对象数据看，需要在原有围绕IT资源为主的CMDB之上进行扩展，向上扩展到应用、业务、客户体验，比如将应用的进程、服务、组件、程序、端口、配置、参数、证书、节假日等配置对象纳管，在横向上要将对象之间的关系链路配置化。此时，CMDB作为运维数字地图的作用呼之而出。

从运维数字地图定义看，物理世界的数字地图包括地理要素、辅助要素、数学要素3要素，分别对应运维数字地图的运维对象、运维指标、架构模型。运维数字地图描述运维数字世界的作用与运维元数据描述运维对象的作用一致，运维元数据是运维数字地图的数据层面的表达方式，运维元数据模型：即描述“运维对象、运维指标、架构模型”的数据。其中，运维对象是运维数字世界的实体对象，描述运维对象的数据，即描述运维组织、基础设施、计算资源、平台软件、软件系统、应用服务的数据；运维指标描述运维数字世界实体对象状况，是运维数据分析场景的关键原材料，指标描述了运维对象的运行状况；架构模型即运维对象的关系，主要包括纵向部署关系、横向链路关系、知识关系。现有CMDB已经具备对运维对象、架构模型的描述，下一步随着运维数据治理越来越受重视，CMDB是否在运维指标体系中发挥元数据管理的角色还需要再跟踪观察一下。

最后，借用业界对CMDB产品的介绍，总结一下CMDB解决方案在落地上考虑的思路：

数据消费场景先行纵向互通，横向互联以应用为中心强调选取合理管理颗粒度强调集中集成强调数据消费的外延扩展自动采集技术的深化应用以图边、图节点表现关系模型