新常态下的 CMDB 系统规划与落地

前言

配置管理数据库（CMDB）是企业 IT 建设绕不开的一个课题，从最初的与 ITIL 紧密绑定以及面向资源管理，到如今的“寻求独立与地位提升”，CMDB 走的路线恰恰是所谓 IT 元数据对 IT 建设以及业务支撑的核心作用以及人们对一个事物认知不断演变过程。本文站在 CMDB 领域发展历史的大背景下，展望新一代配置管理对于企业数字化转型与智能运维体系建设的支撑作用，同时结合笔者经历过的 CMDB 项目经验，与大家分享 CMDB 建设的新理论、技术路线及实施方法论。

CMDB 的发展变迁

2001 年，CMDB 最早出现在 ITIL V2.0 中，并有如下定义：

配置管理数据库，是与 IT 系统所有组件相关的信息库，它包含 IT 基础架构配置项的详细信息。

作为 IT 管理的核心，CMDB 自诞生起就备受各行各业企业用户关注，同时也是各大软件厂商的研发热点。在企业用户和软件厂商不断展开探索、积累最佳实践的过程中，CMDB 被赋予鲜活的生命力，大概可以分为以下几个阶段：

• 2001 年-2008 年，以配置信息电子化为特征的 CMDB1.0：随着以 BMC 为代表的传统软件巨头在自家的 ITIL 相关产品中推出第一代 CMDB 管理的产品和解决方案，CMDB 逐渐在国内得到应用及实施。然而，由于企业对 CMDB 理解不深及技术局限，CMDB 沦为侧重于配置（资产）管理和数据查询的工具。

• 2008 年-2017 年，以数据管理闭环为特征的 CMDB2.0：以银行、运营商为代表的企业开始侧重于 CMDB 与其他流程的协同以及故障、变更影响分析等诊断场景。同时，配置自动化发现技术的引入，帮助企业极大简化了配置数据初始化工作。

• 2018 年至今，以面向业务为特征的 CMDB3.0：伴随着互联网、运营商、金融业等行业技术架构的快速演变，IT 运维呈现出“厚平台，薄应用”、快速迭代、开发运维一体化等趋势，在此趋势影响下，CMDB 的应用场景集中表现为：业务（应用）是 CMDB 核心，将与某个应用的配置项（包含进程、服务、组件、服务器、网络等）及其关系悉数纳管，同时通过广泛集成、自动采集、流程保障、定期审计等多种方式确保数据的唯一性和准确性。

在 CMDB 的发展变迁中，IT 技术在不断更新，CMDB 解决方案和实施方法论也随之迭代优化。在这个过程中，不可避免地产生了大量的共性问题，从某种程度上说，CMDB 的发展史就是持续解决问题的编年史。

AIOPS 和数据治理赋予 CMDB 新的定义及发展方向

2020 年以来，随着 AIOPS 落地场景逐渐丰富、运维数据治理理念的兴起、应用系统运维和运营相互融合，运维工作模式及管理方法论发生了巨大的变化。因此，我们需要对 CMDB 进行新的阐述和定义。

CMDB 本质上是 IT 资源（设备、组件、系统）及其关系的数学抽象，是 IT 资源的“高德地图”，是 IT 运维及 IT 运营的数字基石，是运维工作展开的底层支撑，是运维数据治理的容器和载体。

在此定义下，CMDB 的发展方向呈现下列技术方向：

• 通过标准化、数据治理，将配置基础数据及关联关系数据标识、建模、纳管，以集中集成的数据源为统一输出，并提供各运维作业场景进行数据消费。

• 保障数据准确性和唯一性的基础上，CMDB 是智能运维作业的基础平台和数据基石。

• 从离线处理到实时在线：过去的 CMDB 所支持的 IT 服务过程是离线的，不需要实时获取线上变化；新常态下，IT 服务往往实时反应线上资源状态变化，因此 CMDB 这个电子地图也需要实时同步；

• 从资源到服务：在新技术驱动下，从基础设施到技术组件，往往抽象成服务，并进一步表现为从服务构建到服务运行再到服务运营；

