CMDB平台技术建设实践.docx

《CMDB平台技术建设实践.docx》由会员分享，可在线阅读，更多相关《CMDB平台技术建设实践.docx（15页珍藏版）》请在第一文库网上搜索。

1、CMDB平台建设实践AA【摘要】CMDB似乎是运维中永恒的老话题，方法论很多，落地却发现理想与现实间存在巨大差距：技术之外，建设者们经常要凭一己之力对抗整个组织或流程，一不小心还成了背锅侠。本文试图从各类复杂的解决方案背后寻找决定性的深层逻辑，将围绕CMDB价值定位和数据治理两个核心问题，揭示主数据库这个全局动力与无序炳增这个内在阻力间的矛盾，分析数据治理的政治因素和技术分解，提出CMDB建设的价值能力模型。问题的提出CMDB似乎是运维中永恒的老话题。多年来也形成了许多方法论，比如场景消费、应用驱动等等，道理似乎都很对，一旦落地却发现理想与现实间巨大的差距：技术之外，建设者们经常要凭一己之力对

2、抗整个组织或流程，一不小心还成了背锅侠。比如很多公司上了配置审计制度却发现难以考核下去，还有诸如数据不准、更新不及时、配置自留库、操作复杂、用户抵制情绪，诸多问题挥之不去。项目最后不是缩水为资产管理系统，就是半死不活没有生命力，处于失败的边缘。这些实际困难错综复杂，无从下手，我们该如何面对？本文试图从各类复杂的解决方案背后寻找决定性的深层逻辑。下面将围绕CMDB价值定位和数据治理两个核心问题，揭示主数据库这个全局动力与无序燧增这个内在阻力间的矛盾,分析数据治理的政治因素和技术分解，提出CMDB建设的价值能力模型。产品价值的追问1、主数据库CMDB因主数据库而生，并非为ITI1而生。CMDB的意

3、义看似已深入人心：趋势分析、影响分析、根源诊断按理这么有价值的系统不应遇到太多阻力啊？其实我们被“配置管理”这些高大上的词汇带偏了。抛开传统定义回归本源，CMDB就是一个保管IT数据资产的主数据库。为何称之为数据资产而不是IT固定资产、无形资产，后面会讨论，这里先谈主数据库。历史上看，CMDB一词源于IT11,其上下文中CMDB表示IT环境的重要组件的授权配置，包含每个配置项的所有相关细节以及配置项之间重要关系细节的数据库。而配置项（CD可以定义为“正在（或将要）受配置管理功能控制的基础设施的一个组件“。瞧，多么有文化有内涵啊！但透过ITI1这个具体场景，本质如下图那样CMDB为支撑ITSM大

4、厦而建的主数据库。其实这跟业务系统中的客户主数据、产品主数据之类的MDM没什么区别，因此数据架构治理中主数据领域遇到的种种困难问题,同样发生在CMDB建设中。早期很多国内公司和厂商是随着ITI1的引入，把CMDB作为标准化产品一起引进产品体系。但国内IT11落地时主要也就变更、事件几个流程真正在用，CMDB遇到了水土不服。当IT运维体系从小米加步枪变得越来越庞大复杂，监控、自动化运维到DeVoPs、A1oPS处处离不开CMDB,大家惊呼：CMDB果真是一切运维的基础！从这个演变过程看，CMDB还是那个描述IT资源的主数据系统，不过随着时代发展，主数据的地位愈发重要，CMDB终被推上了风口。2、

5、主数据库必然产生到这里我们要冷静下，美丽新世界还面临许多挑战。复盘整个过程，为什么会有主数据这个东东？被誉为可能是人类最靠谱理论之一的热力学第二定律，其浦增原理告诉我们，系统演化总是朝着混乱均衡的方向发展，这是内在趋势。我们眼睁睁开着设计之初简洁优雅的系统，逐步形成各种错综复杂的调用关系，数据不一致、变更影响复杂、系统不稳定等现象随之而来。请各位明白,这个过程是正常的，符合自然规律的。伟大的IT思想先驱们模仿生命燧减的演化特点，锻造了面向对象和面向服务两大武器，来解决IT系统架构复杂性问题，其背后蕴藏一条重要原理：“高内聚，低耦合”。这个原则配合递归同构，形成了宇宙万物最稳定的结构形式。日常生

