【重磅好文】前华为资深CMDB专家：我与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，能够驱动单流程的自动化运作以及多流程协同。图1 使用CMDB后的管理成本曲线

但是，新平衡不是自然建立起来的。人们大都不愿意主动改变原有的工作模式，即使愿意改变，对使用CMDB也仍然有