冰与火之歌，华为 CMDB 是如何炼成的

每次读到配置管理相关的书籍时，我总在想：“这些定义很精准，流程也很完整，但这不是真正的难题。”

对于一个配置管理者来说，真正的难题不是绘制“庞大而精美”的数据模型，不是设计“全天候、无死角”的管控流程，而是如何促进数据的消费，并在消费过程中持续的改善数据质量。

我在华为从事了七年配置管理工作，见证了 CMDB 从一个半死不活的边缘系统逐渐成为运维的核心。

离开华为后，我有机会看到很多 CMDB 项目，才发现原来像华为这样将 CMDB真正当成运维中重要一环的并不多。大部分CMDB项目，不是以失败告终，就是在失败的边缘苦苦挣扎。

这引发了我的思考。为什么 CMDB 普遍失败？华为的做法有可复制性吗？有没有更好的实现模式？

CMDB 成功的关键因素

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

从我自身的实践来看，我对此是有不同看法的。

上述原因的确会影响人们使用CMDB，严重时甚至会造成项目失败，但这不能解释普遍性的失败。其实每一个IT组织内部，不管是专业技术团队还是流程和技术管理部门，都有自建的配置库（如主机配置库、网络配置库、机房配置库……下面简称“自建库”）。

如果没有数据消费场景，哪来这么多自建库？同时，这些自建库的技术并不先进，甚至很粗糙，也没有管控流程，但依旧野蛮生长，用得好好的。

为何它们有如此强大的生命力，而投入众多先进科技（联邦、调和、可视化、流程引擎等）和 严密管控流程打造而成的 CMDB，却命如薄纸？

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

配置管理本质上是“数据管理外包”。抛开那些高大上的价值（趋势分析、影响分析、根源诊断…）不谈，它的“初始”价值是能够减少各管理业务重复维护数据的成本，从而使这些管理业务更专注于本身业务能力的改进。

这个理念没问题，但实际上，各运维管理业务更倾向于在数据管理方面能够自给自足。这里有两个原因：

1.由于管理规模不大，所以各管理业务分头维护数据的成本并不高。2.能够对数据拥有最强的掌控力，可以根据自身业务的变化灵活的调整数据模型，或是通过个性化的管理规则和功能设置，让用户更方便、更准确的输入信息。这种自给自足的小农经济模式当然会有问题，比如，各领域的运维数据相互孤立、数据不一致以及总体数据维护成本偏高等等。但在特定的管理水平下，这种模式却是最有效的，因为对数据的全力掌控能够带来变化的灵活性，并提升数据的准确性，只要成本能够接受，这种平衡将无法打破。

可是，如果使用CMDB这个“外包服务”呢？首先，失去了对数据的掌控力。

CMDB不是你一个人的，不可能说改就改，总得统一规划吧。何况 ITIL 中也明确写了“对配置模型的修改需提交配置委员会评审”。另外，你以为成本真的会降低吗？不一定的。初建的CMDB，数据质量不可能很好，如果贸然消费，很可能带来大量的数据纠错成本。

所以，CMDB不受欢迎的重要原因，是因为CMDB在建设初期往往使各运维业务对配置数据的掌控力反而下降了，而它所带来的成本降低，即便真实，在当前的管理规模下也没有足够的吸引力，从而导致 CMDB 项目的推广和应用往往有很大阻力和困难，很多CMDB项目就都死在这个初级阶段上，无法向下推进。

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

下面这张图，描述了使用 CMDB 后，对运维业务的成本改变情况。普遍情况是，运维业务的管理成本在短期内会提升（因为要进行数据纠错），但长期会下降。而运维的标准化程度越高，成本会下降得越快。

因为标准化的流程具备更明确的输入和输出，通过CMDB，能够驱动单流程的自动化运作以及多流程协同。

但是，新平衡不是自然建立起来的。人们大都不愿意主动改变原有的工作模式，即使愿意改变，对使用CMDB也仍然有很多的顾虑。因此，CMDB建设需要有敢于不断试错的勇气和环境和长期坚持的耐心。只有这样，才能在旧平衡被打破时，尽快的建立起新的平衡。

所以，CMDB成功的两个关键因素是：管理对象的规模和组织的执行力。华为的运维环境基本具备上述两个因素，但过程依然漫长和艰辛。如果不是每年能涨点工资，我很难相信自己能坚持下来。

后面几篇文章，我会简要介绍我在华为参与的 CMDB 建设历程，跟大家分享一下我的经验教训。

华为 CMDB 是如何炼成的

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

1 初创期

2002年华为IT运维引入了ITIL流程，同时也一并引入了CMDB。那时我们并不知道CMDB该怎么用。但由于“先僵化、再优化、最后固化”的指导思想，我们完成了系统建设，并成立了专职的配置管理团队。

2002年到2007年，是配置管理最尴尬的几年。当时每个技术管理部门都有自己的“自建库”。比如，机房管理部和网络部有设备表，X86管理部、Unix管理部也开发了自己的配置库。大家各玩各的，就是没人玩CMDB。