6、活中边界问题、计划与市场经济、金字塔与自服务、自治结构均是其不同形式的演绎。IT是业务的虚拟和抽象，业务世界的复杂和变化，对应到IT架构要实现两个层面的解耦：一个是业务和技术的解耦，业务实现不再依赖于某种特定的技术，技术的变化对业务影响变小。另一个方面是操作方法和业务数据实体的解耦。因此才产生了SOA、微服务、对象建模、领域建模、主数据等顶层架构设计。IT运维世界里的对象是如此庞大繁杂和多变，各个运维系统无力为继来自主管理。必然产生一个系统，专门管理这些对象和关系，遵循领域建模和面向对象建模原则，采用SOA和主数据库的架构，从而让各运维系统专注自己的业务。这个工具被人起了个名字叫CMDBo3、

7、产生主数据库的基本条件任何事物不是先验的，盲目引入工具往往南橘北枳。前面说到CMDB是对抗IT运维架构复杂性的产物，因此当公司运维体系比较简单，或者说还不成熟时，仓促上马CMDB注定失败。企业里一些原始管理手段的矛盾还没爆发时，请严格控制项目范围，摆正预期。要知道你的作战对手有深厚的群众基础，生产力决定生产关系在这里同样适用。虽然这些自建库粗糙、数据孤立、不一致、总体维护成本偏高，但在特定管理水平下，却野蛮生长而且有效。只有当公司运维复杂度提高，尤其是上了微服务、PAAS等运维对象复杂度大幅提升后，自给自足的配置孤岛必然走向CMDBo全局角度，运维系统达到一定复杂度必然需要CMDB,但微观角度

8、，CMDB天然面临巨大阻力，故应自上而下推动。人类总是在全局和个体、长期和短期之间纠结平衡。虽然从道理上都知道应服从大局，但个体决策时是另外一番情景，让我们换位思考下各个运维系统怎么想：从技术上，通过外部AP1调用远没有自己应用直连数据库来的方便。管理上，配置模型和数据维护的决定权上收到配置管理团队，大部分修改变更还要经过配置委员会和流程审批。因此自下而上来建设主数据一定会遇到强大阻力的。康威定律从另个角度可以验证：组织架构会决定团队写出的产品架构。如果各运维系统开发团队和CMDB团队分属不同组织，在推动配置库集成这件事上一定会遇到正面或暗地里巨大的困难，尤其一些体制内单位中，人是问题的关键。

9、所以很多方法论中才强调，CMDB建设一定要获得高层理解和支持。我们应跟管理层反复解释这个逻辑，从公司整体运维架构出发，利用组织强大的执行力自上而下推动。CMDB远不仅是个技术方案，更应从组织和管理视角促进CMDB团队和其他运维团队的理解、支持和融合。4、主数据库+场景模型CMDB价值的一只脚是主数据，另一只脚则是场景。主数据的道理我们可以跟管理者、架构师沟通，但遇到具体的各个运维单位和工具时，我们面对的局面好比以一当十，要寻找每个对手的弱点逐个击破。用户会找出各种借口，或想保留数据的控制权，或因为原有习惯，或就是偷懒不配合。从个体角度看CMDB落地的关键是场景驱动，场景就是动力。常见有价值的场

10、景包括：安全内控管理（账号、堡垒机、防火墙、漏洞补丁、合规检查、IP端口）、监控告警、自动化运维、资产管理、资源交付、发布管理、应急管理、ITI1流程管理、容量管理等。实践经验来看，安全、监控、应用生命周期管理是三个动力最强的场景抓手，尤其要利用好像“护网行动”这类公司重大事件，将CMDB充分与领导要求、政策目标、安全事件等结合，手握“尚方宝剑”，势不可挡！场景不仅体现在日常运维流程中，还体现在公司的各类运维工具中。如果CMDB是一家公司，它应该同时面向B2C+B2B双渠道业务。CMDB团队应抱着招商引资的心态，向运维工具的开发团队去推销、谈合作。比如我司还没统一运维门户，CMDB产品团队索性

11、把前台整合进自动化运维系统，最终实现产品和开发团队层面的深度整合。另一方面，利用公司技术架构评审和创新项目评审等机遇，把CMDB集成要求明确列入评审打分项。下图为场景工具集成效果图:技术和运营，两手都要硬产品价值方向明确后，如何实现价值就要看团队能力了。模型中的能力分技术和运营两部分，缺一不可。我司建设CMDB时没有采购任何商业软件，简单介绍下使用开源产品的经验。开源工具的运用核心模块采用CMDBUiId,这是一款意大利团队开发的开源CMDB产品，最新版本是3.0。之所以称之为核心模块，是因为产品化和个性化往往是对矛盾，尤其在国企环境中。我们用CMDBUiId来做建模和后台管理，由于它采用Po

