冰与火之歌，华为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的建设历程可以分为三个阶段：初创期、整合期和价值发挥期。

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

2002年到2007年，是配置管理最尴尬的几年。当时每个技术管理部门都有自己的“自建库”。比如，机房管理部和网络部有设备表，X86管理部、Unix管理部也开发了自己的配置库。大家各玩各的，就是没人玩CMDB。大家普遍的说法是CMDB不准。因此，配置管理团队付出了巨大努力，比如，强化管控流程、定期开展数据审计等，但始终无法打开局面。

故本文的事从2007年开始。那时，我已经在华为做了一年变更管理员，厌倦了天天盖戳的工作，我认为自己其实是一名程序猿，所以向陈总提出要调到开发部门的请求。陈总人很好，他告诉我CMDB大有可为，并果断给我涨工资。从此，我半推半就的走进CMDB的世界。

CMDB终于被使用起来了，我们也找到了办法使数据也在使用过程中越来越准。下一步做什么呢？

CMDB向外围业务供数的模式，很像原材料出口。量大，但附加值低。能否再做一些加工，提升数据的附加值？

我首先想到的是数据分析。因为CMDB中记录了设备的开关机状态，我们通过计算设备的关机时间，发现出全球有几百台长期关机，却一直放在机房中的设备。

调查后才知道，海外很多地方的机房被当成库房用，大量无用的设备堆积在机房内，浪费了机房的空间容量。另外，我们通过关联关系分析，发现出很多开机的服务器没有关联任何应用系统。经调查发现，原来的应用已经下线或迁移了，这些服务器一直在“空转”。

之后，我们还做了很多其他的分析，也都有新的发现。看来，通过数据挖掘推动管理改进，是CMDB的新价值。需要注意的是，配置管理团队的职责不是天天挽起袖子去发现别人的问题，而是应该提供一个灵活的数据分析平台，让别人更好的发现自己的问题。

可视化是在我华为最后一年的尝试，当时想法很简单，CMDB跟其他数据库比，最有特色的地方是记录了完整的CI关系。而运维最重要的业务之一 --故障处理，就非常迫切的需要看到IT组件间复杂的关系。

可是，关联关系用传统的表格形式展现，很难让人理解，如果能以图的形式把CI关系展示出来，把分散的对象以人们习惯的架构图的形式组织起来，同时，在图中还能看CI的配置、性能、告警、变更、事件，那是多么有价值的事情！

于是，我和强叔再次操刀。我们用TWAVER开发了一个可视化系统，名字很响亮，叫CMS，它能够基于CI的关系自动生成架构图。

然而，实际的使用效果并不理想，原因是：

1、自动视图对关联关系的数据质量要求太高，虽然当时CMDB的数据质量总体上已经很不错，但关联关系的数据质量依旧是短板（很多关系无法发现，人工维护起来又很麻烦），导致很多架构图缺胳膊少腿；

2、自动视图中的CI粒度比传统架构图更细，有没有引入“容器”聚合细粒度的CI，技术人员看不懂（比如，传统架构图上，一台应用服务器对应一个图标。但CMDB生成的视图有三个图标，分别是中间件、操作系统、物理主机）；

3、架构图中的关系连线没有收敛，导致线条错综复杂，难看至极；

4、图的自动布局不太符合人们的视觉习惯。

由于后来离开了华为，所以没有把这件事继续下去。现在回想起来，还是积累了不少经验：

1、 架构图自动生成这件事，在现有的技术条件下非常难。架构图是需要一点点创造力和美感的，而程序很难有创造力，更别说美感了。而且架构图本身很复杂，比如两地三中心的架构布局，工具就很难按照人类的预期绘制出来。

2、 对用户更有用的，其实只是一张空白的画布，用户能够把CI拖入画布中，并自由的绘制和布局,就像画Visio一样。如果CI的关联关系缺失，没关系，直接画一条线出来就行了。

这些经验后来也得到了证实。

去年，优锘给华为提供了一套配置可视化产品，效果非常好，能够以自服务的方式快速实现大量交易流的可视化。项目结束后我们还收到了华为写的感谢信。

华为CMDB是相对成功的，因为我们从它身上挖掘出一些实实在在的价值，比如：

哎

1. 避免配置数据被重复维护，降低数据管理的总成本；

2. 共享同一套配置数据，使各运维业务对IT资产的基本配置情况达成共识，并驱动各流程的自动化协同；

3. 能够以CI为核心，拉通各个管理工具中孤立的数据，并通过面向管理场景的数据分析和可视化，使IT管理者能更加全面的掌握CI的运行状态和管理现状，提升管理的透明度。

即使全部掌握了上面的经验，也许仍然无法按照华为的模式建成一个CMDB。

为什么呢？

