搜索
确认
取消

回归本质,重新认识CMDB ——CMDB项目建设思考

  • 发布时间:2021-08-17

回归本质,重新认识CMDB ——CMDB项目建设思考

【概要描述】本文对CMDB实践和知识的整理并结合自身的思考进行分享,主要围绕4个话题进行展开:理解CMDB、设计CMDB、实施CMDB和维护CMDB。

  • 分类:技术原创
  • 作者:
  • 来源:
  • 发布时间:2021-08-17 15:16
  • 访问量:
详情

这十几年来对于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项目建设的部分思考,欢迎一起交流和探讨。

为什么选择嘉为蓝鲸?

嘉为拥有强大的技术实力,深耕企业IT服务20年,充分掌握企业IT研发、运维、运营管理需求,为企业数字化转型提供建设思路。做为腾讯蓝鲸全国首家技术授权合作伙伴,嘉为与腾讯进行联合研发,将先进的蓝鲸技术体系在企业快速落地,让IT效能为企业创造无限价值!

研运至简,无限可为!

落地嘉为蓝鲸研发运营一体化平台,逐步实现自动化、数据化、智能化IT运营,实现数字化转型!

嘉为蓝鲸微信公众号

嘉为蓝鲸微信公众号

Copyright 广州嘉为科技有限公司版权所有 粤ICP备06004568号