zhh321
作者zhh3212019-07-25 11:53
系统架构师, 中国人寿数据中心

企业CMDB建设失败的原因如何解决以及是否重新审视CMDB的定位和作用

字数 6304阅读 3954评论 0赞 6

CMDB建设为何会失败,很重要原因就是数据不准:

1、数据不准在企业里面就是一个恶性循环,因为数据不准,大家不用,导致数据消费的少,更加不准,CMDB越来越边缘化。虽然有自动发现,但解决不了所有问题;
2、真实的运维工作比我们想象的复杂,总有无法标准化、自动化的地方,运维人员作为一线人员,了解这些细枝末节的需求,但是却没法标准化到CMDB中;
3、总会有一些特例,在运维工作中不断冒出来,CMDB的研发是滞后的,总不能因为CMDB没有这个功能,他们就不运维。

那如何解决企业CMDB数据不准的问题,就需要从以下一些问题入手,本次问题包含2部分:
一部分是哪些会造成数据不准,如何解决数据不准?
另外一方面是CMDB的定位、作用和厂商选型!
本期线上交流:金融企业如何通过数据治理来解决CMDB数据不准的企业难题在线交流 (精彩回顾)

1、云时代的到来,我们是否需要审视CMDB的定位和作用?

目前是云2.0时代,以应用为中心,容器技术的出现,让我们不用关注我们的应用运行在什么主机上,应用之间的访问拓扑可以实时展示;
在这个时代,CMDB是否还有存在的必要性?

回复1:这个话题值得探讨。容器的出现,交付部署发生巨大改变,而且容器平台本身集成或标配了配置中心、监控等许多组件。容器平台本身提供了”一条龙服务“,取代了原本各种复杂林立的运维工具平台,一统江湖。从这个意义上,原来CMDB的主数据价值是降低了。同时,容器自身也集成了一个CMDB。
另外一个方面,微服务化导致模块间的运行关系复杂度大大提高,这或许是CMDB将来的一个方向。

回复2:CMDB是IT数据中心的软资产,可以看成是资本,新技术重塑的业务肯定要从CMDB的环境中分离出去。就像银行会计核心系统,会计准则是不会变,变的是周边系统和资产放哪儿更合适?一个是技术主导,一个是信息资产。就看覆盖面到什么程度,就像云环境下的虚拟化、Docker使用,总还有为数不少的环境要求bare metal box运行,甚至还有要求特殊系统的,诸如windows等。一个平台或系统的存在与否,不是技术决定,也不是信息本身决定,而是所要生存的环境和用户使用需求决定。

回复3:在云时代,对于cmdb的要求的迫切性更高了,更快的发布,更容易的更迭,更加复杂的结构和更多的版本如果没有响应的系统去管理,整个云平台系统会逐渐变得不可知和不可管理,而且云平台里面不仅仅只有容器,还有虚拟机,裸设备以及各种最后的网络环境存储环境!

回复4:cmdb 在裸金属和vm时代对设备的全生命周期管理有着几个数据消费用户,在当前容器时代对实时数据的一致性对当前以配置稳定性为基础的cmdb系统给出来挑战,在以动态数据实时捕获和以往cmdb数据集成方向,完成一个完整的数据业务中台服务,使数据生产者能实时把数据推送到数据中台,消费者可随时发起数据消费,等待实时数据推送完成。对当前cmdb改造完成到数据中台过度,使数据消费者能实时获得所需要数据,并保证数据当前时间的一致性是为了cmdb或数据中台系统的业务方向。

2、CMDB数据审计经常在企业推行不下去,考核往往形同虚设应该怎么处理?

