CMDB项目建设思考

这十几年来对于CMDB的理解众说纷纭，特别是近5年来，业界针对CMDB提出了很多新的概念，比如：重新定义CMDB、以应用为中心的CMDB、企业级CMDB和面向消费场景的CMDB等等。

之前我对于CMDB的定位、理解和建设也有些许困惑，我去年深度阅读了由BMC中国公司翻译的书籍《CMDB分步构建指南》（英文原版《Step-by-Step Guide to Building A CMDB》由BMC美国公司编写），再加上这几年和客户、业界大咖的交流探讨，个人对于CMDB的建设有了进一步的理解，现通过对书籍内容的整理并结合自身的思考进行分享，主要围绕4个话题进行展开：理解CMDB、设计CMDB、实施CMDB和维护CMDB。

理解CMDB

近十几年来，大部分企业均已建设了CMDB，但还是缺少对CMDB的统一认知。我们就先从CMDB的基础概念和本质重新思考和理解CMDB。

01 CMDB基础概念

02 回归CMDB本质

从CMDB基础概念定义中，我们提取出了8个关键词，用来认识CMDB的本质。

逻辑数据库、配置项信息和配置关系：

这三个方面都比较好理解，而且也有了相对统一的认知，在此不过多的阐述；

全生命周期：

包含全生命周期的配置信息（例如一台物理服务器从进入机房开始到投入使用，最后下线的整个生命周期）在这点上还是有很多企业难以做到的，个人认为主要有三个方面的挑战：

管理流程：缺少统一的电子化流程，在全生命周期中不同的阶段使用不同的流程，有纸质化流程的、有走OA流程的，也有走ITSM流程的；
工具系统：缺少统一的工具系统，全生命周期涉及到监控、管理和控制的各个工具系统，这些系统仅仅存储了自身需要的片面信息，难以实现一体化；
部门协作：部门之间的高效协作是数字化时代面临最大的挑战之一，全生命周期会涉及到跨多个部门的协作，包括财务、开发、测试、安全、运维等等。

支持流程：

有句话说“CMDB是数据管道、ITSM是流程管道”，CMDB支持ITSM流程的运转，并于流程所经之处在CMDB留痕，从而实现全生命周期的信息记录和审计；

发挥价值：

ITIL4指导原则的第一个就是专注于价值（Focus On Value），CMDB建设之前我们需要思考清楚CMDB的价值是什么和怎么发挥价值；

依赖流程、数据准确性：

CMDB的建设至少需要包括数据库、配置采集和配置管理流程3个方面，而配置管理流程是最为关键的，但也是最容易被忽略的。我见过一些企业建设了配置数据库，并通过配置采集暂时保障了数据的准确性，然而随着时间的推移，数据的准确性急速下降，我认为主要有2个方面的原因：

过于依赖自动发现和采集
首先，IT资源不可能实现100%的自动发现和采集；其次，自动采集的信息不一定是准确的；最后，自动采集到配置信息的变更如何识别是正常变更还是非正常变更？
缺少配置管理流程和变更管理流程
ITIL的黄金法则之一——在没有完善的变更管理流程之前，不要建设CMDB。往往CMDB项目不长久或是数据不准确，很大部分的原因是缺少管理流程。

03 为什么需要统一的企业级CMDB

在运维管理工具中，我们可以大致分为3类：监控类、管理类和操作类。在这些管理工具中都存储了一些配置信息，监控类包含了主机名、内存、CPU等信息；操作类包含了IP地址、操作系统、登录方式等信息；管理类包含了主机别名、负责人、SLA等信息；这些管理工具的信息看起来似乎已经足够支持工具本身的使用了，那我们为什么还需要统一的企业级CMDB呢？

- 缺少“物”的唯一标识
  监管控的系统存储的唯一标识是不太一致的，比如Zabbix监控就以主机名来标记的，操作类的可能以IP地址来识别的，管理类的可能以别名来标记的；

缺少“物”的完整信息
每个工具系统仅存储自身所需要用的片面信息；

缺少“物”的关系信息
IT对象的关系信息同样分散在多个平台。

在IT运维管理中的核心就是具体的“事”，而“事”的对象是“物”，如果缺少统一的“物”的视角，更不用谈具体的“事”了。在数字化时代IT管理的“物”就是“业务”，那么如何建立“业务”的视角，实现“业务”的IT管理？——为IT管理对象建立一个身份证和户籍系统。

设计CMDB

在对CMDB有了统一认知和定位后，我们就可以着手开始设计CMDB了。往往很多企业在开始确定了CMDB厂商后才开始CMDB的设计，这点我个人是不建议的；我认为更佳的方式是在选择CMDB厂商之前就应该根据企业的真实情况做好设计，当然在这个阶段可以引入外部专家和顾问。

为此我整理设计CMDB的10个步骤，考虑到篇幅我仅选择我认为比较重要的3个步骤进行阐述。

01 步骤3：定义CMDB支持场景

我们需要在项目一开始就确定CMDB支持的场景和流程，然后才是考虑CMDB需要纳管哪些配置信息，小步快跑，而不是一开始就将所有数据都纳入CMDB的管理。

