华为专家谈CMDB建设.pdfVIP

华为专家谈CMDB建设

CMDB成功的关键因素

对于CMDB项⽬的失败，普遍的解释是：没有数据的消费场景、⼯具和技术不⾏、流程管控不⾜。

从我⾃⾝的实践来看，我对此是有不同看法的。上述原因的确会影响⼈们使⽤CMDB，严重时甚⾄会造成项⽬失败，但这不能解释普遍性的失败。其实每⼀个IT组织内部，

不管是专业技术团队还是流程和技术管理部门，都有⾃建的配置库（如，主机配置库、⽹络配置库、机房配置库……后⾯简称“⾃建库”）。

如果没有数据消费场景，哪来这么多⾃建库？同时，这些⾃建库的技术并不先进，甚⾄很粗糙，也没有管控流程，但依旧野蛮⽣长，⽤得好好的。为何它们有如此强⼤的⽣

命⼒，⽽投⼊众多先进科技（联邦、调和、可视化、流程引擎…）和严密管控流程打造⽽成的CMDB，却命如薄纸？

CMDB的失败不能简单的认为是消费场景、技术和管控流程的问题。⽽应该从成本和收益的⾓度考虑。

配置管理本质上是“数据管理外包”。抛开那些⾼⼤上的价值（趋势分析、影响分析、根源诊断…）不谈，它的“初始”价值是能够减少各管理业务重复维护数据的成本，从⽽使

这些管理业务更专注于本⾝业务能⼒的改进。

这个理念没问题，但实际上，各运维管理业务更倾向于在数据管理⽅⾯能够⾃给⾃⾜。这⾥有两个原因：

1、由于管理规模不⼤，所以各管理业务分头维护数据的成本并不⾼。

2、能够对数据拥有最强的掌控⼒，可以根据⾃⾝业务的变化灵活的调整数据模型，或是通过个性化的管理规则和功能设置，让⽤户更⽅便、更准确的输⼊信息。

这种⾃给⾃⾜的⼩农经济模式当然会有问题，⽐如，各领域的运维数据相互孤⽴、数据不⼀致以及总体数据维护成本偏⾼等等。但在特定的管理⽔平下，这种模式却是最有

效的，因为对数据的全⼒掌控能够带来变化的灵活性，并提升数据的准确性，只要成本能够接受，这种平衡将⽆法打破。

可是，如果使⽤CMDB这个“外包服务”呢？⾸先，失去了对数据的掌控⼒。CMDB不是你⼀个⼈的，不可能说改就改，总得统⼀规划吧。何况ITIL中也明确写了“对配置模型

的修改需提交配置委员会评审”。另外，你以为成本真的会降低吗？不⼀定的。初建的CMDB，数据质量不可能很好，如果贸然消费，很可能带来⼤量的数据纠错成本。

所以，CMDB不受欢迎的重要原因，是因为CMDB在建设初期往往使各运维业务对配置数据的掌控⼒反⽽下降了，⽽它所带来的成本降低，即便真实，在当前的管理规模下

也没有⾜够的吸引⼒，从⽽导致CMDB项⽬的推⼴和应⽤往往有很⼤阻⼒和困难，很多CMDB项⽬就都死在这个初级阶段上，⽆法向下推进。

那CMDB就没戏了吗？也不完全是。随着运维规模的扩⼤，数据维护成本会相应增⾼。当⾃给⾃⾜的管理模式难以⽀撑时，旧平衡将被打破，⽽新平衡的⽀点，将是

CMDB。

下⾯这张图，描述了使⽤CMDB后，对运维业务的成本改变情况。普遍情况是，运维业务的管理成本在短期内会提升（因为要进⾏数据纠错），但长期会下降。⽽运维的标

准化程度越⾼，成本会下降得越快。因为标准化的流程具备更明确的输⼊和输出，通过CMDB，能够驱动单流程的⾃动化运作以及多流程协同。

图1使⽤CMDB后的管理成本曲线

但是，新平衡不是⾃然建⽴起来的。⼈们⼤都不愿意主动改变原有的⼯作模式，即使愿意改变，对使⽤CMDB也仍然有很多的顾虑。因此，CMDB建设需要有敢于不断试错

的勇⽓和环境和长期坚持的耐⼼。只有这样，才能在旧平衡被打破时，尽快的建⽴起新的平衡。

所以，CMDB成功的两个关键因素是：管理对象的规模和组织的执⾏⼒。华为的运维环境基本具备上述两个因素，但过程依然漫长和艰⾟。如果不是每年能涨点⼯资，我很

难相信⾃⼰能坚持下来。

后⾯⼏篇⽂章，我会简要介绍我在华为参与的CMDB建设历程，跟⼤家分享⼀下我的经验教训。

华为CMDB是如何炼成的

华为CMDB的建设历程可以分为三个阶段：初创期、整合期和价值发挥期。

（华为CMDB的三个建设阶段）

1初创期

2002年华为IT运维引⼊了ITIL流程，同时也⼀并引⼊了CMDB。那时我们并不知道CMDB该怎么⽤。但由于“先僵化、再优化、最后固化”的指导思想，我们完成了系统建设，

并成⽴了专职的配置管理团队。

2002年到2007年，是配置管理最尴尬的⼏年。当时每个技术管理部门都有⾃⼰的“⾃建库”。⽐如，机房管理部和⽹络部有设备表，X86管理部、Unix管理部也开发了⾃⼰的

配置库。