12、stgreSQ1数据库，能很好实现对象继承和变更轨迹。同时基于PostgreSQ1强大的适应性，可以跟各种工具灵活整合。比如通过kafka实现消息推送，把CMDB数据变动更及时推送给外围订阅系统。其原生模型具有全局唯一TD和时间戳，外部系统也很方便实现增量同步CMDB。我们放弃了CMDBui1d自带的数据同步工具，因为发现Kett1e来做更稳定和高效。Kett1e的InSert/Update组件可以很好利用主键实现增量更新，不必每次采集清空目标表。此外Kett1e作为专业的ET1工具同样能实现强大的清洗转换功能，是CMDB和外部数据批量同步的重要通道。我们自行重写了前台和REST接口。CMDB

13、Ui1d原生前台用户体验一般，属于典型后台管理界面风格，且基于角色的权限设计不够灵活。如果公司有100个产品，就要设置IOO个角色，这是一场灾难。原生的REST接口中，所有外键属性都是ID,为此要逐一转换，前台开发效率太低。用DjangO的ORM重写了接口后，可以同时提供外键H）和属性值，虽然运行效率有所降低，但极大提升了开发效率。数据治理的逻辑作为一个完整的CMDB产品团队，运营包括推广、集成、调研、数据治理等工作，这往往是工程师们并不擅长的领域，其中最困难就是数据治理了。这里先从从技术层面分解数据治理各个过程，分而治之。再讨论数据变更环节的场景和流程问题。最后从政治层面探讨数据治理“人”的

14、因素，如果人不重视，职责不清，一切治理都无从做起。1、数据治理拆解上图解构了解决数据治理问题的具体路径：CMDB的数据可分为自动发现数据和人工录入数据两大类。第一策略是尽最大努力扩大自动发现范围（因为自动发现的数据一定是最准确），降低配置管理的成本。常见的自动发现数据源有云管平台、安全管理系统、网管平台、负载均衡系统、带外管理系统等，总之要团结一切能够自动发现的力量。但接下来总要面对人工录入数据，这里用水池模型来解释。要一个水池干净，一是保证流入的增量干净，二是净化水池中的存量，三是要水循环流动起来。类似的，CMDB增量变更数据由场景流程来控制，存量数据靠数据资产明确属主并提高犯错成本。最后通

15、过场景消费形成正反馈机制。三管齐下。2、嵌入场景和流程设计场景和流程是CMDB执行阶段重要环节，这里应注意场景结合的空间结构和流程约束的时间结构。调整场景结合的空间结构：传统ITI1场景中配置项变更，一般是用户到流程平台或CMDB门户中去维护，流程重，体验差，导致数据质量不佳。正确的设计思路是把CMDB的位置嵌入到用户场景中最便捷的时间、地点中，降低数据消费门槛。因此CMDB应重点建设实时接口或页面API,以SOA方式嵌入到各种场景中，前端用户甚至感受不到CMDB的存在。我们可以弱化CMDB自身门户入口,成为纯后端平台，转而从外部场景工具中引入流量。调整流程约束的时间结构：流程的约束设计应尽量

16、从事后提前到事中解决。我们对用户在场景中的配置管理要求，通常以流程管控和数据审计的方式写入制度规范中。制度一般会安排多个角色：CMDB配置经理、CMDB维护人员、CMDB审计人员等等，兴师动众却效果一般，尤其是体制内的事后考核往往无法落实，难以有效保证数据质量，我们推荐事中进行“自审计”。举个例子，某个流程要求设备到货时某人某时刻录入CMDB,但执行人可能偷懒或者真的遗忘了，事后审计虽然形成闭环但效率低。更优的流程设计是把设备初验场景整合进流程里，如果没有录入CMDB则无法初验，流程在执行中就有人会跳出来拉响警报。请注意以往逻辑是业务先变更，再到CMDB登记，业务是因，CMDB是果。正确的思路把CMDB设计为某个业务活动的因，这样数据质量可以得到极大改善。下图为部分流程样例，把堡垒机申请、防火墙申请、设备部署、监控接入等业务活动都设计为依赖CMDB数据。3、引入数据资产的理念资产是能够给企业带来