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

《(深度好文)重构CMDB，避免运维之耻》要点：
本文介绍了(深度好文)重构CMDB，避免运维之耻，希望对您有用。如果有疑问，可以联系我们。

• CMDB,几乎是每个运维人都绕不过去的字眼,但又是很多运维人的痛,因为CMDB很少有成功的,因此我也把它称之为运维人的耻辱.
• 那么到底错在哪儿了?该如何去重构它?
• 今天我想从我的角度来和大家探讨一下业务失败的原因,基于失败再去看重构的逻辑,也许会成功.

从失败中寻找成功的逻辑,往往是最有效的,那我们就来逐一看看：

1、组织的设计问题

我必须把核心原因归结成这一条,很多公司把CMDB的建设责任放到基础设施建设部门,由他们主导承建.最后他们梳理出来的核心逻辑是面向基础设施资源的管理,你在他们的CMDB中都能看到如下菜单,AIX主机是哪些,中间件有哪些,大小机有哪些,Oracle有哪些等等,这些都是和公司的IT运维部门组织结构是一一对应的.组织的隔离是CMDB失败的核心原因!

这个里面能看到一些CMDB管理能力错位,拿两个例子来说一下：

A、中间件.

一直搞不明白为什么中间件要作为一个单独的对象来管理,“皮之不存,毛将附焉”.没有主机,没有业务这个皮,哪来的中间件.把他单独拿出来管理,纯粹就是为了满足组织的一个管理视角.从来没人想过,这是主机上的一个资源对象,应该是一个附属资源,其实对他的信息管理和机器上的CPU、网卡一样.

B、进程对象,比如说数据库

这个是另外一种管理错位,是专业的管理平台应该去履行的管理职责,结果放到CMDB平台中了,然后CMDB管理了大量的动态属性,比如主备关系,服务状态等等,太复杂了.最简单的看,从主机的角度来说,他就是服务器上运行的一个进程而已.管它死活干嘛,那是监控系统做的事情,管它状态干嘛,那是**组件管理平台干的事情.

2、Excel是最好的管理工具

当组织隔离,不能够形成有效的信息互动之后,Excel更是之上的一次痛击.可能从外围思考,为什么不去解决现实层面上的问题,而选择了Excel?Excel很简单,特别是IT服务对象不多的情况下,几百个还是能够应对的.我就拿个Excel记录一下,然后svn上小组内共享一下就好了,反正我的信息也就我使用,别的小组也不用(组织的隔离性).对它的思考,还是要回归的第一点,使用Excel是结果,但我比较反对Excel做法.每次建设cmdb的第一个目标,就说要消灭掉Excel.

3、去简就繁

这个是从产品本身说的,我看了几个开源的产品,oneCMDB和iTOP(建议大家都体验一下),界面都是复杂的要命,还有商业的产品(具体哪家不说了).

首先必须要解决产品易用性的问题,易用性不够,你怎么让能用户有使用的欲望呢,以下是来自于UC做的CMDB系统产品截图：

其次还有一种信息复杂带来的易用性下降的问题.我看很多产品都管理了一些无光的信息,信息的管理归类也是有考究的,没归类好,用户又被淹没了.

拿主机来说,维护其核心需要的信息就好了,比如说固资编号、所在机房的位置信息、厂家信息、上架信息、进程端口信息、维护信息等等.这些信息都是有运维场景的,比如说位置信息+固资信息在驻场需要操作的时候有用；上架信息对于过保维修有用；进程端口对于监控有用；维护信息在运维申请资源的时候有空,谁也不想用经常故障的机器吧；主机状态位是用来做资源池管理+监控使用的.

很多配置的变更都是因为场景变更引起的,比如说机器搬迁导致机器的物理位置信息发生变化,那就搞一个机器搬迁流程吧；机器上的业务下线了,但进程信息没有清理,那是业务下线流程的问题….

5、和应用没有关联,更别提场景关联了,就更别提主动场景了

很有意思的现象：客户的监控系统中监控的应用主机信息都是该系统中自行维护的,从来没有考虑从CMDB获取.也就是因为CMDB是另外一家产品,为啥呢?如果资源和应用关联起来了,并且由他来驱动监控,这个维护的动力是不是不一样呢?

哪怕是你的CMDB系统能够支撑一下我上图中的工具盒子的能力,CMDB维护的动力不至于那么糟糕,它的数据也不至于那么糟糕.之前和人探讨过是先有操作系统安装把信息写到CMDB还是先有CMDB的信息然后再有操作系统安装的动作?当然是后者了.事实上在服务器采购分配上机架的时候,其实所有的信息都分配完毕,此时入库,就可以启动远程自动安装了.

其实还有很多原因,比如说物理世界和逻辑世界是独立的,物理世界发生的过程没法直接映射到CMDB系统中(有些配置信息需要进入固件中)；CMDB的对象Owner没有或者过多(Owner很累)；过分强调CMDB的基线作用,引入对比(动态变化的环境基线的作用应该下降)；夸大CMDB自动发现的作用等等.

说了很多的失败的原因,接下来就需要讨论一下解决方案了,既然讲重构,老王的重构逻辑是什么样的?

第一、重构你的CMDB思维

建议大家不要把CMDB称之为CMDB了,那叫什么,就叫资源管理吧.为什么你要从改名字开始?老是叫CMDB,大家都回到过去的思维上了,道不清说不明的,或者各执己见.

一切皆资源!!!一切皆资源!!!一切皆资源!!!

从基础设施的对象来说,计算资源、存储资源、网络资源、IP资源、机房资源等等,在CMDB的管理上,把你的资源对象罗列出来,关系梳理清楚,就可以构建其能力管理了.

从上层的业务资源来说,建立以应用为中心的资源管理逻辑,把 一切都看成应用的资源来看待.比如说Host,应用包、权限、RDS服务、cache资源等等.

老王现在做的产品把CMDB一分为二,底层的基础资源层CMDB可以不要.在不要的情况下,我可以构建上层应用的信息管理平台(业务CMDB),它可以独自构造场景来驱动上层运维.以下是优维EasyOps产品截图：

（编辑：ASP站长网）