某大型保险企业应用CMDB平台建设的实践经验.pdf

某大型保险企业应用 CMDB 平台建设的实践 经验 问题的提出 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 注定失 败。企业里一些原始管理手段的矛盾还没爆发时，请严格控制项目范围，摆正预期。要知道 你的作战对手有深厚的群众基础，生产力决定生产关系在这里同样适用。虽然这些自建库粗 糙