回复:以往我们谈到CMDB数据治理的主要印象是:配置流程规范+数据审计。从原理上,这是一种事后+上层控制的思路,策略上属于下策:
第一,事后控制不如事前、事中控制。流程上看,末端来纠错的成本肯定大于前期纠错成本。
第二,上层集中控制成本很高。可以想象,审计出来的问题数据怎么处理呢?真的考核到个人头上,华为或者一些外企这类组织执行力强的公司可以长期实施,但在绝大部分公司政治环境生态中,领导们还不至于为了CMDB大动干戈,可能把审计出来的问题数据进行公示也无关痛痒。CMDB在很多情况下还无法达到像运维安全那样形成公司上下共识,在强有力的管理要求下开展考核。要知道任何严密的组织结构都是需要一定能量来维持的,领导的权利支持、被管理者的抵制,需要的能量都是成本,而收益又是多少?
成本收益是有机体生存的底层策略之一。因此CMDB数据审计的思路应该是:通过流程设计想办法调整流程约束的时间结构,让数据检查动作提前,提高用户犯错成本,同时转移治理中的监督成本。举个例子,某个流程要求设备到货时某人某时刻录入CMDB,但执行人可能偷懒或者真的遗忘了,事后审计虽然形成闭环但效率低。更优的流程设计是把设备初验场景整合进流程里,如果没有录入CMDB则无法初验,流程在执行中就有人会跳出来拉响警报。请注意以往逻辑是业务先变更,再到CMDB登记,业务是因,CMDB是果。正确的思路把CMDB设计为某个业务活动的因,这样数据质量可以得到极大改善。
传统的数据审计模式还得有,但主要用来做存量数据基线盘点。考核责任人建议以产品为单位。考核手段尽量借力外部或现有的能量资源,譬如外部审计要求、安全要求、公司现有的奖励评选等等。让错误数据找得到责任人,同时让责任人自己感到鸭梨山大。

3、CMDB建完后,如何保证数据的实时更新?相关的规章制度有哪些?

CMDB建好后,过一段时间后,数据就不是很准了。原因就是有很多操作,并没有经过CMDB的环节。有没有运维的标准流程,让所有的操作都能通过CMDB?或者介绍一下贵单位在实际使用CMDB时的流程,保障CMDB中的数据永远都是最新的?

回复:数据自动发现肯定是第一选择。对于无法自动发现的,要考验流程管理水平。公司里有很多规章制度,执行效果如何?大家心里有数。个人浅见:规章制度都只是要求,是目标。目标的执行落地,要么是自上而下的外部力量,要么靠自下而上的内部力量。外部力量比如说领导重视、外部审计、公司考核制度,这些通常这些手段因为CMDB得不到上层重视落地效果不明显。内部力量可能是主要的方向,比如说切合运维的场景驱动,还有我比较提倡的流程“自审计”。把录入CMDB作为其他运维活动的依赖条件,像设备初验、资源申请、主机上线、备份申请等等。利用“利益”把大家绑定起来,才能以最小的成本让配置管理要求真正落地。

4、针对cmdb的数据可视化,在数据库选择上有什么推荐的?

回复:从复杂关系的展现上说,肯定图数据库来实现比较好。印象里优维科技CMDB就是率先采用图数据库实现的,但没体验过效果未知。
从理论上,关系型数据库也能实现多对多、一对多。只是要有中间表,有一定维护成本。深度路径查询肯定没有图数据库的效率高,还有许多其他劣势,也许图数据库是个趋势,只是目前团队学习成本较高。
我猜,用图数据库新建CMDB的,除了专业厂商或技术能力强的互联网公司,一般甲方公司恐怕暂时不会去尝试自建使用。

5、目前市场上哪些成熟的cmdb厂商或产品?应用的效果如何?

回复1:商业产品国内外的有不少。如老牌的BMC,还有IBM HP大厂的。国内现在很多运维厂商也都推出了自己的CMDB产品,像华为、优维、优诺等等。成熟的开源CMDB有腾讯蓝鲸CMDB、CMDBuild、iTop、OneCMDB几款。据目前了解,很多CMDB产品和运维管理平台绑定的较为紧密,如果公司自己已经有较为成熟的运维平台,对接集成会比较困难。我们公司最后选型的是cmdbuild,用户社区还行,产品也一直在更新。这个产品基本的管理功能比较完善,在这个基础上补充一些开源软件进行二次开发,效果还不错,推荐考虑。

回复2:推荐使用一下蓝鲸的CMDB,好处如下:
1.采用MongoDB的数据库,模型创建和属性扩展都非常的灵活
2.可以和蓝鲸监控和自动化天然集成;
3.有非常强大的自动化采集能力。

6、CMDB建设过程中的痛苦,其它部门不配合,数据就很难准确?

