很多的顾虑。因此，CMDB建设需要有敢于不断试错的勇气和环境和长期坚持的耐心。只有这样，才能在旧平衡被打破时，尽快的建立起新的平衡。
所以，CMDB成功的两个关键因素是：管理对象的规模和组织的执行力。华为的运维环境基本具备上述两个因素，但过程依然漫长和艰辛。如果不是每年能涨点工资，我很难相信自己能坚持下来。
后面几篇文章，我会简要介绍我在华为参与的CMDB建设历程，跟大家分享一下我的经验教训。
华为CMDB是如何炼成的华为CMDB的建设历程可以分为三个阶段：初创期、整合期和价值发挥期。（华为CMDB的三个建设阶段） 1初创期
2002年华为IT运维引入了ITIL流程，同时也一并引入了CMDB。那时我们并不知道CMDB该怎么用。但由于“先僵化、再优化、最后固化”的指导思想，我们完成了系统建设，
并成立了专职的配置管理团队。
2002年到2007年，是配置管理最尴尬的几年。当时每个技术管理部门都有自己的“自建库”。比如，机房管理部和网络部有设备表，X86管理部、Unix管理部也开发了自己的配置库。大家各玩各的，就是没人玩CMDB。大家普遍的说法是CMDB不准。因此，配置管理团队付出了巨大努力，比如，强化管控流程、定期开展数据审计等，但始终无法打开局面。 2整合期
故本文的事从2007年开始。那时，我已经在华为做了一年变更管理员，厌倦了天天盖戳的工作，我认为自己其实是一名程序猿，所以向陈总提出要调到开发部门的请求。陈总人很好，他告诉我CMDB大有可为，并果断给我涨工资。从此，我半推半就的走进CMDB的世界。 1
简单粗暴的方法-强制拆迁
我的想法很简单，只要那些自建库不存在了，大家就不得不玩CMDB了…所以，抱着大有可为、一统江湖的心态，我开始策划如何拆迁掉那些自建库。
在得到高层领导的同意后，我们开始了拆迁调研。经分析，技术管理部不愿意使用CMDB的原因有两个：
1. CDM不接地气，与各管理业务的数据模型不兼容 2. CMDB的易用性差
因此，我给出的拆迁补偿是：
1. 基于各业务的管理粒度重新设计配置模型 2. CMDB工具推倒重建，重点提升易用性。
当时国外CMDB产品很贵，买不起。所以在达成拆迁协议后，我和强叔联手自行开发。我们使用了当时最时髦的技术，目的是最大程度的提升用户体验。
在巨大热情的支撑下，我们很快就完成了系统开发。在宣传推广时，新CMDB也广受好评，因为基于Javascript富客户端技术的用户体验的确比之前基于Notes技术的老CMDB好太多了。
但在实际搬时遇到了困难，没有人真的愿意搬进来，还是更愿意使用原来的系统。理由有很多，比如，操作不太习惯啦，
**团队需要的一些特殊功能没有做啦。
好吧，记得Peter Thiel也说过，如果要在同质化的产品中赢得竞争，必须对已有的产品功能有10倍以上的提升。也许我们的自己的水平不行，达不到这个条件，那就买吧！于是，我们采购了国外一流厂商的CMDB。
但结果仍然不尽如人意。除了机房配置库、网络配置库由于是Excel表，在版本控制上存在问题，不得已搬入CMDB外，其他技术团队仍然在使用自己的配置库。
从此，我认为提升工具的易用性并不能帮助CMDB走出困境。原有分散的数据管理模式有其存在的理由，并已经形成了一种平衡。这种平衡不可能通过CMDB的强行介入来打破。为了建CMDB而建CMDB是注定失败的。
不过，虽然拆迁的效果不好，但在此过程中我们优化了配置模型，新的配置模型更接地气，能够与现有管理业务的管理粒度和数据结构兼容，为日后的系统对接打下了基础。 2