ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2021-05-23 23:51:33  阅读:224  来源: 互联网

标签:重新认识 生命周期 步骤 流程 信息 变更 思考 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。


1.png

【正文】

1       理解CMDB

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

1.1   CMDB基础概念

2.png


1.2   回归CMDB本质

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

3.png


1)   逻辑数据库、配置项信息和配置关系:这三个方面都比较好理解,而且也有了相对统一的认知,在此不过多的阐述;

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

a)   管理流程:缺少统一的电子化流程,在全生命周期中不同的阶段使用不同的流程,有纸质化流程的、有走OA流程的,也有走ITSM流程的;

b)   工具系统:缺少统一的工具系统,全生命周期涉及到监控、管理和控制的各个工具系统,这些系统仅仅存储了自身需要的片面信息,难以实现一体化;

c)   部门协作:部门之间的高效协作是数字化时代面临最大的挑战之一,全生命周期会涉及到跨多个部门的协作,包括财务、开发、测试、安全、运维等等。

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

4)   发挥价值:ITIL4指导原则的第一个就是专注于价值(Focus On Value),CMDB建设之前我们需要思考清楚CMDB的价值什么和怎么发挥价值;

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

a)   过于依赖自动发现和采集:首先,IT资源不可能实现100%的自动发现和采集;其次,自动采集的信息就一定是准确的吗;最后,自动采集到配置信息的变更如何识别是正常变更还是非正常变更?

b)   缺少配置管理流程和变更管理流程:ITIL的黄金法则之一——在没有完善的变更管理流程之前,不要建设CMDB。往往CMDB项目不长久或是数据不准确,很大部分的原因是缺少管理流程。

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

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

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

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

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

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

4.png


2       设计CMDB

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

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


 5.png

2.1   步骤3:定义CMDB支持场景

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

6.png


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

2.2   步骤6:定义配置项(CI)关系

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

1)   应用与应用:应用服务之间的调用关系,一般是通过APM和BPC等工具实现调用关系的发现;

2)   应用与基础设施:应用系统与所在的运行环境和基础设施的关系;

3)   应用与基础组件:应用系统与所依赖的数据库、中间件的关系;

 7.png


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

8.png


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

2.3   步骤7:定义配置项属性的管理

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

9.png

1)   仅继承上级(下图左):下级属性默认会继承上级的属性,只需在上级的基础上增加个性化的属性即可;

2)   仅继承顶级(下图右):下级属性仅继承顶级属性。


3       实施CMDB

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


 10.png

3.1   步骤7:定义数据填充顺序

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

11.png


3.2   步骤8:定义数据调和规则

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

12.png


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

3.3   步骤9:合并和标准化测试数据

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

1)   优先级规则:为不同的数据源分配不同的优先级权重;

2)   标准化规则:在调和活动之前,数据需要被标准化为CMDB所存储信息相符合的统一格式;

4       维护CMDB

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

13.png


4.1   步骤6:部署控制点

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

14.png


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

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

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

1)   识别CI分类在生命周期的每一个步骤;

2)   识别CI在每个步骤涉及哪些部门、岗位和人员;

3)   识别CI在每个步骤涉及哪些属性的更新

15.png


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

4.3   步骤9:设定度量与指标

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

1)   多维度统计信息:业务视角和管理视角的CI统计信息和变化趋势;

2)   未授权CMDB变更百分比:结合变更管理流程,记录未授权和授权的变更信息;

3)   CI完整性检查:

a)   通过IP网段扫描存活IP与CMDB数据库进行匹配;

b)   通过查询VM是否关联到宿主机;

16.png



【结尾】

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

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

17.png


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

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


标签:重新认识,生命周期,步骤,流程,信息,变更,思考,CMDB
来源: https://blog.51cto.com/stephen1991/2805577

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有