以场景驱动CMDB数据治理经验分享

字数 3246阅读 1943评论 0赞 5

内容摘要：

文章介绍了场景驱动的CMDB数据治理经验分享，包括专岗负责、流程保障、数据融合、场景驱动和闭环运营等方面。重点强调了规范化流程、任务责任明确、数字化看板等工作方式，以及技术治理场景的价值驱动和闭环优化。

当前摘要为AI生成

数据治理是 CMDB 项目实施中难度最大、成本最高的环节，是一个长期治理的过程，而行业很少提出 CMDB 数据治理的技术实现方案。 CMDB 数据治理不仅需要解决配置管理工程性的技术问题 ， 还要基于运维组织的特点 ， 建立适应性的配置运营能力、 设置专岗专责、 梳理配置目录、制定配置项管理机制、 落地流程、自动化策略、 定期建立配置数据质量监测或分析、 触发配置问题治理任务、技术运营等工作。在《运维数字化转型》书中，我 结合在 CMDB 数据运营的工作经验 ， 抽象建章立制、价值导向、问题驱动、闭环跟进四步走的 CMDB 数据治理方法 。本文，进一步细化以技术治理场景驱动CMDB数据治理的一些经验。

# 1.专岗负责
**明确分层次的专岗专责**。此处的专岗负责制包括CMDB治理统筹专岗、执行任务团队专岗 、执行治理任务专岗三级。其中，统筹专岗对数据治理整体治理水平的持续提升负责，来自横向优化角色；执行团队专岗负责传递、督促治理工作落实 ，对职能团队的治理情况起督促性作用，来自于职能团队 ；执行任务专岗责任配置项及配置属性的正确性，来自于职能岗位。
 **线上化建立专岗间协同**。基于“纵向到底、横向到边”的思路，CMDB能够纳管的IT资产范围越来越多， 引发配置项问题的源头也会不断出现，具体的 治理实施过程是一系列 琐碎的 工作。确保每一个数据问题都能够解决，需要从问题发现、问题修证、修复核实、“漏洞”优化建立一个全在线的解决方案。
![](/home/attachment/202312/01/1247669_170141532099322.png)

**责任细分到每一个任务**。 专岗负责制需要针对每一项数据问题任务化，每一项任务最好能够具体到某一个特定的人。一个任务如果允许多个责任人（非会签），容易引发分工、责任不明确、责任人之间意见分歧等导致任务进展缓慢的问题。我个人认为，任务更适合尽可能的细分到某一个责任人独立承担，且有明确的截止时间。虽然任务责任明确一个人，也可能带来责任人请假等问题，但总体效果看，能够避免推诿和分工不明确的突出问题。

# 2.流程保障
规范化的流程是机制能够顺利落地的保障基础。规范化是一种行为标准，能够约束个体的行为，建立一个有序的协同秩序，帮助协同中各个角色保持统一的协同意识，形成一个集团军作战的能力，提升组织整体工作效率。在一些小型团队里可能会更加强调单兵作战能力，但是当组织形成一定规模后，必要的规范化流程是必不可少的一部分。所以，我们会看到同业中很多运维团队在阶段性的。

为了推动规范化的落地，可以考虑建立“制度、标准、规程、时序”四级的机制。其中，制度重点关注行业、企业通用性的规范对于配置管理的要求。技术标准重点关注对制度进行分解，形成具体指导落地的配置管理与技术规范要求，重点关注角色、职责、协同、例行化工作等。规程是为了应对流程的迭代效率引入的流程管理要求，因为运维是高度强调复盘文化的组织，且对于复盘中发现的协同、操作等流程问题，以及工具平台、场景设计等技术问题，需要保持快速的迭代，防止问题的重复出现。CMDB数据治理规程的上线与修订需要保持高度的敏捷，来源可能是领导对于IT资产管理的一个临时决策，可能是事件复盘发现的配置问题，可能是合规检查发现的配置问题，也可能是某个数据消费场景发现的问题。当规程的执行步骤能够原子化为一个重复的数据操作或自动化脚本执行时，则要独立出来形成自动化时序。

**3.数据融合**

CMDB的数据治理是一个问题发现、问题修正、修正复核、 “ 漏 洞 ” 优化的过程，整个过程需要对配置数据、机器运行数据、流程协同数据进行融合。一方面，单独的IT资产配置数据在很多场景下无法判断数据是否正确，关联数据能够还能够让配置数据质量问题的可解释性更好；另一方面，数据质量问题任务是否完成，应该尽量由数据本身自动化复核来关闭；同时，配置数据消费场景也需要结合其他数据。

