重磅好文前华为资深CMDB专家我与CMDB不得不说的故事.docx
《重磅好文前华为资深CMDB专家我与CMDB不得不说的故事.docx》由会员分享，可在线阅读，更多相关《重磅好文前华为资深CMDB专家我与CMDB不得不说的故事.docx（15页珍藏版）》请在冰豆网上搜索。
重磅好文前华为资深CMDB专家我与CMDB不得不说的故事
【重磅好文】前华为资深CMDB专家：
我与CMDB不得不说的故事
每次读到配置管理相关的书籍时，我总在想：
“这些定义很精准，流程也很完整，但这不是真正的难题。
”对于一个配置管理者来说，真正的难题不是绘制“庞大而精美”的数据模型，不是设计“全天候、无死角”的管控流程，而是如何促进数据的消费，并在消费过程中持续的改善数据质量。
我在华为从事了七年配置管理工作，见证了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.基于各业务的管理粒度重新设计配置模型
2.CMDB工具推倒重建，重点提升易用性。
当时国外CMDB产品很贵，买不起。
所以在达成拆迁协议后，我和强叔联手自行开发。
我们使用了当时最时髦的技术，目的是最大程度的提升用户体验。
在巨大热情的支撑下，我们很快就完成了系统开发。
在宣传推广时，新CMDB也广受好评，因为基于Javascript富客户端技术的用户体验的确比之前基于Notes技术的老CMDB好太多了。
但在实际搬时遇到了困难，没有人真的愿意搬进来，还是更愿意使用原来的系统。
理由有很多，比如，操作不太习惯啦，**团队需要的一些特殊功能没有做啦。
好吧，记得PeterThiel也说过，如果要在同质化的产品中赢得竞争，必须对已有的产品功能有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.配置模型要接地气
抑制设计完美配置模型的冲动。
CI的粒度和关系要与当前的运维管理粒度一致。
3.开放心态和数据分级管理
配置管理范围和CMDB管理范围是两回事。
CMDB是一个大的数据管理舞台，有需要但没有合适管理工具的数据都可以放入CMDB中。
但只有最重要的数据（如果错误会导致下游业务异常）才纳入配置管理。
4.数据维护流程要简化
与其担心别人把你的数据改错，你更应该担心别人不愿更新数据。
而复杂的审批流程，只会降低大家维护信息的意愿。
5.保障数据的完整性
数据错了，可以在使用中被发现。
但数据少了，是很难被发现的。
同时，CMDB数据的完整性（就是家底）对于有广覆盖要求的业务有巨大的吸引力，因此要重点保障。
6.数据消费要有反馈
如果无法捕捉反馈，就无法做到“在使用中促进数据准确”。
7.可视化
可视化能够降低信息的理解门槛，也能够更好的暴露数据质量问题。
是引爆消费、提升数据质量的重要手段。
8.在初创阶段，要克制数据分析的冲动
CMDB高级阶段的能力，对数据量和数据质量的要求极高。
在CMDB建设初期还是要务实一些，以与系统对接、供应原材料数据为主。
通向未来的路配置管理深深的“摧残”了我。
几年下来，我逐渐形成了一种“非确定性悲观”的心态。
我总觉得数据有问题，但
升级会员 