•  从工具系统到平台实施：CMDB 配置管理并不是一个简单的系统部署过程，而是一个咨询、培训、实施、优化密切结合的综合过程。在 CMDB 项目循序渐进、持续发展的过程中，应该最大可能地消费 CMDB 中存储的配置项及其关联关系，实现核心价值。

新一代 CMDB 解决方案的典型特征

新一代 CMDB 解决方案从业务的角度规划管理各种运维场景，梳理和分析运维对象及关系，从物理层、逻辑层和应用层几方面分层构建模型。通过该模型中所定义的配置项及关系，帮助运维团队快速了解整体应用资源对象和拓扑关系，提升变更发布、故障分析等运维工作效能，保障业务系统高可用性。

新一代 CMDB 解决方案能够支撑企业 IT 管理的重点从面向资源转移为面向业务，同时实现企业对 CMDB 的期望：

• 以 CMDB 为核心，实现业务影响分析、故障根源定位、容量管理、业务连续性管理及可用性管理。

• 以 CMDB 为基础，实现“资源视角+应用视角”的数据源管理，具备模型自建、流程引擎、离线采集、智能校验、增量发布、字段级审计等能力，在金融行业，往往集中表现为“监管报送”需求。

（一）新一代 CMDB 解决方案的典型特点

• 数据消费场景先行

• 纵向互通，横向互联

• 以应用为中心

• 强调选取合理管理颗粒度

• 强调集中集成

• 强调数据消费的外延扩展，如金融行业的监管报送场景

• 自动采集技术的深化应用

• 以图边、图节点表现关系模型

（二）新一代 CMDB 解决方案的技术路线

• 以业务为中心，实现数据生命周期管理，驱动数据更新：定义配置项从生产、运营、消亡的整个生命周期，并通过设计与之匹配的技术手段（流程、稽核、采集与比对）驱动生命周期状态流转，实现数据闭环管理，更新配置模版，保证配置模型的完整性。

• 以场景为导向、促进数据消费，提高数据流动性：结合实际运维场景，与其他运维工具联动，积极消费数据，体现 CMDB 的最大价值。只有数据被广泛应用，才能保持 CMDB 鲜活的生命力。

新技术·新 CMDB·新建设思路

那么，到底要如何建设 CMDB 配置管理数据库呢？尤其是对于那些体量大，层级多，组织架构复杂，业务场景多的企业来说，CMDB 的建设无疑是一个任重而道远的过程。就某省级运营商的 CMDB 平台建设来说，为了保障平台基础数据的唯一性及准确性，提高 IT 资源的利用效率，达到通过技术促进业务管理的根本目的，整个 CMDB 建设从咨询规划，建立配套的配置管理流程制度，到平台建设及配置实施，再到集中集成，每一个环节都起着举足轻重的作用。

（一）制定合理的规划建设方案

从企业本身来讲，首先要对 CMDB 配置管理有正确的认知，有明确的建设目标和合理的规划建设方案，确保建设的 CMDB 是企业真正想要，也真正需要的东西。“百里之行，始于足下”，在 CMDB 建设之前，建设方需要结合数字化转型浪潮，站在运维数据治理的高度，从运维体系建设的长远视角思考 CMDB 建设。为走好第一步，建设方可以引入更加系统且专业的 CMDB 解决方案及实施方法论，通过业务调研确认项目目标、项目覆盖范围、数据消费场景，达成业务蓝图共识，输出 CMDB 配置管理规划建设方案。

（二）建立配套的配置管理流程制度

CMDB 配置管理建设不仅是技术、平台的事情，还要考虑使用人员、岗位职责、流程关联、配置审计等因素，所以产品上线后需要有一套行之有效的具有企业特色的配置管理流程制度作为运行机制，来保障 CMDB 的运行和维护，否则再先进的技术和设计也无法发挥配置管理真正的作用。

（三）采用科学的实施方法论

