企业 CMDB 项目建设为什么常常失败？
CMDB建设过程中其它部门不配合，数据不准确怎么办？CMDB数据审计经常在企业推行不下去，考核往往形同虚设应该怎么处理？CMDB建完后，如何保证数据的实时更新？……本文精选社区交流活动中大家分享的CMDB建设中的十个痛点及对策。
分享者包括：zhh321 某人寿数据中心 系统架构师（多年来一直负责公司CMDB项目建设推广和运营工作）、eximbank 某金融企业 系统架构师、@asdf-asdf 研究学者、he7yong 研发工程师等
1、云时代的到来，我们是否需要审视CMDB的定位和作用？
【问题描述】目前是云2.0时代，以应用为中心，容器技术的出现，让我们不用关注我们的应用运行在什么主机上，应用之间的访问拓扑可以实时展示。在这个时代，CMDB是否还有存在的必要性？
@zhh321：
这个话题值得探讨。容器的出现，交付部署发生巨大改变，而且容器平台本身集成或标配了配置中心、监控等许多组件。容器平台本身提供了”一条龙服务“，取代了原本各种复杂林立的运维工具平台，一统江湖。从这个意义上，原来CMDB的主数据价值是降低了。同时，容器自身也集成了一个CMDB。
另外一个方面，微服务化导致模块间的运行关系复杂度大大提高，这或许是CMDB将来的一个方向。
@eximbank：
CMDB是IT数据中心的软资产，可以看成是资本，新技术重塑的业务肯定要从CMDB的环境中分离出去。就像银行会计核心系统，会计准则是不会变，变的是周边系统和资产放哪儿更合适？一个是技术主导，一个是信息资产。就看覆盖面到什么程度，就像云环境下的虚拟化、Docker使用，总还有为数不少的环境要求bare metal box运行，甚至还有要求特殊系统的，诸如windows等。一个平台或系统的存在与否，不是技术决定，也不是信息本身决定，而是所要生存的环境和用户使用需求决定。
@匿名用户：
在云时代，对于CMDB的要求的迫切性更高了，更快的发布，更容易的更迭，更加复杂的结构和更多的版本如果没有相应的系统去管理，整个云平台系统会逐渐变得不可知和不可管理，而且云平台里面不仅仅只有容器，还有虚拟机，裸设备以及各种最后的网络环境存储环境！
@asdf-asdf：
CMDB在裸金属和VM时代对设备的全生命周期管理有着几个数据消费用户，在当前容器时代对实时数据的一致性对当前以配置稳定性为基础的CMDB系统给出来挑战，在以动态数据实时捕获和以往CMDB数据集成方向，完成一个完整的数据业务中台服务，使数据生产者能实时把数据推送到数据中台，消费者可随时发起数据消费，等待实时数据推送完成。对当前CMDB改造完成到数据中台过度，使数据消费者能实时获得所需要数据，并保证数据当前时间的一致性是为了CMDB或数据中台系统的业务方向。
2、CMDB数据审计经常在企业推行不下去，考核往往形同虚设应该怎么处理？
@zhh321：
以往我们谈到CMDB数据治理的主要印象是：配置流程规范+数据审计。从原理上，这是一种事后+上层控制的思路，策略上属于下策：
第一，事后控制不如事前、事中控制。流程上看，末端来纠错的成本肯定大于前期纠错成本。
第二，上层集中控制成本很高。可以想象，审计出来的问题数据怎么处理呢？真的考核到个人头上，华为或者一些外企这类组织执行力强的公司可以长期实施，但在绝大部分公司政治环境生态中，领导们还不至于为了CMDB大动干戈，可能把审计出来的问题数据进行公示也无关痛痒。CMDB在很多情况下还无法达到像运维安全那样形成公司上下共识，在强有力的管理要求下开展考核。要知道任何严密的组织结构都是需要一定能量来维持的，领导的权利支持、被管理者的抵制，需要的能量都是成本，而收益又是多少？
成本收益是有机体生存的底层策略之一。因此CMDB数据审计的思路应该是：通过流程设计想办法调整流程约束的时间结构，让数据检查动作提前，提高用户犯错成本，同时转移治理中的监督成本。举个例子，某个流程要求设备到货时某人某时刻录入CMDB，但执行人可能偷懒或者真的遗忘了，事后审计虽然形成闭环但效率低。更优的流程设计是把设备初验场景整合进流程里，如果没有录入CMDB则无法初验，流程在执行中就有人会跳出来拉响警报。请注意以往逻辑是业务先变更，再到CMDB登记，业务是因，CMDB是果。正确的思路把CMDB设计为某个业务活动的因，这样数据质量可以得到极大改善。
传统的数据审计模式还得有，但主要用来做存量数据基线盘点。考核责任人建议以产品为单位。考核手段尽量借力外部或现有的能量资源，譬如外部审计要求、安全要求、公司现有的奖励评选等等。让错误数据找得到责任人，同时让责任人自己感到鸭梨山大。
3、针对CMDB的数据可视化，在数据库上应如何选择？
@zhh321：
从复杂关系的展现上说，肯定图数据库来实现比较好。
从理论上，关系型数据库也能实现多对多、一对多。只是要有中间表，有一定维护成本。深度路径查询肯定没有图数据库的效率高，还有许多其他劣势，也许图数据库是个趋势，只是目前团队学习成本较高。
我觉得，用图数据库新建CMDB的，除了专业厂商或技术能力强的互联网公司，一般甲方公司恐怕暂时不会去尝试自建使用。
4、CMDB建设过程中的痛苦：其它部门不配合，数据就很难准确？
【问题描述】CMDB建设过程中往往涉及很多部门。但是可能存在下面的情况：一线运维部门对CMDB需求紧迫，但是无法作为牵头部门对整个数据中心的CMDB建设统领；管理条线部门本应统一规划CMDB建设，但对具体需求不甚明确。所以，很容易造成各部门之间扯来扯去，CMDB却无法落地的情况。
@zhh321：
我们公司也经历这个痛苦的过程，经常自嘲说：要凭一己之力对抗整个组织或流程，一不小心还成了背锅侠。其原因在“CMDB能对目前运维带来哪些收益以及推行的难点主要在哪方面”中提到过：CMDB建设者从长期、全局的视角来做配置管理工作，但造成各(ge)个(huai)部(gui)门(tai)短期成本提升，这对领导都是一件有难度的事，何况几乎没有什么权利的CMDB团队？
所以CMDB是很考验管理能力的工作，当然我们也能通过这个过程获得成长。如何去争取和说服决策者（权利中心），如何各个场景分别突破形成利益捆绑从而降低管理成本，如何把责任明确提升用户犯错成本，都只能提个思路，各家公司实际情况都不同要灵活处理。总之，CMDB团队应抱着招商引资的心态，向运维团队去推销、谈合作。
@he7yong：
企业对CMDB的定位不准确，高度不够高。
5、经常面临CMDB数据变更滞后于数据源的数据变更，如何变被动数据治理为主动数据治理？
【问题描述】目前我们平台经常面临CMDB数据变更滞后于数据源的数据变更，目前部分分类通过定时同步解决了该问题，但随着分类越来越多，这一方法就变得成本很高，我的问题是如何变被动数据治理为主动数据治理？
@zhh321：
从时间结构上看，CMDB和其他活动的因果关系分为两种：
一种是先“变更”再更新CMDB，变更活动是“因”，CMDB是果。这种情况CMDB比较被动，你要么要(gui)求(qiu)人家改你的CMDB，要么想办法通过数据发现自动捕捉人家的变化。
另一种是先更新CMDB，再实施变更。CMDB是因，变更活动是“果”。这种方法还有个好听的叫法“配置驱动”，是一种配置中心化的软件定义。从流程设计上，让CMDB成为下游环节的依赖前提。从系统架构关系上，让CMDB成为运维系统的配置中心。需要提醒的是，这种方式并不一定要用户在CMDB自身门户中操作，完全可以在运维场景中，用户直接在运维工具中，通过API间接维护和消费CMDB。用户甚至感觉不到CMDB的存在。
第二种从策略上说肯定是最优的，变被动为主动。
@he7yong：
我们实现比较简单，所有的执行流程，如果涉及到配置对象的变动，最后执行流程得有一个动作，更新配置对象到CMDB中；
如交付10台虚拟机，这10台虚拟机完成初始化后，直接更新到CMDB对于的业务和模块下面，强调流程的闭环。
6、CMDB能对目前运维带来哪些收益？推行的难点主要在哪些方面？
@zhh321：
这个问题背后其实是成本收益分析，商人脑袋很自然的就用这个模型来思考问题，但作为IT从业者往往会忽视。经历了一些事后可能发现，原来一件正确的事不一定是适合的，所谓天时地利人和。
因此收益和难点（成本）这个问题很高明。本质上的理解我在一篇分享中阐述过，供您参考：某大型保险企业应用CMDB平台建设的实践经验。
CMDB的核心收益是主数据库带来的较低的综合成本。只不过结合不同场景，其价值又体现在安全内控管理（账号、堡垒机、防火墙、漏洞补丁、合规检查、IP端口）、监控告警、自动化运维、资产管理、资源交付、发布管理、应急管理、ITIL流程管理、容量管理等具体领域。没有主数据库，上面这些工作都要自建配置库，大型数据中心情况下整体成本会很高。
但主数据库这种架构天然导致了推广的悖论，因为人们总是对全局和个体、长期和短期之间纠结平衡，且整体上会朝着熵增的趋势发展。CMDB建设者从长期、全局的视角来做配置管理工作，但造成各(ge)个(huai)部(gui)门(tai)短期成本提升，这对领导都是一件有难度的事，何况几乎没有什么权利的CMDB团队？换句话说，CMDB本身是一件短期成本高，但从全局和长期才能体现收益的事情，想想人们买保险的心情！
解决办法我也上面一篇分享尝试做了分析，欢迎大家一起交流。抽象的说就是：
1.要获得高层权利支持
2.通过具体场景来落实收益
3.设法转嫁和降低管理成本（蹭热度，抱大腿；和其他系统、流程形成利益绑定；把要求纳入现有奖惩考核）
4.提升用户犯错成本（以产品为单位明确责任人；流程自审计；公开审计结果）
7、CMDB建完后，如何保证数据的实时更新？相关的规章制度有哪些？
【问题描述】CMDB建好后，过一段时间后，数据就不是很准了。原因就是有很多操作，并没有经过CMDB的环节。有没有运维的标准流程，让所有的操作都能通过CMDB？或者介绍一下贵单位在实际使用CMDB时的流程，保障CMDB中的数据永远都是最新的？
@zhh321：
数据自动发现肯定是第一选择。对于无法自动发现的，要考验流程管理水平。公司里有很多规章制度，执行效果如何？大家心里有数。个人浅见：规章制度都只是要求，是目标。目标的执行落地，要么是自上而下的外部力量，要么靠自下而上的内部力量。外部力量比如说领导重视、外部审计、公司考核制度，这些通常这些手段因为CMDB得不到上层重视落地效果不明显。内部力量可能是主要的方向，比如说切合运维的场景驱动，还有我比较提倡的流程“自审计”。把录入CMDB作为其他运维活动的依赖条件，像设备初验、资源申请、主机上线、备份申请等等。利用“利益”把大家绑定起来，才能以最小的成本让配置管理要求真正落地。
8、CMDB能解决服务器相关各类资产的准确性难题吗？
【问题描述】服务器资产管理，目前还在用excel表格来管理，想上一套工具，但纠结在用资产管理工具还是用CMDB配置管理工具，感觉都能实现？又感觉都差点意思。
@zhh321：
如果只是定位硬件设备的资产管理，资产管理工具还是CMDB都行。但一般企业发展下去都会走CMDB这条路来打通各种运维平台和服务流程，从这个角度来说直接上CMDB综合成本会更低。
数据准确性方面，硬件资产可以利用部分数据自动发现的手段获得CPU、内存、存储、HBA这类配置信息。但设备位置和序列号这个盘点用到的关键对应关系，如果没有RFID这种手段的话，还是要靠流程来控制，这比较考验流程设计水平了，需要和相关部门协调好，才能保证数据准确性。
9、如何从数据类型和过程拆解数据治理的逻辑，分而治之？
@zhh321：
CMDB的数据可分为自动发现数据和人工录入数据两大类。第一策略是尽最大努力扩大自动发现范围（因为自动发现的数据一定是最准确），降低配置管理的成本。常见的自动发现数据源有云管平台、安全管理系统、网管平台、负载均衡系统、带外管理系统等，总之要团结一切能够自动发现的力量。但接下来总要面对人工录入数据，这里用水池模型来解释。要一个水池干净，一是保证流入的增量干净，二是净化水池中的存量，三是要水循环流动起来。类似的，CMDB增量变更数据由场景流程来控制，存量数据靠数据资产明确属主并提高犯错成本。最后通过场景消费形成正反馈机制。三管齐下。
10、CMDB自动发现数据是否能够自动更新？
【问题描述】自动发现数据是放入调和库，还是直接更新？一般更新策略是什么？有更新后是否对更新内容追踪核实？
@he7yong：
CMDB自动发现数据是否能够自动更新，取决于你的业务需求；
如果你的CMDB供给给自动化操作的场景，CMDB发现的数据直接写入到CMDB影响会很大；2.我们现在的做法是先放入到自动发现数据库，人员审批后自动更新到CMDB；3.未来根据使用的情况，如果发现的数据都是可以直接更新的，我们可能会采取直接更新的策略。
@zhh321：
楼上的回答很完善了，我也推荐针对重要的属性，尤其是用于自动化运维的，采用先入调和库，再通过人工审核后更新CMDB正式库。从程序效率上，也是先全部入调和库，再和正式库比对会更可控一些。
您是否有过类似的经历，对企业CMDB建设有何建议和看法？ 欢迎点击文末阅读原文到社区原文下评论交流
资料/文章推荐：
某保险企业应用CMDB平台建设的实践经验
http://www.talkwithtrend.com/Document/detail/tid/425859
如何实现云管平台与CMDB系统的联动
http://www.talkwithtrend.com/Article/243115
欢迎关注社区 “CMDB”技术主题，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/76027
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场