我怀疑遇到了假的CMDB

每次读到配置管理相关的书籍时，我总在想：“这些定义很精准，流程也很残缺，但这不是真正的难题。”对于一个配置管理者来说，真正的难题不是绘制“庞大而精美”的数据模型，不是design“全天候、无死角”的管控流程，而是如何促进数据的消费，并在消费过程中持续的改善数据质量。

我在华为从事了七年配置管理工作，见证了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也仍然有很多的顾虑。因此，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. 基于各业务的管理粒度重新design配置模型

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

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

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

但在实践搬时遇到了困难，没有人真的情愿搬进来，还是更情愿运用原来的零碎。理由有很多，比如，操作不太习气啦，**团队需求的一些特殊功能没有做啦。

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

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

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

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

2

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

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

2008年的春天，海外发生了一同安全事情，预先清查，发现这些服务器没有纳入零碎运转管理部的安全管控范围。于是，华为IT开始推进全球一致运维，一切国家、所无机房，均纳入零碎运转管理部的流程管理体系。

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

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

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

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

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

3

价值发挥期

1

冒险的尝试-流程自动化

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

首先尝试的是账号管理，由于全球有海量的账号需求回收，人工成本极高。我们先进行了自动开单，当账号管理零碎从CMDB中辨认到未回收口令的CI时，可自动触发批量口令回出工单。试点效果很好，大大提升了账号回收效率。

大家的决心加强了，于是我们进行了更大胆的尝试：账号管理零碎基于CI属性自动辨认口令回收脚本，并触发脚本执行。我们的理论再次取得成功，账号管理从此轻松完成了百万级口令自动回收，领导再也不用担心口令没回收啦！

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

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

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

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

（CMDB驱动多流程协同）

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

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

2

最大的难题-数据精确性

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

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

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

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

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

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

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

1关门和放权

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

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

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

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

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

但似乎还差了什么？…

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

2发现黑户

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

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

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

可是，如果私设IP呢？

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

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

不过，随着理论的深化，我们发现成绩愈加复杂，比如，云环境下，操作零碎是自动安装的，IP也是自动分配的，没法走流程请求，怎样办？非云环境下，近程装机需求运用DHCP地址，如何将DHCP网段排除掉？但办法总比困难多，最终成绩都处理了。

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

想点新东西

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

1

数据分析

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

我首先想到的是数据分析。由于CMDB中记录了设备的开关机形状，我们经过计算设备的关机工夫，发现出全球有几百台长期关机，却不断放在机房中的设备。

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

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

2

可视化

可视化是在我华为最后一年的尝试，当时想法很简单，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. 配置模型要接地气

抑制design完美配置模型的冲动。CI的粒度和关系要与当前的运维管理粒度分歧。

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

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

4. 数据维护流程要简化

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

5. 保障数据的残缺性

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

6. 数据消费要有反馈

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

7. 可视化

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

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

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

通向将来的路

配置管理深深的“摧残”了我。几年上去，我逐渐构成了一种“非确定性悲观”的心态。我总觉得数据有成绩，但又不知道哪有成绩。随着运用配置的客户越来越多，我总担心哪天由于配置不准而摊上大事。

因此，我想尽办法搞一大堆的数据质量检查措施，有变更后的检查、定期的审计、逻辑合理性分析、CI责任人的定期自我审视。这些措施，除了逻辑合理性分析有用外，其他基本没啥用。但这不重要，真正重要的是：当我摊上事的时分，最少可以跟领导说，你看，我该做的都做了…

可是，难道我们不应该更愉快的工作吗？

将来，肯定有更好的实施CMDB的方法。

这种方法，能够更大限制的提升人们消费信息的原动力和创造力，能够以非侵入的方式与各业务流程无缝集成，最重要的是，能够降低实施CMDB的门槛和风险，使大量中小型的IT组织能够从中受益。当然，也使配置管理员不那么的辛劳……

经过两年的探求以及与国内大量顶尖IT管理者面对面的交流，我们忽然发现，“自服务+可视化”的CMDB也许是一条通向将来的道路。CMDB与架构图的亲密接触会发生什么呢？这是我近两年不断研讨的课题，置信在不远的将来，大家能会看到一个全新的方案。