基于配置管理软件平台，进行数据标准化实施是 CMDB 建设的又一重点。需要注意的是，配置实施要坚持“以点带面”的原则。传统的 CMDB 构建，使用了“由下向上”的方法论，先做出一个较大的 CMDB，再随着应用逐步理顺配置项。这样做有很大的缺点，就是投入巨大，实施周期长，短期很难见到效益。对于实施的乙方来讲，确实容易掉进“费力不讨好”的陷阱里面。“自上而下，以点带面的渐进式”实施方法是一个比较聪明的选择。通过局部应用，尝试在主题应用环境下发现、管理配置信息的方法和技巧，积累 CMDB 维护和应用的经验。待与 ITIL 的流程配合逐渐成熟后，以点带面，推广更大范围的 CMDB 实施。

配置实施具体包括以下几个关键步骤。首先制定配置管理策略，通过配置项需求识别完成配置项模型设计，并根据设计模板进行数据收集与标准化。然后结合运维所需属性，通过规范的命名规则，提取各领域配置项关键属性，建立配置项关系。定期审核全部或部分配置项及关系数据，确认和生产环境的一致性，从而确保配置信息的完整性。同时，为保证配置管理数据库的配置信息的完整性和正确性，需要设计配置管理内控流程及工作职责，并在系统内实现。除此之外，需要设计 CMDB 配置管理与其他模块的业务关系和流程关系，用以提升整体 IT 运维能力。

（四）充分识别集成业务场景

为了落地规划的业务场景，持续驱动并体现配置数据的价值，CMDB 配置管理需要广泛地和周边系统进行集成。相辅相成的是，通过集成实现的配置数据消费亦能保证配置数据的准确性。以下简单介绍三个常见的集成业务场景。

• 集成业务场景之业务排障

当某一个业务系统出现故障的时候，决策层往往关系以下几个问题：

- 哪个系统出现故障？

-哪些业务受到影响？

-什么原因引起的，应用还是系统？

-如果是应用本身问题，是程序缺陷还是性能问题？

-如果是系统问题，是存储问题、网络问题还是数据库故障？

-谁负责这些问题？

在弄清楚这一系列问题后，决策层才能审定变更维护或者优化方案，而这些都是 CMDB 配置管理的范畴。为了尽快恢复业务，CMDB 配置管理以配置项为唯一标识，集中运行数据做归集，为业务排障提供必要的支撑数据，来收敛化、立体化、标准化告警消息，便于工程师了解故障影响范围和影响程度，判断问题根源，查看故障的运行数据和历史告警事件等。

• 集成业务场景之变更风险管控

据统计，日常 IT 运维事故中 80%源自变更，而变更管理过程与 CMDB 配置管理是紧密结合的。通过明确配置项更新与流程管控联动机制，实施 CMDB 实现与变更流程的融合，使每一个变更管理流程引发和控制对配置项的修改。与此同时，CMDB 通过消费存储的关联关系，帮助变更管理进行风险评估分析。变更审批者可通过查看 CMDB 中的网络拓扑和业务影响拓扑，直观了解此次变更的影响，全面判断是否允许变更。企业可以通过这种变更管理和 CMDB 配置管理的联动，有效降低变更风险，提高变更效率。

• 集成业务场景之库存系统设备管理

通过 CMDB 和库存系统的集成，针对设备入库、设备出库或交接、设备借用或归还、设备处置或报废、设备维护管理等业务，由 CMDB 提供不同业务环节的责任人所需提交的设备、信息模板，明确所需提交字段。由对应责任人根据模板录入相应设备信息并推送给 CMDB。

总结与展望

近年来，关于 CMDB 的建设和管理思路虽然百花齐放，却也万变不离其宗。在新常态的背景下，围绕业务，面向运维建设及运维数据治理，CMDB 系统规划应该考虑在建设标准化、高度集成化、具备动态收集能力的配置管理技术平台的同时，建立简洁有效的配置管理工作机制，只有通过这种技术+管理机制的手段，才能为基于 CMDB 的智能运维应用实践提供坚实基础，为企业业务连续性及服务稳定性的提升提供有力保障。