长文重构CMDB,避免运维之耻.pdf

长文 重构 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 （建议大家都体验一下） ，界面都是 复杂的要命，还有商业的产品（具体哪家不说了）