写在前面

CMDB是什么?

简单来说,就是为互联网企业或者公司,统一管理IT数据,设备状态,资产等信息的一个平台。CMDB和真正意义的资产系统还有一定区别,它本身不仅包含了资产系统,还跟所有服务支持和服务交付流程都紧密相联。为整个ITIL流程的运转提供数据基础,并发挥配置信息的价值。所以一个成功的CMDB系统对于一个企业来说好处是巨大的。

设计目的

车之家的CMDB是什么?它用来解决什么问题?经过了几次不成功的因为CMDB而CMDB的开发后,我们清空了自己的大脑,痛定思痛,静下心来仔细的想了想工作中遇到的问题,总结了以下几点:

1. 随着公司运营规模的扩大,所使用的各种设备数量变的非常庞大,机器种类繁多,审计成本成倍增加,统计困难,盘点耗时耗力,急需一个统一平台来管理和收集。

2. 随着公司运维自动化的发展,出现了发布系统,配管系统,监控系统,工单系统,设备利用率系统等的数据孤立,不一致,都要单独维护加高成本等问题。急需整合所有数据,打通一个底层数据平台,方便以后的扩展和维护。

3. 由于各种原因,导致有些工作操作原始,管理无序,重复量巨大但产出价值不明显,需要定制一个适合自己,方便使用的系统,来减少工作量,提高效率和产值。

如上所述,目的也就出来了:一个数据高度集中,替代表格,减少重复工作,服务于运维人员的资产配置管理系统。

设计的方向,核心思路以及功能

方向:高度准确性,高度可用性,高度自动化

• 准确是所有数据的基础,一切目的的前提,CMDB的所有给出数据必须保证准确并且有效。

• 可用性是根本,再好再强大,没有人用也是不行,要了解数据的消费场景,了解用户的使用重点和习惯,接受用户反馈并持续优化是没有止境的。

• 自动化保证了时间和人力的高效,是从成本和收益上衡量CMDB成功的关键。

那么CMDB怎么样才能保证方向正确?解决所有问题的关键是什么?

核心思路:流程管控

流程的本质是解决变更带来的一系列问题.
通过一个自动化的可重复的流程来管理变更,使得发生变更时,有一个准确的流程去执行。并且预测这个变更对整个系统产生的影响,并对影响进行评估和控制。是CMDB解决所有问题的关键。

当方向和核心解决以后,我们的CMDB功能设计就清晰了

1. 整合功能:将现有的多个数据源合并至一个视图中,生成一个统一完整的数据报表。

2. 自我调和功能:保证CMDB中记录的多个数据源没有重复差异现象,维持CMDB中各个字段的数据完整性。

3. 同步级联:CMDB中的信息能够反映更新情况,并对数据在各个子系统中进行协调统一。

4. 权限分级:具备各种情况,各类条件下人员增删改查权限的分配功能。

5. 可视化功能:降低信息的理解门槛,直观的了解数据变更带来的各种影响。

平台展示

1.资产管理平台

图1
图2 

上面的图1 图2 是资产数据页面的展示。
车之家这边分出了35个字段,主要满足日常的查询,各种数据的统计,审计备案等工作。

关于CMDB各个字段颗粒度问题:

1. 颗粒度的粗细跟该公司运维整体能力和人力成正比。

2. 管理需求决定这些颗粒度的粗细,大而全的数据覆盖要考虑维护成本。

3. 数据价值产出跟颗粒度的粗细不一定是正比,但是要保证有随时扩展的能力。

4. 所有字段无论颗粒度粗细,都要在流程中找到相应的位置。

2.流程管控平台

车之家流程管控主要包括4个方面:初始化数据(录入),数据变更(状态机),数据价值(报表系统),数据审计(工单查询)。

想设计一个“All weather & Flawless”的管控流程,来保证所有数据的准确,要从先 明白设备的生命周期跟CMDB之间的联系,如图: 

根据设备的生命周期的联系图,我们定义了状态机,来反映数据变更后导致的一系列变化。如图:

通过状态之间的转变,我们规定一些必有的字段保证数据的准确:

并通过这个变化,来获取一些我们需要的信息:

当然,单个自动化流程只是第一步,CMDB做为整个运维自动化的底层数据平台,将对整个流程起到连接引导作用,实现多流程协同工作,端对端完成,为运维自动化体系奠定基石,示意图如下:

3.其他功能平台

Ip池管理:对IP资源进行了统一的归纳,针对IP目前现状,我们定义了三种使用状态,并在后台针对全网络IP情况做了一个统一的验证程序,结合三种状态,合理的分配和使用IP资源,示意图: 

机房视图:针对资产列表中的数据,在机房视图这个功能中直观的体现了出来,并提供了可用机柜,机位查询,特定搜索条件下机位机器高亮显示等功能。如图:

还有一些针对我们自身业务的定制功能,权限,特有字段等这里就不一一演示了。

总结

车之家的CMDB,陆陆续续也已经有2年时间了,通往成功的道路都是充满了荆棘与坎坷,建设CMDB也是如此。这两年,我们看了许多资料,也做了许多尝试,有些成功了,有些失败了。这里分享一些通用的经验教训给大家:

教训:

1. 开始搭建的时候没有一个项目真正的负责人,开发和需求之间沟通不够。

2. 初始目标过大,涵盖了太多功能,导致项目主次不分明,工期过长。

3. 运维和运维研发的目标不一致,讨论,测试,验收,后期优化等步骤不完善或 者运维没有参与。

4. 最核心的流程问题没有抓住,或者考虑不周到。

5. 没有收集反馈或者收集反馈后,没有跟踪人。

6. 妥协,著名的直线变曲线问题。

经验:

1. 领导层对时间,人力,资源的承诺。

2. 挥动所有能指派的力量去核对数据,各种历史问题,难点痛点都要解决。

3. CMDB只是一个系统,而配置管理是一个流程,CMDB固然重要,但是维持它的流程更为重要,所以要想设计一个好的CMDB,必须站在全局的角度先设计一套适合自己公司的流程。

4. 建立标准化,平台化,不可脱离CMDB。

5. 在高可用方面要做到精益求精,“找的到,用的着”才能使CMDB延续。