CMDB建设过程中往往涉及很多部门。但是可能存在下面的情况:一线运维部门对CMDB需求紧迫,但是无法作为牵头部门对整个数据中心的CMDB建设统领;管理条线部门本应统一规划CMDB建设,但对具体需求不甚明确。所以,很容易造成各部门之间扯来扯去,CMDB却无法落地的情况。

回复1:我们公司也经历这个痛苦的过程,经常自嘲说:要凭一己之力对抗整个组织或流程,一不小心还成了背锅侠。其原因在帖子cmdb能对目前运维带来哪些收益以及推行的难点主要在哪方面中提到过:CMDB建设者从长期、全局的视角来做配置管理工作,但造成各(ge)个(huai)部(gui)门(tai)短期成本提升,这对领导都是一件有难度的事,何况几乎没有什么权利的CMDB团队?
所以CMDB是很考验管理能力的工作,当然我们也能通过这个过程获得成长。如何去争取和说服决策者(权利中心),如何各个场景分别突破形成利益捆绑从而降低管理成本,如何把责任明确提升用户犯错成本,都只能提个思路,各家公司实际情况都不同要灵活处理。总之,CMDB团队应抱着招商引资的心态,向运维团队去推销、谈合作。

回复2: 企业对CMDB的定位不准确,高度不够高.

7、经常面临CMDB数据变更滞后于数据源的数据变更,如何变被动数据治理为主动数据治理?

目前我们平台经常面临CMDB数据变更滞后于数据源的数据变更,目前部分分类通过定时同步解决了该问题,但随着分类越来越多,这一方法就变得成本很高,我的问题是如何变被动数据治理为主动数据治理?

回复1:从时间结构上看,CMDB和其他活动的因果关系分为两种:
一种是先“变更”再更新CMDB,变更活动是“因”,CMDB是果。这种情况CMDB比较被动,你要么要(gui)求(qiu)人家改你的CMDB,要么想办法通过数据发现自动捕捉人家的变化。
另一种是先更新CMDB,再实施变更。CMDB是因,变更活动是“果”。这种方法还有个好听的叫法“配置驱动”,是一种配置中心化的软件定义。从流程设计上,让CMDB成为下游环节的依赖前提。从系统架构关系上,让CMDB成为运维系统的配置中心。需要提醒的是,这种方式并不一定要用户在CMDB自身门户中操作,完全可以在运维场景中,用户直接在运维工具中,通过API间接维护和消费CMDB。用户甚至感觉不到CMDB的存在。
第二种从策略上说肯定是最优的,变被动为主动。

回复2:我们实现比较简单,所有的执行流程,如果涉及到配置对象的变动,最后执行流程得有一个动作,更新配置对象到CMDB中;
如交付10台虚拟机,这10台虚拟机完成初始化后,直接更新到CMDB对于的业务和模块下面,强调流程的闭环。

8、cmdb能对目前运维带来哪些收益以及推行的难点主要在哪方面?

回复:这个问题背后其实是成本收益分析,商人脑袋很自然的就用这个模型来思考问题,但作为IT从业者往往会忽视。经历了一些事后可能发现,原来一件正确的事不一定是适合的,所谓天时地利人和。
因此收益和难点(成本)这个问题很高明。本质上的理解我在一篇分享中阐述过,供您参考:某大型保险企业应用CMDB平台建设的实践经验
CMDB的核心收益是主数据库带来的较低的综合成本。只不过结合不同场景,其价值又体现在安全内控管理(账号、堡垒机、防火墙、漏洞补丁、合规检查、IP端口)、监控告警、自动化运维、资产管理、资源交付、发布管理、应急管理、ITIL流程管理、容量管理等具体领域。没有主数据库,上面这些工作都要自建配置库,大型数据中心情况下整体成本会很高。
但主数据库这种架构天然导致了推广的悖论,因为人们总是对全局和个体、长期和短期之间纠结平衡,且整体上会朝着熵增的趋势发展。CMDB建设者从长期、全局的视角来做配置管理工作,但造成各(ge)个(huai)部(gui)门(tai)短期成本提升,这对领导都是一件有难度的事,何况几乎没有什么权利的CMDB团队?换句话说,CMDB本身是一件短期成本高,但从全局和长期才能体现收益的事情,想想人们买保险的心情!
解决办法我也上面一篇分享尝试做了分析,欢迎大家一起交流。抽象的说就是:
1.要获得高层权利支持
2.通过具体场景来落实收益
3.设法转嫁和降低管理成本(蹭热度,抱大腿;和其他系统、流程形成利益绑定;把要求纳入现有奖惩考核)
4.提升用户犯错成本(以产品为单位明确责任人;流程自审计;公开审计结果)

