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

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

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

简单粗暴的方法-强制拆迁

我的想法很简单，只要那些自建库不存在了，大家就不得不玩CMDB了…所以，抱着大有可为、一统江湖的心态，我开始策划如何拆迁掉那些自建库。

在得到高层领导的同意后，我们开始了拆迁调研。经分析，技术管理部不愿意使用CMDB的原因有两个：

1. CDM不接地气，与各管理业务的数据模型不兼容

2. CMDB的易用性差

因此，我给出的拆迁补偿是：

1. 基于各业务的管理粒度重新设计配置模型

2. CMDB工具推倒重建，重点提升易用性。

当时国外CMDB产品很贵，买不起。所以在达成拆迁协议后，我和强叔联手自行开发。我们使用了当时最时髦的技术，目的是最大程度的提升用户体验。

在巨大热情的支撑下，我们很快就完成了系统开发。在宣传推广时，新CMDB也广受好评，因为基于Javascript富客户端技术的用户体验的确比之前基于Notes技术的老CMDB好太多了。

但在实际搬时遇到了困难，没有人真的愿意搬进来，还是更愿意使用原来的系统。理由有很多，比如，操作不太习惯啦，**团队需要的一些特殊功能没有做啦。

好吧，记得Peter Thiel也说过，如果要在同质化的产品中赢得竞争，必须对已有的产品功能有10倍以上的提升。也许我们的自己的水平不行，达不到这个条件，那就买吧！于是，我们采购了国外一流厂商的CMDB。

但结果仍然不尽如人意。除了机房配置库、网络配置库由于是Excel表，在版本控制上存在问题，不得已搬入CMDB外，其他技术团队仍然在使用自己的配置库。

从此，我认为提升工具的易用性并不能帮助CMDB走出困境。原有分散的数据管理模式有其存在的理由，并已经形成了一种平衡。这种平衡不可能通过CMDB的强行介入来打破。为了建CMDB而建CMDB是注定失败的。

不过，虽然拆迁的效果不好，但在此过程中我们优化了配置模型，新的配置模型更接地气，能够与现有管理业务的管理粒度和数据结构兼容，为日后的系统对接打下了基础。

全球化的机遇-全球数据整合

先说一个小背景：华为IT运维管理主要分成两个部分，系统运行管理部和区域IT管理部。系统运行管理部负责数据中心运维，特点是：人员专业性较强，并建立了完善的运维流程体系和管理工具。区域IT管理部负责海外机房的运维，特点是：机房量非常大，流程不健全，也缺乏管理工具。

2008年的春天，海外发生了一起安全事件，事后追查，发现这些服务器没有纳入系统运行管理部的安全管控范围。于是，华为IT开始推进全球统一运维，所有国家、所有机房，均纳入系统运行管理部的流程管理体系。

全球化带来的直接后果，是各个运维管理部门的数据维护成本陡然上升。以前只需要搞清楚数据中心内部这点家底就行了，现在要搞清楚全球几十个国家、一百多个机房中的软硬件配置信息，这几乎是不可能完成的任务！

于是，大家把目光转向了配置团队：你们不是专业做数据的嘛，这事你们就担了吧。没问题！（我耳边响起刘德华的歌“盼了好久终于盼到今天”）

于是我们手持安全内控的尚方宝剑，花了半年时间，顺利的完成了全球IT资产的梳理并整合进CMDB。

这对CMDB有里程碑的意义。虽然CMDB在“准确性”和“灵活性”方面无法超越自建库，但这一次，CMDB终于在数据的“完整性”方面完胜群雄。

有了全球家底数据，各管理业务开始体现出对CMDB的兴趣，开始定期和CMDB进行数据核对，并发现了大量遗漏管理的设备。从此，CMDB逐步从运维的边缘逐步走向核心。

冒险的尝试-流程自动化

起初，CMDB与外围管理业务进行半自动的数据核对，输出遗漏管理的对象清单后，提给各外围业务处理。但老这么干太费劲。于是，我们开展了流程自动化的工作。

首先尝试的是账号管理，因为全球有海量的账号需要回收，人工成本极高。我们先进行了自动开单，当账号管理系统从CMDB中识别到未回收口令的CI时，可自动触发批量口令回收工单。试点效果很好，大大提升了账号回收效率。

大家的信心增强了，于是我们进行了更大胆的尝试：账号管理系统基于CI属性自动识别口令回收脚本，并触发脚本执行。我们的实践再次取得成功，账号管理从此轻松实现了百万级口令自动回收，领导再也不用担心口令没回收啦！

账号管理实验成功后，我们乘热打铁，迅速与监控对接。监控业务同样面临全球广覆盖的要求，有强烈的原动力。最终实现的效果是，当一个CI在CMDB中被置为生产状态后，监控系统会立即识别，并根据CI的属性和关联关系自动确定监控指标和告警级别，在完成人工确认后，可触发自动化监控部署。

通过与这两个业务的集成，使大家看到了CMDB在运维自动化方面的潜力。原来CMDB除了给人查阅，还可以这么玩！从此，配置数据的消费呈现爆发式增长。不到两年，已有十几个业务流程基于CMDB运作。