这里需要谨记的是：永远不要停止确定利益相关者的工作和需求，应该综合考虑不同部门和不同岗位对CMDB的需求。

02 步骤6：定义配置项（CI）关系

从应用视角，我们可以把IT资源的关系分为三类：

应用与应用：
应用服务之间的调用关系，一般是通过APM和BPC等工具实现调用关系的发现；
应用与基础设施：
应用系统与所在的运行环境和基础设施的关系；
应用与基础组件：
应用系统与所依赖的数据库、中间件的关系。

业界的CMDB厂商都提供了多种CI关系类型，包括：依赖于、运行于、属于、安装于、包含等等。值得注意的是：过多的关系类型可能会无法控制，不容易被用户所理解。

正如上图的例子，虚拟机与VMware宿主机的关系应该属于哪一种？你会发现无论使用哪一种似乎都是正确的，所以我们建议是将关联关系进行简化为2种——父子关系和连接关系。

03 步骤7：定义配置项属性的管理

在管理配置项属性时会发现一些属性是通用的，比如：IP地址、所属系统和管理员等，我们可以通过属性继承的方式来简化属性的管理。书籍《CMDB分步构建指南》提到了简化配置属性管理的2种继承方式。

- 仅继承上级（下图左）：下级属性默认会继承上级的属性，只需在上级的基础上增加个性化的属性即可；

仅继承顶级（下图右）：下级属性仅继承顶级属性。

实施CMDB

通过CMDB的理解和设计形成标准规范和准则，那么在实施阶段就是水到渠成的事情了，同样我也是整理了10个步骤来完成CMDB的实施工作。在此，选取3个步骤进行阐述。

01 步骤7：定义数据填充顺序

数据填充顺序遵循的基本原则是：优先纳管容易发现的数据；其次是集成现有的系统来更新数据；最后对于复杂的组件先放一放，后期处理。

02 步骤8：定义数据调和规则

“物”的唯一标识在数据调和阶段就发挥作用了，需要通过唯一标识识别不同的数据源，再根据数据源的优先级进行调和。

需要注意的是，CMDB系统上线后，我们不建议将采集到的数据自动录入到CMDB数据库中（首次录入除外），一方面是采集不代表就是准确的；另一方面，单靠采集我们无法识别是授权的变更还是非授权变更。

03 步骤9：合并和标准化测试数据

合并和标准化测试数据，主要需要考虑2个方面的规则；

优先级规则：

为不同的数据源分配不同的优先级权重；

标准化规则：

在调和活动之前，数据需要被标准化为CMDB所存储信息相符合的统一格式。

维护CMDB

CMDB实施阶段的质量决定了CMDB建设完成后的数据准确性，但要保证CMDB长久有效和准确，CMDB配置维护流程和体系的建设就极为重要了。在此，我选取维护阶段的3个步骤进行阐述。

01 步骤6：部署控制点

在配置信息录入CMDB数据库之前，有没有一种实践可以来做数据的双重校验和核对？——部署控制点，应该部署检查和控制点以确定收集到的数据的准确性和完整性。

例如对于变更的场景，只有在变更流程的信息和自动采集到的信息一致时，才能认为是正常的变更（或计划内变更），此时才能更新CMDB数据；否则将视为非正常变更，形成差异报表供手工确认。

02 步骤7：实现每个CI分类的生命周期管理

回顾文章开始CMDB的概念，CMDB是包含全生命周期的配置信息的，识别全生命周期的配置信息可以分为几个步骤：

识别CI分类在生命周期的每一个步骤；
识别CI在每个步骤涉及哪些部门、岗位和人员；
识别CI在每个步骤涉及哪些属性的更新。

ITIL最佳实践之一：越接近生命周期的开始，获得的利益越大。这个很好理解，DevOps在2009年刚提出来的时候更多是关注在开发（Dev）和运维（Ops），而现在已经扩展到BizDevSecTestOps,更加接近于业务端到端的全过程管理。

03 步骤9：设定度量与指标

要想持续改进和优化CMDB数据质量，我们得先度量它，定义CMDB质量相关的度量指标，并形成统计报表。

多维度统计信息：

业务视角和管理视角的CI统计信息和变化趋势；

未授权CMDB变更百分比：

结合变更管理流程，记录未授权和授权的变更信息；

CI完整性检查：

通过IP网段扫描存活IP与CMDB数据库进行匹配；
通过查询VM是否关联到宿主机；

总结

没有“万能药”，但指导原则和模型是有的

以前我还在思考有没有标准的通往成功的职业道路规划，当然这是不可能存在的。CMDB的建设也是如此——没有“万能药”。但我们可以借鉴业界实践、指导原则和模型，并结合企业自身情况，找到属于自身的道路和方法。

上图是ITIL 4指导原则和持续改进模型的映射表格，在采用改进模型的同时遵循7大指导原则。

以上是我个人对于CMDB项目建设的部分思考，欢迎一起交流和探讨。

原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/aiops/303281.html