因为华为CMDB的主要客户是系统，而不是人。这种模式是侵入式的，会对原有的业务运作模式在短期内带来巨大冲击（业务效率会降低、成本会增多、风险会增加），必然受到抵制。

华为能按这种方式做成的根本原因是什么呢？其他组织又是否具备呢？

华为CMDB成长的土壤、条件、机遇和运气

很多人都知道华为有一句口号：“先僵化、再优化、最后固化”。这不仅仅是句口号，华为的确是这么做的。2001年，IBM的外国顾问引入了配置管理流程，并设置了专门的管理部门，但并没有讲清楚CMDB到底怎么用。

结果，在长达6年时间，配置管理事实上并未给运维带来多大的好处。虽然如此，华为仍然持续投入。那些年，配置管理部门始终保持3-7人的规模。正是这些人不断的尝试，不断的努力，才迎来了成功的机会。

另外，在2009年完成全球配置梳理后，为了保持数据的准确，几乎全部IT人员都动员起来了。只要有人出差，不管去全球哪个角落，都会帮我们检查当地的配置信息。甚至CIO周总也亲自下机房检查。

我还记得那几年周总每次出差前，都会问我们要一份当地机房的配置清单。当然，为了保持良好的合作关系，我会立即通知当地的机房管理员，赶紧自查！

华为IT资产的体量庞大，分布极广（在全球有几十万台设备，分布在几十个国家的一百多个机房），而运维人员只有几百人，大部分都在总部数据中心，这必然带来流程自动化的需求。

另外，2002年引入配置管理的同时，也引入了其他一系列ITIL管理流程。经过7-8年的完善，这些流程的标准化程度已经很高，具备了自动化的基础。

由于上述条件，使华为CMDB的潜力得以充分发挥。

全球化带来了管理要广覆盖的要求，使得各个管理业务自建配置库的数据维护成本陡然上升，不得不认真考虑“数据管理外包”。

第一个运气：在“和平”时期，配置管理团队独立完成全球配置数据梳理是不可能完成的任务。然而，在海外发生的意外使安全内控被空前重视。配置管理“手持”安全内控的“尚方宝剑”，人挡杀人、佛挡杀佛，奇迹般的在短时间内就完成了全球数据梳理。

第二个运气：基于以往的教训，即使CMDB完成了数据梳理，其他业务也不敢贸然使用，因为CMDB的第一个用户必然要消化掉存量的数据质量问题。幸运的是，当时账号安全管理部和配置管理部正好都归刘青管。

刘青一方面苦于CMDB没有消费场景，另一方面又面对账号管理要广覆盖的强大压力，那就把这俩宝贝撮合一下试试吧… 这也是为什么账号管理敢第一个“吃螃蟹”。

那么，为什么国内大部分公司做不成呢？ 因为他们很可能不具备这些条件。下面是一个对比：

所以，鉴于这些因素，我认为华为实施CMDB的方式很难复制，但并不是说华为之外的其它组织就做不成CMDB，在下一篇文章中我将尝试总结一些相对通用的CMDB建设经验，分享给还在与CMDB搏斗的各位同好。

通过成功的道路往往曲折艰难。建设CMDB也是如此。那些年，我们做了大量的尝试，有些成功了，有些失败了。抛开华为的特殊性，在这里总结一些通用的经验教训：

1. 拆迁不如搬迁

运维环境中已经存在的自建库，虽然粗糙，但有其存在的意义。贸然拆迁会有巨大的风险。比较保险的办法是保留原有的数据维护模式不变，只进行数据的复制搬迁。历史的经验也告诉我们，包产到户比人民公社更有效。

2. 配置模型要接地气

抑制设计完美配置模型的冲动。CI的粒度和关系要与当前的运维管理粒度一致。

3. 开放心态和数据分级管理

配置管理范围和CMDB管理范围是两回事。CMDB是一个大的数据管理舞台，有需要但没有合适管理工具的数据都可以放入CMDB中。但只有最重要的数据（如果错误会导致下游业务异常）才纳入配置管理。

4. 数据维护流程要简化

与其担心别人把你的数据改错，你更应该担心别人不愿更新数据。而复杂的审批流程，只会降低大家维护信息的意愿。

5. 保障数据的完整性

数据错了，可以在使用中被发现。但数据少了，是很难被发现的。同时，CMDB数据的完整性（就是家底）对于有广覆盖要求的业务有巨大的吸引力，因此要重点保障。

6. 数据消费要有反馈

如果无法捕捉反馈，就无法做到“在使用中促进数据准确”。

7. 可视化

可视化能够降低信息的理解门槛，也能够更好的暴露数据质量问题。是引爆消费、提升数据质量的重要手段。

8. 在初创阶段，要克制数据分析的冲动

CMDB高级阶段的能力，对数据量和数据质量的要求极高。在CMDB建设初期还是要务实一些，以与系统对接、供应原材料数据为主。

通向未来的路