每次读到配置管理相关的书籍时，我总在想：“这些定义很精准，流程也很完整，但这不是真正的难题。”对于一个配置管理者来说，真正的难题不是绘制“庞大而精美”的数据模型，不是设计“全天候、无死角”的管控流程，而是如何促进数据的消费，并在消费过程中持续的改善数据质量。
我在某公司从事了七年配置管理工作，见证了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的建设历程可以分为三个阶段：初创期、整合期和价值发挥期。
图2某公司CMDB的三个建设阶段
初创期
2002年某公司IT运维引入了ITIL流程，同时也一并引入了CMDB。那时我们并不知道CMDB该怎么用。但由于“先僵化、再优化、最后固化”的指导思想，我们完成了系统建设，并成立了专职的配置管理团队。
2002年到2007年，是配置管理较尴尬的几年。当时每个技术管理部门都有自己的“自建库”。比如，机房管理部和网络部有设备表，X86管理部、Unix管理部也开发了自己的配置库。大家各玩各的，就是没人玩CMDB。大家普遍的说法是CMDB不准。因此，配置管理团队付出了巨大努力，比如，强化管控流程、定期开展数据审计等，但始终无法打开局面。
整合期
故本文的事从2007年开始。那时，我已经在某公司做了一年变更管理员，厌倦了天天盖戳的工作，我认为自己其实是一名程序猿，所以向陈总提出要调到开发部门的请求。陈总人很好，他告诉我CMDB大有可为，并果断给我涨工资。从此，我半推半就的走进CMDB的世界。
简单粗暴的方法-强制拆迁
我的想法很简单，只要那些自建库不存在了，大家就不得不玩CMDB了…所以，抱着大有可为、一统江湖的心态，我开始策划如何拆迁掉那些自建库。
在得到高层领导的同意后，我们开始了拆迁调研。经分析，技术管理部不愿意使用CMDB的原因有两个：
- CDM不接地气，与各管理业务的数据模型不兼容
- CMDB的易用性差
因此，我给出的拆迁补偿是：
- 基于各业务的管理粒度重新设计配置模型
- 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还能够驱动多流程协同。比如，实现服务请求的端到端交付。示意如下：
图3CMDB驱动多流程协同
依据经验，通过CMDB驱动各流程协同，可以将服务器的交付时间从原来的1个月缩短到3天。更重要的是，外部客户再也不用介入在资源交付过程中的各种跨部门、跨流程的沟通工作。
经过多年的努力，CMDB已经逐步变成了各个业务流程的起点，为各个流程提供高质量的配置数据。有一次，我跟刘青（我的领导）开玩笑说，你看我们多重要。一旦CMDB挂掉，某公司整个IT运维流程就摊了。刘青批评我说，别乌鸦嘴！
很大的难题-数据准确性
数据的准确性是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的关系自动生成架构图。
然而，实际的使用效果并不理想，原因是：
- 自动视图对关联关系的数据质量要求太高，虽然当时CMDB的数据质量总体上已经很不错，但关联关系的数据质量依旧是短板（很多关系无法发现，人工维护起来又很麻烦），导致很多架构图缺胳膊少腿；
- 自动视图中的CI粒度比传统架构图更细，有没有引入“容器”聚合细粒度的CI，技术人员看不懂（比如，传统架构图上，一台应用服务器对应一个图标。但CMDB生成的视图有三个图标，分别是中间件、操作系统、物理主机）；
- 架构图中的关系连线没有收敛，导致线条错综复杂，难看至极；
- 图的自动布局不太符合人们的视觉习惯。
由于后来离开了某公司，所以没有把这件事继续下去。现在回想起来，还是积累了不少经验：
- 架构图自动生成这件事，在现有的技术条件下非常难。架构图是需要一点点创造力和美感的，而程序很难有创造力，更别说美感了。而且架构图本身很复杂，比如两地三中心的架构布局，工具就很难按照人类的预期绘制出来。
- 对用户更有用的，其实只是一张空白的画布，用户能够把CI拖入画布中，并自由的绘制和布局,就像画Visio一样。如果CI的关联关系缺失，没关系，直接画一条线出来就行了。
这些经验后来也得到了证实。去年，优锘给某公司提供了一套配置可视化产品，效果非常好，能够以自服务的方式快速实现大量交易流的可视化。项目结束后我们还收到了某公司写的感谢信。
总结
已挖掘出的价值
某公司CMDB是相对成功的，因为我们从它身上挖掘出一些实实在在的价值，比如：
- 避免配置数据被重复维护，降低数据管理的总成本；
- 共享同一套配置数据，使各运维业务对IT资产的基本配置情况达成共识，并驱动各流程的自动化协同；
- 能够以CI为核心，拉通各个管理工具中孤立的数据，并通过面向管理场景的数据分析和可视化，使IT管理者能更加全面的掌握CI的运行状态和管理现状，提升管理的透明度。
某公司的特殊性
即使全部掌握了上面的经验，也许仍然无法按照某公司的模式建成一个CMDB。
为什么呢？
因为某公司CMDB的主要客户是系统，而不是人。这种模式是侵入式的，会对原有的业务运作模式在短期内带来巨大冲击（业务效率会降低、成本会增多、风险会增加），必然受到抵制。
某公司能按这种方式做成的根本原因是什么呢？其他组织又是否具备呢？
某公司CMDB成长的土壤、条件、机遇和运气
强大的执行力
很多人都知道某公司有一句口号：“先僵化、再优化、最后固化”。这不仅仅是句口号，某公司的确是这么做的。2001年，IBM的外国顾问引入了配置管理流程，并设置了专门的管理部门，但并没有讲清楚CMDB到底怎么用。结果，在长达6年时间，配置管理事实上并未给运维带来多大的好处。虽然如此，某公司仍然持续投入。那些年，配置管理部门始终保持3-7人的规模。正是这些人不断的尝试，不断的努力，才迎来了成功的机会。
另外，在2009年完成全球配置梳理后，为了保持数据的准确，几乎全部IT人员都动员起来了。只要有人出差，不管去全球哪个角落，都会帮我们检查当地的配置信息。甚至CIO周总也亲自下机房检查。我还记得那几年周总每次出差前，都会问我们要一份当地机房的配置清单。当然，为了保持良好的合作关系，我会立即通知当地的机房管理员，赶紧自查！
管理规模大、标准化程度高，有强烈的自动化需求和现实条件
某公司IT资产的体量庞大，分布极广（在全球有几十万台设备，分布在几十个国家的一百多个机房），而运维人员只有几百人，大部分都在总部数据中心，这必然带来流程自动化的需求。
另外，2002年引入配置管理的同时，也引入了其他一系列ITIL管理流程。经过7-8年的完善，这些流程的标准化程度已经很高，具备了自动化的基础。
由于上述条件，使某公司CMDB的潜力得以充分发挥。
全球化带来的机遇
全球化带来了管理要广覆盖的要求，使得各个管理业务自建配置库的数据维护成本陡然上升，不得不认真考虑“数据管理外包”。
偶然的运气
第一个运气：在“和平”时期，配置管理团队独立完成全球配置数据梳理是不可能完成的任务。然而，在海外发生的意外使安全内控被空前重视。配置管理“手持”安全内控的“尚方宝剑”，人挡杀人、佛挡杀佛，奇迹般的在短时间内就完成了全球数据梳理。
第二个运气：基于以往的教训，即使CMDB完成了数据梳理，其他业务也不敢贸然使用，因为CMDB的第一个用户必然要消化掉存量的数据质量问题。幸运的是，当时账号安全管理部和配置管理部正好都归刘青管。刘青一方面苦于CMDB没有消费场景，另一方面又面对账号管理要广覆盖的强大压力，那就把这俩宝贝撮合一下试试吧…这也是为什么账号管理敢第一个“吃螃蟹”。
那么，为什么国内大部分公司做不成呢？ 因为他们很可能不具备这些条件。下面是一个对比：
| 比较要素 | 某公司 | 其他组织 |
| 执行力 | 超强（先僵化，在优化，最后固化） | 一般 |
| 管理规模 | 超大 | 一般 |
| 管理标准化程度 | 明确的流程触发条件 明确的数据输入标准 面向应用和业务的管理 | 对象管理范围不明确 数据输入标准不明确针对单台设备的管理 |
| 机遇 | 全球化导致原有管理模式成本激增 | ？ |
| 运气 | 具备内部试点的条件 | ？ |
表1某公司和其他组织的比较
所以，鉴于这些因素，我认为某公司实施CMDB的方式很难复制，但并不是说某公司之外的其它组织就做不成CMDB，在下一篇文章中我将尝试总结一些相对通用的CMDB建设经验，分享给还在与CMDB搏斗的各位同好。
经验教训
通过成功的道路往往曲折艰难。建设CMDB也是如此。那些年，我们做了大量的尝试，有些成功了，有些失败了。抛开某公司的特殊性，在这里总结一些通用的经验教训：
- 拆迁不如搬迁运维环境中已经存在的自建库，虽然粗糙，但有其存在的意义。贸然拆迁会有巨大的风险。比较保险的办法是保留原有的数据维护模式不变，只进行数据的复制搬迁。历史的经验也告诉我们，包产到户比人民公社更有效。
- 配置模型要接地气抑制设计完美配置模型的冲动。CI的粒度和关系要与当前的运维管理粒度一致。
- 开放心态和数据分级管理配置管理范围和CMDB管理范围是两回事。CMDB是一个大的数据管理舞台，有需要但没有合适管理工具的数据都可以放入CMDB中。但只有很重要的数据（如果错误会导致下游业务异常）才纳入配置管理。
- 数据维护流程要简化与其担心别人把你的数据改错，你更应该担心别人不愿更新数据。而复杂的审批流程，只会降低大家维护信息的意愿。
- 保障数据的完整性数据错了，可以在使用中被发现。但数据少了，是很难被发现的。同时，CMDB数据的完整性（就是家底）对于有广覆盖要求的业务有巨大的吸引力，因此要重点保障。
- 数据消费要有反馈如果无法捕捉反馈，就无法做到“在使用中促进数据准确”。
- 可视化可视化能够降低信息的理解门槛，也能够更好的暴露数据质量问题。是引爆消费、提升数据质量的重要手段。
- 在初创阶段，要克制数据分析的冲动CMDB高级阶段的能力，对数据量和数据质量的要求极高。在CMDB建设初期还是要务实一些，以与系统对接、供应原材料数据为主。
通向未来的道路
配置管理深深的“摧残”了我。几年下来，我逐渐形成了一种“非确定性悲观”的心态。我总觉得数据有问题，但又不知道哪有问题。随着使用配置的客户越来越多，我总担心哪天因为配置不准而摊上大事。因此，我想尽办法搞一大堆的数据质量检查措施，有变更后的检查、定期的审计、逻辑合理性分析、CI责任人的定期自我审视。这些措施，除了逻辑合理性分析有用外，其他基本没啥用。但这不重要，真正重要的是：当我摊上事的时候，起码可以跟领导说，你看，我该做的都做了…
可是，难道我们不应该更愉快的工作吗？
未来，肯定有更好的实施CMDB的方法。
这种方法，能够更大限度的提升人们生产信息的原动力和创造力，能够以非侵入的方式与各业务流程无缝集成，重要的是，能够降低实施CMDB的门槛和风险，使大量中小型的IT组织能够从中受益。当然，也使配置管理员不那么的辛苦……
经过两年的探索以及与国内大量IT管理者面对面的交流，我们忽然发现，“自服务+可视化”的CMDB也许是一条通向未来的道路。CMDB与架构图的亲密接触会发生什么呢？这是我近两年一直研究的课题，相信在不远的将来，大家能会看到一个全新的方案。
图4虐心，但蕴含着无限可能
谨以此文，向那些曾经在配置岗位上一起奋斗过和至今仍在奋斗的战友们致敬。