CMDB似乎是运维中永恒的老话题。多年来也形成了许多方法论，比如场景消费、应用驱动等等，道理似乎都很对，一旦落地却发现理想与现实间巨大的差距：技术之外，建设者们经常要凭一己之力对抗整个组织或流程，一不小心还成了背锅侠。比如很多公司上了配置审计制度却发现难以考核下去，还有诸如数据不准、更新不及时、配置自留库、操作复杂、用户抵制情绪，诸多问题挥之不去。项目最后不是缩水为资产管理系统，就是半死不活没有生命力，处于失败的边缘。
这些实际困难错综复杂，无从下手，我们该如何面对？本文试图从各类复杂的解决方案背后寻找决定性的深层逻辑。下面将围绕CMDB价值定位和数据治理两个核心问题，揭示主数据库这个全局动力与无序熵增这个内在阻力间的矛盾，分析数据治理的政治因素和技术分解，提出CMDB建设的价值能力模型。
1、主数据库
CMDB因主数据库而生，并非为ITIL而生。CMDB的意义看似已深入人心：趋势分析、影响分析、根源诊断…按理这么有价值的系统不应遇到太多阻力啊？其实我们被“配置管理”这些高大上的词汇带偏了。抛开传统定义回归本源，CMDB就是一个保管IT数据资产的主数据库。为何称之为数据资产而不是IT固定资产、无形资产，后面会讨论，这里先谈主数据库。历史上看，CMDB一词源于ITIL，其上下文中CMDB表示IT环境的重要组件的授权配置，包含每个配置项的所有相关细节以及配置项之间重要关系细节的数据库。而配置项(CI)可以定义为“正在(或将要)受配置管理功能控制的基础设施的一个组件”。瞧，多么有文化有内涵啊！但透过ITIL这个具体场景，本质如下图那样CMDB为支撑ITSM大厦而建的主数据库。其实这跟业务系统中的客户主数据、产品主数据之类的MDM没什么区别，因此数据架构治理中主数据领域遇到的种种困难问题，同样发生在CMDB建设中。
早期很多国内公司和厂商是随着ITIL的引入，把CMDB作为标准化产品一起引进产品体系。但国内ITIL落地时主要也就变更、事件几个流程真正在用，CMDB遇到了水土不服。当IT运维体系从小米加步枪变得越来越庞大复杂，监控、自动化运维到DevOps、AIOPS处处离不开CMDB，大家惊呼：CMDB果真是一切运维的基础！从这个演变过程看，CMDB还是那个描述IT资源的主数据系统，不过随着时代发展，主数据的地位愈发重要，CMDB终被推上了风口。
2、主数据库必然产生
到这里我们要冷静下，美丽新世界还面临许多挑战。复盘整个过程，为什么会有主数据这个东东？被誉为可能是人类最靠谱理论之一的热力学第二定律，其熵增原理告诉我们，系统演化总是朝着混乱均衡的方向发展，这是内在趋势。我们眼睁睁开着设计之初简洁优雅的系统，逐步形成各种错综复杂的调用关系，数据不一致、变更影响复杂、系统不稳定等现象随之而来。请各位明白，这个过程是正常的，符合自然规律的。伟大的IT思想先驱们模仿生命熵减的演化特点，锻造了面向对象和面向服务两大武器，来解决IT系统架构复杂性问题，其背后蕴藏一条重要原理：“高内聚，低耦合”。这个原则配合递归同构，形成了宇宙万物最稳定的结构形式。日常生活中边界问题、计划与市场经济、金字塔与自服务、自治结构均是其不同形式的演绎。IT是业务的虚拟和抽象，业务世界的复杂和变化，对应到IT架构要实现两个层面的解耦：一个是业务和技术的解耦，业务实现不再依赖于某种特定的技术，技术的变化对业务影响变小。另一个方面是操作方法和业务数据实体的解耦。因此才产生了SOA、微服务、对象建模、领域建模、主数据等顶层架构设计。IT运维世界里的对象是如此庞大繁杂和多变，各个运维系统无力为继来自主管理。必然产生一个系统，专门管理这些对象和关系，遵循领域建模和面向对象建模原则，采用SOA和主数据库的架构，从而让各运维系统专注自己的业务。这个工具被人起了个名字叫CMDB。
3、产生主数据库的基本条件
任何事物不是先验的，盲目引入工具往往南橘北枳。前面说到CMDB是对抗IT运维架构复杂性的产物，因此当公司运维体系比较简单，或者说还不成熟时，仓促上马CMDB注定失败。企业里一些原始管理手段的矛盾还没爆发时，请严格控制项目范围，摆正预期。要知道你的作战对手有深厚的群众基础，生产力决定生产关系在这里同样适用。虽然这些自建库粗糙、数据孤立、不一致、总体维护成本偏高，但在特定管理水平下，却野蛮生长而且有效。只有当公司运维复杂度提高，尤其是上了微服务、PAAS等运维对象复杂度大幅提升后，自给自足的配置孤岛必然走向CMDB。
全局角度，运维系统达到一定复杂度必然需要CMDB，但微观角度，CMDB天然面临巨大阻力，故应自上而下推动。人类总是在全局和个体、长期和短期之间纠结平衡。虽然从道理上都知道应服从大局，但个体决策时是另外一番情景，让我们换位思考下各个运维系统怎么想：从技术上，通过外部API调用远没有自己应用直连数据库来的方便。管理上，配置模型和数据维护的决定权上收到配置管理团队，大部分修改变更还要经过配置委员会和流程审批。因此自下而上来建设主数据一定会遇到强大阻力的。康威定律从另个角度可以验证：组织架构会决定团队写出的产品架构。如果各运维系统开发团队和CMDB团队分属不同组织，在推动配置库集成这件事上一定会遇到正面或暗地里巨大的困难，尤其一些体制内单位中，人是问题的关键。所以很多方法论中才强调，CMDB建设一定要获得高层理解和支持。我们应跟管理层反复解释这个逻辑，从公司整体运维架构出发，利用组织强大的执行力自上而下推动。CMDB远不仅是个技术方案，更应从组织和管理视角促进CMDB团队和其他运维团队的理解、支持和融合。
4、主数据库+场景模型
CMDB价值的一只脚是主数据，另一只脚则是场景。主数据的道理我们可以跟管理者、架构师沟通，但遇到具体的各个运维单位和工具时，我们面对的局面好比以一当十，要寻找每个对手的弱点逐个击破。用户会找出各种借口，或想保留数据的控制权，或因为原有习惯，或就是偷懒不配合。从个体角度看CMDB落地的关键是场景驱动，场景就是动力。常见有价值的场景包括：安全内控管理（账号、堡垒机、防火墙、漏洞补丁、合规检查、IP端口）、监控告警、自动化运维、资产管理、资源交付、发布管理、应急管理、ITIL流程管理、容量管理等。实践经验来看，安全、监控、应用生命周期管理是三个动力最强的场景抓手，尤其要利用好像“护网行动”这类公司重大事件，将CMDB充分与领导要求、政策目标、安全事件等结合，手握“尚方宝剑”，势不可挡！
场景不仅体现在日常运维流程中，还体现在公司的各类运维工具中。如果CMDB是一家公司，它应该同时面向B2C+B2B双渠道业务。CMDB团队应抱着招商引资的心态，向运维工具的开发团队去推销、谈合作。比如我司还没统一运维门户，CMDB产品团队索性把前台整合进自动化运维系统，最终实现产品和开发团队层面的深度整合。另一方面，利用公司技术架构评审和创新项目评审等机遇，把CMDB集成要求明确列入评审打分项。下图为场景工具集成效果图：
技术和运营，两手都要硬
产品价值方向明确后，如何实现价值就要看团队能力了。模型中的能力分技术和运营两部分，缺一不可。我司建设CMDB时没有采购任何商业软件，简单介绍下使用开源产品的经验。
开源工具的运用
核心模块采用CMDBuild，这是一款意大利团队开发的开源CMDB产品，最新版本是3.0。之所以称之为核心模块，是因为产品化和个性化往往是对矛盾，尤其在国企环境中。我们用CMDBuild来做建模和后台管理，由于它采用PostgreSQL数据库，能很好实现对象继承和变更轨迹。同时基于PostgreSQL强大的适应性，可以跟各种工具灵活整合。比如通过kafka实现消息推送，把CMDB数据变动更及时推送给外围订阅系统。其原生模型具有全局唯一ID和时间戳，外部系统也很方便实现增量同步CMDB。
我们放弃了CMDBuild自带的数据同步工具，因为发现Kettle来做更稳定和高效。Kettle的Insert/Update组件可以很好利用主键实现增量更新，不必每次采集清空目标表。此外Kettle作为专业的ETL工具同样能实现强大的清洗转换功能，是CMDB和外部数据批量同步的重要通道。
我们自行重写了前台和REST接口。CMDBuild原生前台用户体验一般，属于典型后台管理界面风格，且基于角色的权限设计不够灵活。如果公司有100个产品，就要设置100个角色，这是一场灾难。原生的REST接口中，所有外键属性都是ID，为此要逐一转换，前台开发效率太低。用Django的ORM重写了接口后，可以同时提供外键ID和属性值，虽然运行效率有所降低，但极大提升了开发效率。
作为一个完整的CMDB产品团队，运营包括推广、集成、调研、数据治理等工作，这往往是IT工程师们并不擅长的领域，其中最困难就是数据治理了。这里先从从技术层面分解数据治理各个过程，分而治之。再讨论数据变更环节的场景和流程问题。最后从政治层面探讨数据治理“人”的因素，如果人不重视，职责不清，一切治理都无从做起。
1、数据治理拆解
上图解构了解决数据治理问题的具体路径：CMDB的数据可分为自动发现数据和人工录入数据两大类。第一策略是尽最大努力扩大自动发现范围（因为自动发现的数据一定是最准确），降低配置管理的成本。常见的自动发现数据源有云管平台、安全管理系统、网管平台、负载均衡系统、带外管理系统等，总之要团结一切能够自动发现的力量。但接下来总要面对人工录入数据，这里用水池模型来解释。要一个水池干净，一是保证流入的增量干净，二是净化水池中的存量，三是要水循环流动起来。类似的，CMDB增量变更数据由场景流程来控制，存量数据靠数据资产明确属主并提高犯错成本。最后通过场景消费形成正反馈机制。三管齐下。
2、嵌入场景和流程设计
场景和流程是CMDB执行阶段重要环节，这里应注意场景结合的空间结构和流程约束的时间结构。
调整场景结合的空间结构：传统ITIL场景中配置项变更，一般是用户到流程平台或CMDB门户中去维护，流程重，体验差，导致数据质量不佳。正确的设计思路是把CMDB的位置嵌入到用户场景中最便捷的时间、地点中，降低数据消费门槛。因此CMDB应重点建设实时接口或页面API，以SOA方式嵌入到各种场景中，前端用户甚至感受不到CMDB的存在。我们可以弱化CMDB自身门户入口，成为纯后端平台，转而从外部场景工具中引入流量。
调整流程约束的时间结构：流程的约束设计应尽量从事后提前到事中解决。我们对用户在场景中的配置管理要求，通常以流程管控和数据审计的方式写入制度规范中。制度一般会安排多个角色：CMDB配置经理、CMDB维护人员、CMDB审计人员等等，兴师动众却效果一般，尤其是体制内的事后考核往往无法落实，难以有效保证数据质量，我们推荐事中进行“自审计”。举个例子，某个流程要求设备到货时某人某时刻录入CMDB，但执行人可能偷懒或者真的遗忘了，事后审计虽然形成闭环但效率低。更优的流程设计是把设备初验场景整合进流程里，如果没有录入CMDB则无法初验，流程在执行中就有人会跳出来拉响警报。请注意以往逻辑是业务先变更，再到CMDB登记，业务是因，CMDB是果。正确的思路把CMDB设计为某个业务活动的因，这样数据质量可以得到极大改善。下图为部分流程样例，把堡垒机申请、防火墙申请、设备部署、监控接入等业务活动都设计为依赖CMDB数据。
3、引入数据资产的理念
资产是能够给企业带来经济利益的重要资源，数据中心最重要的资产是其资源结构，CMDB则是管理这类资产的唯一工具。把CMDB地位意识提升到数据资产这个层次，是解决数据治理中重视不足、推诿扯皮常见问题的重要基础。
DAMA(国际数据管理协会)数据管理职能框架如下图，涉及元数据建模、制度流程、安全审计等等多维度技术管理手段。这个庞大框架背后有一条关键定义：数据治理(DG，Data Governance)是指对数据资产的管理活动行使权力和控制的活动集合(规划、监控和执行)。
让我们回到问题之初：数据治理，治理什么？治理的对象是数据吗？其实不然。运维过程中产生了诸如日志、监控等大量数据，虽然是一种重要的电子化记录，可以集中清洗并分析，却并没有治理的必要。因此，数据治理的对象必须是重要的数据资源，DAMA定义中称之为“数据资产”可谓相当到位。
那么数据中心的重要资产有哪些？除了传统意义上开得见摸得着的机房、服务器、网络硬件这类有型资产，更有价值的是广义的无形资产。就如同数据和信息间的差别，孤立的人员、产品、主机、中间件、数据库、应用包、配置等这些资源只是数据，他们之间互相依赖支撑拟合形成的结构关系才是有价值的信息。数据中心正是依靠它们撑起了外界所看到的一个个系统和一个个服务，像有机体那样对外界输入进行处理并反馈，整个资源结构保存在CMDB中。一个产品可以利用其CMDB中的信息在另一套环境中重建，灾难发生时甚至可以基于CMDB重建整个机房。
资产是管理的起点，如果不了解管理对象，管理从何谈起？前阵子微信上故宫的单院长火了一把，他上任伊始做的一件事是走遍故宫的1200座建筑9371间房间，盘点清楚1862690件（套）文物，搞清自己的资产是他管理的第一步。将军带兵打仗，首先要了解他的士兵、武器和补给。反观数据中心的各层级管理者们，大家清楚数据中心的IT数据资产吗？我们有多少设备、产品、服务？每个产品所用的主机、中间件、数据库实例情况都掌握吗？有那些关键业务流程涉及那些服务？服务间调用关系拓扑是怎样的？大部分企业管理在粗放阶段，这些信息是模糊、分散的。梳理清这些数据资产是各层级管理者本职工作，而不能把CMDB当做替罪羊！我发现工作认真细致的团队负责人，其团队的配置数据质量也往往较高。我们一定要向老板和部门领导们呼吁一个理念：CMDB不是要逃脱责任，但数据质量更是全公司的责任！工作中有个负反馈循环：数据实际生产者埋怨数据不准而不愿意使用CMDB，CMDB因为没人不用所以数据更加不准。引入数据资产概念后这个问题就明确了：资产要确权，资产归谁，谁就要负责。事实上，产权问题是土地治理、国企治理等各种治理活动在人性层面的关键问题。
4、 数据资产的抓手：产品运行配置基线
上述理念具体落地时，我们以“产品运行配置基线”作为执行的抓手，具体解决两个问题：一是明确存量数据的责任人。二是起到“户口登记”的基线作用。
数据资产的概念比较虚，具体落地体现在让CMDB在所有运维场景谈到产品时占据人们的“第一联想”。产品运行配置基线这和研发管理的配置基线有所不同，大家可参考附表的框架。这里不仅包括传统产品架构资源信息，还囊括运行生产中所需要的人员、容量、安全各领域信息。它可以投放到ECC总控中心、事件管理平台等各类运维场景和系统，任何时间地点看到、用到围绕产品的相关信息时，大家都意识到源头来自CMDB。
形成产品这个管理单位的边界后，接下来要明确数据责任人。数据资产可以划分两类：一是硬件资源类，二是逻辑资源类。前者往往是以资源池的形式提供服务，和产品关系不紧密，故CMDB数据责任人建议是负责资产的设备管理员。后者由于组织分工因素，有些配置类型较难明确界定归属，导致审计责任不清。这里建议由产品团队负责人（产品经理或者应用管理员）对CMDB数据负责。CMDB中某个产品的如何数据不准，可以直接追溯到责任人。
产品运行配置基线另外起到“户口登记”的作用，可参考附表中关联影响一列。我们常口口声称CMDB是权威的配置信息来源，何谓权威？就要像“户口”一样必须登记准确，否则寸步难行！这里的“基线”是要让CMDB成为其他管理场景的依赖先决条件。如果基线中的信息不准，产品的各种运维活动，像监控、自动化运维、堡垒机登录、备份等工作均无法正常开展。
总结
以上围绕CMDB价值本源和数据治理两个核心问题，分析了CMDB内在动力和必然面对的障碍，给出主数据库、数据资产、场景驱动、自审计流程、产品运行配置基线等一些理念和工具。上述解决方案并没有重大创新，但经过逻辑推演，希望能为读者梳理其因果关系和思路。毕竟，CMDB只是一个工具手段，掌握其来龙去脉，方能有的放矢。希望这些经验对大家的项目建设有所帮助，让我们在配置管理之路上痛并思考着，共同成长！
