拒绝“ 背锅”！数据治理从策略到落地，发挥 CMDB 价值！

2023-02-22
广东
本文字数：3016 字
阅读完需：约 10 分钟

小魏是某银行配置经理，这天，银行部门年度会议上，运维领导突然说：“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 存在着数据质量问题，准备进行治理时，切不可“头痛医头脚痛医脚”，我们要先从本质上认真思考治理的数据对象才好决定相应的治理策略。思考的维度有很多种，本文将从数据的录入方式这个相对通用的维度出发来思考治理策略。

自动录入

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

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

人工录入

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

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

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

自上而下：指对于人工录入数据的治理办法，一定需要和领导达成一致并且尽可能在会议上获得领导背书，这个领导的职权范围需尽可能覆盖 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 必须足够友好，尽最大可能为人工维护数据进行减负。