作者:监控易 来源:美信时代
发布时间:2026-09-21
你有没有经历过:想分析一下过去半年CPU使用率的趋势,结果发现数据分散在3套监控工具里,命名规则还不一样——同一台服务器的CPU,在工具A里叫“CPU Utilization”,在工具B里叫“cpu_usage_pct”。
想做个简单的趋势分析,光对数据就对了半天。最后放弃了。
这就是运维数据治理要解决的问题。

2025年12月2日,GB/T 43208.2-2025《信息技术服务 智能运维 第2部分:数据治理》正式发布。2026年7月1日实施。
这是ITSS体系框架里的标准,归口于全国信息技术标准化技术委员会(TC28)。第1部分《通用要求》(GB/T 43208.1-2023)去年4月就实施了。
值得关注的是起草单位阵容:南方电网数字电网集团牵头,联合了中国电子技术标准化研究院、太保科技、招商证券等45家单位。银行、证券、保险、电力、航空、通信、科技——全齐了。
这不是某一个行业的问题,是所有行业的共性挑战。
标准原文把要求分成了四个维度:
顶层设计。不能“边干边看”,要有规划。有明确的数据治理目标。
运维数据管理。数据的采集、存储、处理、使用要有规范。什么数据要采集、怎么存、怎么处理、谁能用,都要有规矩。
运维数据供给。数据要“可用、可信、可共享”——三个关键词,每一个都很难。可用,意味着数据是完整的;可信,意味着数据是准确的;可共享,意味着数据是标准化的。
运维数据治理过程。持续监控、评估、改进,不是一次性项目。做完一版扔在那里不管了,那不叫治理。
说白了就一句话:把分散在各处的运维数据管起来,让它能被用起来。
这些误区我是在实际项目中一遍一遍看到的。
误区一:“数据治理只是合规要求,跟日常运维无关。”——这句话我听过太多次了。直到有一次,客户想用AI做异常检测,结果发现历史数据质量太差,模型根本训练不出来。数据治理不是合规负担,是所有上层应用的前提。
误区二:“我们系统少,不需要数据治理。”——我见过只有3套系统的客户,数据照样对不上。问题不在数量,在源头是否统一。哪怕只有两套工具,如果CPU使用率一个叫“cpu_usage”一个叫“CPU Util”,数据治理的工作量一样大。
误区三:“等数据治理做完了再上AIOps。”——这两件事可以并行。先统一采集和存储,然后逐步补充治理规则。边用边治,比等“完美”了再用更现实。等什么都完美了,可能已经过去了两年。
标准已经实施3个月了,很多团队还在观望。我的建议是:不用等,从最小可行单元开始。
第一步:选择一个系统做试点(建议2-3周)。不要一上来就想覆盖所有系统和所有数据。选一个核心业务系统,把它的运维数据(监控指标、告警记录、配置信息、日志)全部梳理一遍。搞清楚三件事:数据从哪里来、数据长什么样、数据到哪里去。这个试点能帮你建立一套可复用的流程和方法。
第二步:建立数据字典(建议2-4周)。运维数据治理的核心是统一命名。把试点系统的所有指标列出来,逐一标准化:CPU使用率统一叫“cpu_usage_percent”,内存使用率统一叫“memory_usage_percent”,以此类推。数据字典一旦建立,后续扩展到其他系统就只需要补充新指标。
第三步:统一采集规范(建议与第二步同步)。标准化数据字典的基础上,建立统一的采集规范——采集频率(比如秒级/分钟级)、采集方式(主动拉取/被动接收)、采集精度(保留几位小数)。这些规范看起来琐碎,但没有它们,数据治理就是空中楼阁。
第四步:建立数据质量检查机制(建议第2个月开始)。每天自动检查三条:数据是否完整(有没有缺漏)、数据是否准确(有没有异常值)、数据是否及时(有没有延迟)。把检查结果生成一份“数据质量日报”,谁负责的数据出了问题,一目了然。有了日报,数据质量就进入了“持续改进”的轨道,而不是靠被动发现。
GB/T是推荐性标准。但国标符合性正在成为运维服务采购、信创验收、等保测评中的事实门槛。
标准适用的场景写得很清楚:指导组织开展运维数据治理,组织评估自身能力,需方评估供方能力,第三方评估供方能力——从甲方到乙方到第三方,全链条覆盖。
先行对标是合规准备,更是能力建设。
数据治理国标的终极目标不是“满足检查”,而是把离散的运维数据变成可用的数据资产。
合规只是起点。谁能率先建立统一的数据治理体系,谁就能把高质量的数据转化成AIOps、容量预测、根因分析的燃料——这才是终局。
#关键词#GB/T43208.2-2025 #运维数据治理 #智能运维 #数据资产化 #ITSS