在技术实现上，可以考虑在CMDB、运行数据、流程协同之上建立一份数据融合后的配置治理主题数据。基于配置问题的时序策略可以直接从这份标准化的主题数据中，采用无代码的方式配置出具体的任务与任务完成的复核。
 
# 4.场景驱动

CMDB数据质量问题任务的尽快修正一直都是配置治理运营的难题。很多同业都提到 执行治理任务专岗对配置问题的修正重视程度不高。为了落实任务的处理，可以采用专项运动式活动与常态性工作结合的运营方式。技术治理场景是专项运动式活动的一种落地方式，技术治理场景借助管理要求，在短期内能够让各职能团队更容易接受，且能够吸引管理决策层的注意，更有利于治理工作的落地。同时，技术治理场景在设计上，是基于价值驱动，能够让琐碎的数据治理工作聚焦到一个主题，让治理成效最大化，并通过数字化绩效形式表达出来。比如：
* 基于主机效能管理的FinOps运营场景，在价值上推动了IT资产成本优化过程中， 可以将主机 未 按要求关联 系统， 主机 未及时下架等 问题 挖掘出来， 在配置质量上优化了IT资产配置纵向部署关系的配置治理；
* 基于主机时钟源、重启时间、过保时间、单电源等风险管理场景，在价值上推动了稳定性风险的防范过程中，可以将自发现代理问题、集群类型属性等配置问题挖掘出来。
* 基于系统上下游关系的应急、变更协同管理场景上，在价值上推动了协同的自动化，在提升协同效率过程中，可以将系统上下游关系有误、角色未保鲜等问题挖掘出来。
以技术治理场景为切入点与常态性数据质量问题任务，在实现思维上有一些区别。其中，技术治理场景认为“数据是对的”，场景分析对应到的负责人看到数据反映其技术管理成效低下，会驱动负责人主动去修正。常态性化数据质量问题任务是直接告诉数据责任方数据是错的，不修正会“考核”你。总的来说，技术治理场景 基于成效的价值驱动，在某些时候，能够形成自驱性的数据质量优化，促进落地效率 ， 推动配置数据保鲜。

# 5.闭环运营
一项成功的工作机制应该是能够形成闭环，并驱动持续优化。
CMDB数据治理是一项琐碎的数据挖掘的工作，需要利用一些连接工具把琐碎的事串起来。ChatOps、任务就是协同的连接利器。以ChatOps为例，ChatOps具备很多连接优点，比如：
* 企业IM是用户高频使用的协同工作空间；
* ChatOps精准地触达到具体的人；
* 协同群具备极为扁平的协同能力；
* 协同群聊有公示作用，驱动治理工作落地“卷”起来；
* 协同群聊能够更好建立在线的升级；
* 具有专项工作属性的群提升效同效率；
* ChatOps机器人能够代替人做自动化的工作；
* 机器人驱动的人机协同，简化员工沟通上的工作（很多技术工程师不太愿意做太多沟通性的工作）；

技术运营离不开配套的数字化看板及专项报告。其中，数字化看板关注实时的数据分析，专项报告关注某项技术治理场景的工作成效。在设计技术运营数字化内容时，可以考虑关注以下几点：
* 用户想看的信息：要明确看板与报告的用户是谁，不建议做一个适用于所有角色的报告，设计能够解决用户痛点与期望的数据洞察。
* 你想用户看到的信息：这类数据未必是用户自己想看到的，但是技术运营方出于运营目的要表达出来的信息，通常可以从表现“不好情况”的问题数据，比如按成效低下排TOP几。
* 你想表现出的成效信息：要让专项工作的人有成就感，或争取更多资源，需要将工作成效表现出来，比如最终的效果数据，或持续获取的效果变化均可。

另外，针对经常出现用户看不懂看板数据的问题，在设计上，可以参考在用PPT讲故事的形式，设计一个多页看板的内容顺序套路：概况、技术治理信息1、技术治理信息2、技术治理N、技术治理成效。
 
最后，自己要把技术运营当回事，持续的、主动的将技术运营的信息精准的触达到人，并在一些公开场合用数字化方式表达出来。

CMDB 数据治理

著作权归作者所有

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

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

以场景驱动CMDB数据治理经验分享

添加新评论0 条评论

文章目录收起目录

作者其他文章

相关文章

相关问题

相关资料