CMDB数据治理-从治理策略到工具落地

字数 3098阅读 1643评论 0赞 2

小魏是某银行配置经理，这天，银行部门年度会议上，运维领导突然说：“CMDB是我们整个自动化运维平台的基础，必须发挥好他主数据的价值，让大家尽可能都感受到他的价值，注意一定不能因为数据质量的问题导致大家不愿意用！”

配置经理小魏很头痛，满脑子都是，我该怎么办？

现在都是别人发现数据有问题的时候告诉我，我咋能实时感知我CMDB的数据质量呢？
小王前几天建议说写个脚本去检查，这我也不知道检查哪些指标是合理的啊？（搁置..）
检查出来了，让他们改也太难了，不改也不影响他们，反正都是我背锅。

这时候他想起，之前看到嘉为蓝鲸结合多年CMDB项目建设实践的角度撰写的技术分享，受到了启发。文中提到：运维平台的建设离不开CMDB，甚至可以说CMDB建设失败会直接导致整个平台的价值大打折扣。因此，众多企业的选择从CMDB开始建设，但是建设效果与蓝图往往存在着“天差”。

这个“天差”来自于企业CMDB的承建方会面临的各种问题叠加：

跨部门协同困难、人员抵制“新系统”的内在情绪；
CMDB显性价值太弱、建设初期“升本降效”；
CMDB数据不准、数据缺乏审计机制等。

这些问题错综复杂且通常分布在不同的建设阶段，其中数据不准会贯穿CMDB从建设到运行到运营的整个周期，堪称企业配置经理的“心头大患”。

01. 为什么需要数据治理

首先，我们可以回归到企业建设CMDB的目的：作为运维主数据支撑平台供其他消费场景的使用，从而无需各系统重复建设配置库，降低数据维护成本，同时保障主数据在平台内的一致性和准确性。

为什么数据一定要准确？是因为其他系统需要在消费CMDB的数据辅助完成自身业务的执行（如：监控告警、应用发布系统等），这是CMDB建设价值的核心体现。如果CMDB的数据不准确或者时效太差（更新不及时），阻碍了其他系统业务的运行甚至影响了业务连续性，CMDB在企业内的可信度就会大大降低，甚至“无人敢消费”，最终沦落为和资产台账系统无任何区别的“线上Excel”，那就代表着这个CMDB的建设已经处于失败边缘了。

其次，我们还可以从企业配置管理建设团队的角度来看，CMDB的数据质量是个“人尽皆知”的难题。企业立项后，负责建设和持续运营CMDB的配置经理必定会收到来自领导和其他消费方的“灵魂拷问”：

“CMDB的数据质量你准备如何保障，有什么方案吗”
“我每个季度需要一份数据质量改进的报告，能给出吗？”
“你如何保障给我消费的数据一定是准确的？”等等。

企业CMDB的建设本就是一项跨部门“推倒重来”的IT规划活动，如若不能持续性地处理好数据质量的问题，消除领导和消费方的焦虑，轻则项目效果差团队绩效受损，重则项目失败。

因此，无论是从CMDB对IT运维的价值出发还是从CMDB建设团队的建设成果出发， CMDB的数据准确性都是CMDB能否建设成功的核心因素之一，数据治理是CMDB建设过程中不可或缺的一部分。

02. 数据治理的基本策略是什么

当我们已经认识到当前CMDB存在着数据质量问题，准备进行治理时，切不可“头痛医头脚痛医脚”，我们要先从本质上认真思考治理的数据对象才好决定相应的治理策略。思考的维度有很多种，本文将从数据的录入方式这个相对通用的维度出发来思考治理策略。

1）自动录入

对于“自动录入”的数据，其实治理策略是清晰的：保证采集源端数据的准确性。

落到现实情况中，一般可细分为两种：

2）人工录入

对于“人工录入”的数据，治理策略将会复杂很多，“对人的管理一定都是最难的”，如果人不重视，职责不清，认识不足，对于这类数据的治理将无从谈起。

基于我们的经验，要做好对“人工录入”数据的治理，推荐下述原则：

3）“自上而下，责权清晰，数据说话，闭环保障”

自上而下：指对于人工录入数据的治理办法，一定需要和领导达成一致并且尽可能在会议上获得领导背书，这个领导的职权范围需尽可能覆盖CMDB数据的所有人工维护团队，能覆盖消费团队则会更佳。

责权清晰：指CMDB建设团队需明确好角色和职责分工，建议划分配置经理、配置管理员和配置Owner三大角色，三大角色需紧密协同才能保障好数据治理策略的落地。

配置经理：企业CMDB建设的负责人，负责CMDB建设的价值效果和运营治理机制的框架制定；
配置管理员：企业CMDB各核心域对象的负责人，负责相关领域IT对象在CMDB中落地的建模、管理和治理机制工作；
配置Owner：企业CMDB配置项实例的维护负责人，负责保障相关数据的录入、更新、下线等日常维护操作。
数据说话：治理策略在运行过程中，一定是基于有理有据的数据来推动相关机制的持续运行的，而不是模糊的说辞。
如经过我们治理机制的检查，你这边的不合规数据有XX条，具体如下表格，目前整体质量评分为XX分，其他数据源平均评分为XX分，你这边低于平均线XX%，目前已经影响了全局质量评分XX%，需尽快调整。
面对用户投诉：我们据数而论进行解释：当前影响到XX系统的不合规数据共有XX条，主要不合规原因是XX，我们基于质量趋势发现是某月某日突然出现了质量下降，目前判断是当天XX系统变更导致，预计XX时间可以修正完毕。

这样可以给到用户和领导清晰、明确的质量问题分析情况，体现平台的运营价值，稳定用户对CMDB数据质量的信任。

闭环保障：指治理策略在运行后，有了责权分工，有了运营数据，最后一步那就是需要有个机制确保“监督者”，发挥作用保障不合规的数据能被配置Owner按时按质的修正完交付给用户，通过修正不合规数据实际解决用户消费的问题，这才是数据治理的真正闭环，也是治理价值的最终体现。这个机制需要两个核心点：感知与修正。

感知：主要面向配置经理和配置管理员，要让“监督者”能实际感知到CMDB数据质量因修正带来的变化，能感知到部分配置Owner的修正完成/逾期情况便于触发管理动作。
修正：主要面向配置Owner，对于Owner来讲，修正是个压力也是个苦力活，压力的感知是必须的（如：系统明确告知无法按时修正的话将上报通知配置管理员和配置经理），无压力则无动力，苦力活的解决也是 “减负增效”的核心，落到产品工具上来讲，修正机制的产品设计体验对于配置Owner必须足够友好，尽最大可能为人工维护数据进行减负。