(深度好文)重构CMDB，避免运维之耻(2)

随着应用相关的一些支撑资源云化之后,面向应用的资源管理能力要不断加强.我经常和大家举的一个例子,是IaaS公有云平台中的Mysql实力已经是一个资源对象：实例域名.如何实现的对他们的管理,你只能把他当成一个附加资源来进行管理,不是么?

此时有意义的事情来了,你管理的业务资源信息越丰富,你的自动化驱动能力就越强.别再绕回去了,说让自动化来帮我维护这些信息.相辅相成、互相促进的事情,就不该设定前提,而是关注那个上升式的过程.

第二、重构你的CMDB方法

标准的CMDB方法是教你如何迭代进行一个CMDB项目,这个没有错误,但我会指出有些方法是你必须要坚持的,否则你的系统会面临失败.

A、放弃你的excel

excel是一个CMDB失败的佐证,必须去除它的存在,很多时候大家说是系统不好用引起的,但我的观察是大家的习惯引起的.改变习惯很难,有些时候需要借助组织自上而下的力量.没有集中的平台依赖,平台是没有人去驱动优化的.

B、构建CMDB的微内核和弹性CMDB模型库

CMDB的微内核很小,其实你只需要应用、集群和主机三个概念就可以构建起一个CMDB,基于这三个概念,可以不断去向周边扩散.应用可以往用户侧的概念不断靠拢,形成业务的概念.主机可以在其关联或者拥有的资源上不断去扩展,比如说主机所在的机柜、机柜所在的机房、机器关联的交换机等等.

这个微内核,我想是可以适用一切场景了,但还不够呢,如何保证这个模型对所有企业做到落地可适配的?这个时候就是弹性模型的作用了.弹性模型由对象的弹性和对象CI及其关联的弹性定义实现的.简单的理解,你就是实现了一个业务数据库的可视化定义,下图是对象的弹性定义：

下图是对象的CI及其关联关系的弹性定义：

C、构建“自动发现+标准流程+人工维护”的CMDB数据库

自动发现是降低维护成本的一种有效方式,但我认为确保一个CMDB库信息的有效性,还是需要其他几个手段,标准化的流程和人工维护.

标准化的流程是运维资源信息变更的场景化流程梳理,比如说机房搬迁,服务器搬迁,服务器下架等等,这个流程需要识别出来,并确定相应的CMDB配置项状态变更过程.

人工维护,在有些流程没有构建起来的情况下,则需要通过人工变更的能力把CMDB信息维护准确,比如说主机所属负责人变更,这个时候不建议流程了,可以通过人工直接变更完成.那如何确保维护准确呢?通过外围系统来控制,比如说告警信息,如果负责人没有变更告警是直达原有负责人,导致告警不准确.

D、CMDB是持续迭代的过程

贪大求全求细、一步到位都是它的反义词,建议以微内核和核心需求为中心,快速实现,然后在此基础上快速迭代.随着底层云平台的出现,对CMDB都提出了新的要求,我们都知道,每一个IaaS都有一个自己的CMDB,如何实现对IaaS云的CMDB管理?Docker和其他类似服务化平台出现之后,又如何实现这类资源的管理?

E、边界、边界、边界

CMDB实现拓扑是为了故障定位,但不能实现故障定位；CMDB实现资源管理,可以去评估故障影响,但不能实现故障和变更影响评估；CMDB实现业务拓扑是为了快速的故障定位,但不能实现故障根因分析；一切都是因为在CMDB提供的数据基础之上,周边系统(变更、监控、发布)借助的CMDB提供的数据能力,实现自身的场景化系统能力.

第三、重构你的CMDB组织

围绕业务能力重构你的CMDB!!!

分离CMDB建设的层次和结构,独立建设不是没有可能,至少应该分离出两个CMDB系统–面向基础设施的资源管理系统和面向业务的资源管理系统.

面向基础设施的资源管理系统可以由数据中心的同事来建设,而面向业务的资源管理系统是由应用运维部门来构建.

这两者没有先后之分,当然如果有底层的基础设施的资源管理,在其上构建业务的资源管理系统之后,数据的关联性会更强一些.

如果在两个职能管理分离的组织中,这个独立建设的必要性就更强了.比如腾讯,CMDB就是分两层的,一层是有网络平台部建设的面向基础资源的CMDB管理平台,另一层是业务的CMDB(是否叫CMDB已经不重要了),是各个业务部门建设的.

第四、重构你的CMDB产品形态

建立面向应用的资源管理CMDB!!!

核心是面向应用的CMDB产品思路要发生重大变化,仅仅聚焦在资源管理是远远不够的,资源是静态的.必须要建立一个逆向思维,不要从资源的角度维护资源,而是从应用的角度来维护资源.主机是什么?是应用的一个资源；Docker是什么?可以看成应用的附属资源；PaaS平台中分布式RDS服务是什么?是应用的附加资源等等.

这个形态要突出应用的核心位置,并以此为核心打造CMDB的管理入口,把资源管理、应用的场景维护等能力紧密集成起来.

第五、重构你的CMDB服务场景

经常大家都在说CMDB场景化,那真正的场景化到底是什么?

• 基于流程的场景识别

这是最传统的场景识别方式,通过ITIL认识到IT服务管理的核心流程,这些流程其实就是运维的场景.这个场景还有两个方面需要改进,第一在企业落地的过程中要结合实际,细分成一些核心流程；第二,具体的场景流程需要基于角色进行分类细化,比如说网络运维、服务器运维、机房运维、业务运维等等.

• 基于服务化的场景识别

（编辑：ASP站长网）