9、CMDB建完后,如何保证数据的实时更新?相关的规章制度有哪些?

CMDB建好后,过一段时间后,数据就不是很准了。原因就是有很多操作,并没有经过CMDB的环节。有没有运维的标准流程,让所有的操作都能通过CMDB?或者介绍一下贵单位在实际使用CMDB时的流程,保障CMDB中的数据永远都是最新的?

回复:数据自动发现肯定是第一选择。对于无法自动发现的,要考验流程管理水平。公司里有很多规章制度,执行效果如何?大家心里有数。个人浅见:规章制度都只是要求,是目标。目标的执行落地,要么是自上而下的外部力量,要么靠自下而上的内部力量。外部力量比如说领导重视、外部审计、公司考核制度,这些通常这些手段因为CMDB得不到上层重视落地效果不明显。内部力量可能是主要的方向,比如说切合运维的场景驱动,还有我比较提倡的流程“自审计”。把录入CMDB作为其他运维活动的依赖条件,像设备初验、资源申请、主机上线、备份申请等等。利用“利益”把大家绑定起来,才能以最小的成本让配置管理要求真正落地。

10、CMDB能解决服务器相关各类资产的准确性难题吗?

服务器资产管理,目前还在用excel表格来管理,想上一套工具,但纠结在用资产管理工具还是用CMDB配置管理工具,感觉都能实现?又感觉都差点意思。

回复:如果只是定位硬件设备的资产管理,资产管理工具还是CMDB都行。但一般企业发展下去都会走CMDB这条路来打通各种运维平台和服务流程,从这个角度来说直接上CMDB综合成本会更低。
数据准确性方面,硬件资产可以利用部分数据自动发现的手段获得CPU、内存、存储、HBA这类配置信息。但设备位置和序列号这个盘点用到的关键对应关系,如果没有RFID这种手段的话,还是要靠流程来控制,这比较考验流程设计水平了,需要和相关部门协调好,才能保证数据准确性。

11、如何从数据类型和过程拆解数据治理的逻辑,分而治之?

回复:
CMDB的数据可分为自动发现数据和人工录入数据两大类。第一策略是尽最大努力扩大自动发现范围(因为自动发现的数据一定是最准确),降低配置管理的成本。常见的自动发现数据源有云管平台、安全管理系统、网管平台、负载均衡系统、带外管理系统等,总之要团结一切能够自动发现的力量。但接下来总要面对人工录入数据,这里用水池模型来解释。要一个水池干净,一是保证流入的增量干净,二是净化水池中的存量,三是要水循环流动起来。类似的,CMDB增量变更数据由场景流程来控制,存量数据靠数据资产明确属主并提高犯错成本。最后通过场景消费形成正反馈机制。三管齐下。

12、cmdb自动发现数据更新?

自动发现数据是放入调和库,还是直接更新? 一般更新策略是什么? 有更新后是否对更新内容追踪核实,更新原因?与所做变更对应?

回复1:CMDB自动发现数据是否能够自动更新,取决于你的业务需求;

  1. 如果你的CMDB供给给自动化操作的场景,CMDB发现的数据直接写入到CMDB影响会很大; 2.我们现在的做法是先放入到自动发现数据库,人员审批后自动更新到CMDB; 3.未来根据使用的情况,如果发现的数据都是可以直接更新的,我们可能会采取直接更新的策略。

回复2: 楼上的回答很完善了,我也推荐针对重要的属性,尤其是用于自动化运维的,采用先入调和库,再通过人工审核后更新CMDB正式库。从程序效率上,也是先全部入调和库,再和正式库比对会更可控一些。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论0 条评论

Ctrl+Enter 发表

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30