各业务流程通过数据总线识别CI状态的变化，一旦CI进入对应业务的管理范围，就自动触发流程执行。回顾整个推广过程，我发现原动力最为关键。对于一些有广覆盖需求的业务（尤其与安全相关），其原动力最大，会主动找CMDB。比如，补丁管理、入侵检测、账号管理、合规检查等等。

驱动单个流程自动化只是CMDB的起点，当运维的标准化程度足够高时，CMDB还能够驱动多流程协同。比如，实现服务请求的端到端交付。示意如下：

（CMDB驱动多流程协同）

依据经验，通过CMDB驱动各流程协同，可以将服务器的交付时间从原来的1个月缩短到3天。更重要的是，外部客户再也不用介入在资源交付过程中的各种跨部门、跨流程的沟通工作。

经过多年的努力，CMDB已经逐步变成了各个业务流程的起点，为各个流程提供高质量的配置数据。有一次，我跟刘青（我的领导）开玩笑说，你看我们多重要。一旦CMDB挂掉，华为整个IT运维流程就摊了。刘青批评我说，别乌鸦嘴！

最大的难题-数据准确性

数据的准确性是CMDB的生命。因为账号管理和CMDB都归刘青管，所以账号业务相当于CMDB的内部客户，即使CMDB不准，账号那边也得忍着。

但监控、备份等外部客户就没那么好说话，如果CMDB长期不准，客户很容易就会流失。所以，持续提升准确率是巩固成果的关键。

但如何提升准确率呢？很多人说，只要数据被用起来了，自然会准的。真的吗？其实未必。这里面缺了一个前提：要有反馈！

举个例子，其实监控和备份在很多年以前就开始消费CMDB的数据。

但一切是那么的安静，没有任何对数据质量的抱怨。这跟后来账号管理消费CMDB时的氛围完全不一样，我每次碰到朱娟凤（账号管理业务的负责人），就感觉到强烈的杀气。

仔细调查后发现，这些流程有后门！正常情况下，用户在工单中选择CI后，系统会将CI的相关属性自动填入工单。但如果CI的信息是错误的，或者CI根本没登记，用户可以自行在工单中录入信息，这整个过程，CMDB根本不知道。

这就是为什么监控、备份“号称”基于CMDB运作那么多年，却从来没有怨言。燕过都要留毛，你们消费CMDB不给钱就算了，总得对数据准确率做点贡献吧！于是，我们想到了一些办法：

“关门”的意思，是 CMDB 的下游业务发现配置数据不准时，不允许私自修正，必须回到 CMDB 修正。

可以想到，这个策略实施后肯定立马炸锅。因为用户在使用外部系统时，一旦发现配置数据错误，就不得不停止手头的工作，回头更新 CMDB 。新数据要获得审批才能生效，生效的数据要同步回外部系统，用户才能继续工作。这大大降低了业务效率。所以，我们又想到一个办法。

为了避免被人打，我们不得不做了一个大胆的尝试：部门内 “ 放权 ” 。用户更新自己部门的 CI 可即时生效，无需流程审批。因为我们从经验判断， CMDB 准确性最大的问题是 CI 得不到及时更新，而不是更新错误。后来证明，这个决定完全正确。

其实，还有一种更理想的方式是 “ 就地修正 ” 。用户在任何管理系统中发现配置数据不准，应能在当前页面中直接修正。系统会自动将修正后的信息更新回 CMDB 或更上游的数据生产系统。可惜当时开发资源不足，没有实现。

虽然 “关门 ” 很讨厌，但 “ 放权 ” 将影响降到了最低。通过这个方法，我们捕捉到了消费者的反馈，实现了数据在使用中越来越准。

但似乎还差了什么？ …

如果 CI 没登记呢？那么 CI 就不会被消费，也就不会发现问题。更严重的是，对 CI 的安全管控也会遗漏。所以， CMDB 还有最后一件重要的事情要处理 -- 发现黑户！

一开始，我和李渤尝试使用嗅探的办法，试图发现遗漏登记的设备，但效果不好，因为嗅探出来的数据太多、太乱，无法识别。

后来，在牟旭涛的支持下，我们想到一种奇葩的方法：将 CI 登记与 IP 地址管理流程结合：所有接入网络的服务器或网络设备都要有 IP ， IP 必须走流程申请，走流程申请就必须登记 CI ，有 CI 后就能通过自动发现获得 CI 的详细信息，有了 CI 的详细信息后，就能顺藤摸瓜（自动发现或人工追查），把与之关联的 CI 找出来。

这是应该一个完美的闭环， CI 不会漏了吧。

可是，如果私设 IP 呢？

这就要用最后的绝招了 -- “ 黑 IP 检测 ” ：所有网段挨个 ping ，抓出所有活动的 IP ，然后与 IP 申请流程做比对，发现黑 IP 。发现黑 IP 后，提交给网段管理员分析 IP 对应的设备，如果实在分析不出来，就提给机房管理员，顺着网线找！

通过这个极端方法，我们真的发现了大量遗漏登记的设备。

不过，随着实践的深入，我们发现问题更加复杂，比如，云环境下，操作系统是自动安装的， IP 也是自动分配的，没法走流程申请，怎么办？非云环境下，远程装机需要使用 DHCP 地址，如何将 DHCP 网段排除掉？但办法总比困难多，最终问题都解决了。

另外，还有些无法自动发现的问题，可以通过数据合理性分析的方法自动发现出来，这里不再详述。

全球化带来的机遇