数据治理对运维数据体系的思考与启发 | 运维进阶

发布时间：2025-11-05 08:14:11 来源：码上建站 作者：域名

【摘要】虽然我们正在运维的数字化工作空间中协同运作，但我们需要正视的治理是我们对运维数据的认识及应用还处于皮毛，虽有理念但缺乏必要的对运、可执行的维数方法。如何借鉴大数据领域数据治理的据体进阶经验，反思运维数据平台建设应该关注的数据思考问题，减少不必要的治理坑，做好运维数据治理，对运让运维数据更好用，维数用得更好，据体进阶完善运维数字化工作空间，数据思考是治理本文的目的。

【作者】彭华盛，对运广发证券数字化运维研发团队负责人。维数超过10年的据体进阶金融领域运维工作，期间负责参与企业运维组织、流程、工具的建设，包括各类重大业务系统项目与数据中心工程性项目的实施，免费信息发布网数据中心标准化工作流程构建，运维工具体系的规划与研发、数字化转型研究与实施相关等工作，对金融领域的运维有较全面的理解。近年来专注数字化转型研究，探索推进数字化技术与业务转型双轮驱动的协同模式，推进业务数字化转型。平时喜欢研究新技术、新理念、思维模式、产品设计等等，乐于分享。腾讯TVP成员。个人公众号：运维之路

【主要观点】

运维数据分析需要借鉴当前传统大数据领域的数据治理经验，提高资源投入产出比，少走弯路，少跳坑。

运维数据体系包括“技术平台、应用场景、数据治理”三部分，运维数据治理的目标是让运维数据更好用， 用得更好。

运维数据分析场景围绕在“增强业务连续性保障、提升软件交付效率、提高IT服务质量、辅助提升客户体验”四点，IT技术网涉及“监控、日志、性能、配置、流程、应用运行”6类数据。

运维数据治理主要包括元数据、主数据、数据标准、数据质量、数据模型、数据安全、数据生命周期7部分。

运维数据治理直击实际问题，以应用场景为驱动，选择必要的治理内容，有侧重、有步骤的推行运维数据治理，而非大张旗鼓的搞个运维数据治理项目（有人、有钱的背景下忽略这个观点）。

运维数据治理可以考虑采用“摸家底、建标准、促消费”三个步骤。

前言

今天，领先的数字原生企业不断用数字化手段颠覆传统行业，传统行业内领先的企业也在积极拥抱数字化，国家也适时的源码库将“数据”列为生产要素参与分配，推动了以数据为关键要素的数字经济进入了新时代。站在企业内运营后台的运维部门，运维属于数据密集型工作，团队的价值创造都是在运维数字化工作空间中运作。

在运维数字化工作空间中，运维利用各种代理，将人与机器、软件系统连接在一起，通过线上化的运维流程或规程将参与者的运维协同形成连接，再基于“组织、流程、平台”能力组装连接成为运维场景，构成了运维的数字化工作空间。今天，如果运维失去了对运维数据的控制，运维连续性保障将失控，更谈不上提升IT服务质量、加快IT交付速度、辅助提升客户体验的价值创造。运维数字化空间与滴滴的出行数字化空间类似，滴滴用手机定位这个超级传感器，将乘客、司机、汽车三个参与者做了一次连接，通过数字地图将出发点，目的地、路况、路线图与参与者又做了一次连接，再通过实时的打车、坐车、评价、信用等运营模式做了连接，形成一个出行的数字化空间。

虽然我们正在运维的数字化工作空间中协同运作，但我们需要正视的是我们对运维数据的认识及应用还处于皮毛，虽有理念但缺乏必要的、可执行的方法。随着运维数据平台的建设，将极有可能出现当前大数据领域出现的数据孤岛、数据不可用、数据质量不高、融合应用难、有数据不会用等诸多问题。上述问题，在当前运维领域资源投入不足显得尤其重要。如何借鉴大数据领域数据治理的经验，反思运维数据平台建设应该关注的问题，减少不必要的坑，做好运维数据治理，让运维数据更好用，用得更好，完善运维数字化工作空间，是本文的目的。

1 数据治理背景

从1997年“大数据”概念从NASA武器研究中心第一次提出，到2001年gartner提出大数据模型，到2004年google推出的大数据技术论文，到接下来大数据、人工智能、云计算等技术的广泛应用，再到今天数字时代，企业已逐渐了解数据所蕴含的价值，对数据的重视程度越来越高，投入大量资源进行大数据研发与应用。但我们必须承认，国内很多金融企业在大数据技术应用前并不是很重视数据治理，出现像投入大量资源建设大数据平台，但用的时候又发现报表不准、数据质量不高，导致项目没有达到预期效果的普遍性问题。上述问题促进企业反思，发现在数据从采集、存储、计算、使用过程中，少了数据管理的步骤，即数据治理缺失。今天，数据治理已经被企业广泛认可为必要的基础性工作，以下整理一下数据治理所要解决的痛点：

首先，信息孤岛，有数不能用。数据孤岛可能存在掌握数据的人主观上不愿意共享，也有客观上担心数据共享存在敏感性问题，或数据与数据关联性不够导致不能有效连接。

第二，数据质量不高，有数不好用。没有统一的数据标准导致数据难以集成和统一，没有质量控制导致海量数据因质量过低而难以被利用，没有能有效管理整个大数据平台的管理流程。

第三，数据不可知，有数不会用。不知道数据平台中有哪些数据，也不知道这些数据和业务的关系是什么，不知道平台中有没有能解决自己所面临业务问题的关键数据。

第四，数据服务不够，有数据不可取。用户即使知道自己业务所需要的是哪些数据，也不能便捷自助地拿到数据，相反，获取数据需要很长的开发过程，导致业务分析的需求难以被快速满足，而在数字时代，业务追求的是针对某个业务问题的快速分析。

在运维领域，运维数据分布在大量的机器、软件、“监管控析”工具软件上，除了上面大数据领域提到的信息孤岛、质量不高、数据不可知、数据服务不够的痛点外，运维数据还有以下突出痛点：

- 资源投入不够：从组织定位看，运维属于企业后台中的后台部门，所做的事甚至都很难让IT条线的产品、项目、开发明白“系统架构越来越复杂、迭代频率越来越高、外部环境严峻等等需要持续性的运维投入”，更不要说让IT条线以外部门理解你在做的事，在运维的资源投入通常是不够的。所以，运维数据体系建设要强调投入产出比，在有限的资源投入下，收获更多数据价值。

-数据标准化比例低：运维数据主要包括监控、日志、性能、配置、流程、应用运行数据。除了统一监控报警、配置、机器日志、ITIL里的几大流程的数据格式是相关标准，其它数据存在格式众多、非结构化、实时性要求高、海量数据、采集方式复杂等特点，可以说运维源数据天生就是非标准的，要在“资源投入不够”的背景下，采用业务大数据的运作模式比较困难。

- 缺乏成熟的方法：虽然行业也提出了ITOA、dataOps、AIOps的运维数据分析应用的思路，但是却缺少一些成熟、全面的数据建模、分析、应用的方法，主流的运维数据方案目前主要围绕监控、应急领域探索。

- 缺乏人才：如“资源投入不够”这点提到的背景，因为投入不足，很难吸引到足够人才投入到运维数据分析领域。

通俗一点来说，就是运维数据分析要借鉴当前传统大数据领域的数据治理的经验，提高投入产出比，少走弯路，少跳坑。

2 运维数据治理定位

以终为始，先分析运维数据应用场景。在《数智万物下，重新思考运维价值》中，我总结过“增强业务连续性保障、提升软件交付效率、提高IT服务质量、辅助提升客户体验”四个运维价值创造的举措，其中与运维数据息息相关的举措大概有如下内容：

以“连接网络+数据驱动”重塑“监管控析”运维平台化能力，全面提升业务连续保障能力（加强连续性保障）。

以主动的运行数据分析，挖掘系统架构及应用系统的潜在运行风险，反向推进应用架构的健壮性提升（加强连续性保障）。

利用运行数据运营分析，快速交付线上系统、产品、运营活动的运营实时分析看板，辅助业务决策（提升软件交付效率）。

建立系统退出机制，数据驱动释放IT资源（提升软件交付效率）。

增加客户行为数据的收集与分析，为产品设计的决策提供辅助数据（辅助提升客户体验）。

加强业务系统的性能管理，推动优化系统响应效率，提升客户体验（辅助提升客户体验）。

模拟客户行为操作监控，提前发现并解决潜在问题（辅助提升客户体验）。

建立评价IT服务质量的管理模型，以数据驱动IT运营效能提升（提高IT服务质量）。

建立统一的IT服务目录，开放面向性能、运营、客户体验等方向的数据分析能力（提高IT服务质量）。

要达成上述数据应用场景，我们需要用好监控、日志、性能、配置、流程、应用运行6类数据，场景与数据的关系如下：

- 监控数据：监控事件报警数据、监控性能/KPI指标数据两类，特点是实时、代理、海量、时序为主。

- 日志数据：机器运行日志、系统日志、应用日志，特点是海量、实时、非结构化、格式不统一、有业务相关数据。

- 性能数据：APM、NPM、BPM，或应用主动上报的性能数据，特点是海量、实时、贴近业务与用户体验、链路关系、格式不统一。

- 配置数据：围绕CMDB的配置CI、关系、架构数据，特点是CMDB方案较成熟，关系与架构数据复杂但自发现能力困难。

- 流程数据：围绕ITSM，以及其他运维场景工具（监管控析、安全、CMP等）记录的数据，特点是关键流程基于ITSM、实时性不够、大量琐碎工作来源于各类工具。

- 应用运行数据：记录在业务系统数据库中的系统运行数据，特点是与系统相关、贴近业务与用户体验、依赖研发支持、格式不统一。  

在文章《他山之石之运维数据》中，我举例过当前常见的运维数据平台项目有以下三种方式：

基于特定场景的数据分析应用：这种方案以运维痛点为切入点，针对特定的场景选择特定的数据，在解决方案上强调数据质量与算法。

“监管控析”分别管理数据，在上面建立一层汇集层。比如监控负责存储监控性能与事件数据，日志平台负责存储日志数据，CMDB存储配置数据，ITSM存储流程数据等。这种方式，通常是先有工具的功能使用，再有运维数据分析需求。

统一的运维大数据平台。这种思路通常拿一套大数据架构，日志用ELK或ELG，实时数据分析用fink，监控数据放influxDB等时序数据库，消费中间件用KAFKA……

可以看出，上面三种方式构建的运维数据体系主要包括：“技术平台+应用场景”两个部分组成，其中技术平台指支撑运维海量数据的“采、存、算、管、用”的技术架构，算法也属于技术平台的一部分；应用场景指数据的“用”，包括：面向人使用的可视化、低代码/服务化的开发工具，以及面向系统使用的数据服务API、感知或决策类的可视化、驱动自动化。鉴于运维数据有着来源多、标准化、实时、海量、非结构化、格式不统一等特点，仅从“技术平台+应用场景”两个角度看运维数据平台，很容易将运维数据相关项目建成一个个数据孤岛式的数据应用场景，无法发挥数据价值。需要在“技术平台+应用场景”的基础中，加上“运维数据治理”，三者关系相辅相成，缺少技术平台则失去基础，缺少应用场景则失去价值，缺少运维数据治理则不具备扩展性。

基于“技术平台、应用场景、数据治理”三个部件构成的运维数据体系的关系可以考虑有以下架构图，右下是针对技术平台提供的“采存算管用”的技术解决方案，右上是针对数据应用场景，左边是运维数据治理。

总结下，运维数据治理是运维数据体系三大关键之一，运维数据治理要借鉴传统大数据领域数据治理的成熟方法，结合运维领域特点打造运维数据治理方法，以获得高质量、完整、互联的数据，构建持续优化型的数据生命周期管理，让运维数据更好用，用得更好，以完善运维数字化工作空间。

3 运维数据治理主要内容

大数据领域的数据治理主要包括元数据、主数据、数据标准、数据质量、数据模型、数据安全、数据生命周期7部分内容，以下结合运维领域特点，谈一下我对运维数据治理的内容。

1）元数据管理

因为后面还会提到主数据、交易数据，讲元数据前我觉得有必要介绍一下三者区别：

- 交易数据：描述具体的事件或行为，通常是某个时间发生的行为，比如运维里的端终性能、客户行为、监控KPI指标、监控报警、日志等数据。

- 主数据：具有稳定、可共享、权威、关系等特征的数据，比如主机、架构、拓扑关系、人员关系、流程、域名等数据。

- 元数据：元数据是指描述数据的数据，是指从信息资源中抽取出来说明数据特征、内容的结构化的数据，用于组织、描述、检索、保存、管理。

运维数据的应用中，我们通常对不同数据采用不同的技术方案，比如日志放在ES，监控KPI指标数据与工具选型有关，这种源端数据分散的现状导致我们的运维数据指标的分析口径不清晰，出现数据问题很难追遡。元数据这种对于数据的描述、来源、口径等管理，有助于我们管理动态、分散在各处的数据，形成数据服务目录体系，就类似于图书馆图书的检索信息、数字地图中一个道路的位置信息，运维领域源端的日志解析规则、监控报警字段描述、监控KPI时序数据描述等，也属于运维元数据。

2）主数据管理

主数据在信通院发布的《主数据管理实践白皮书1.0》中的定义是：“指满足跨部门业务协同需要的、反应核心业务实体状态属性的组织机构的基础信息。主数据相对交易数据而言，属性相对稳定，准确度要求更高，唯一识别。”主数据管理是指一整套用于生成和维护主数据的规范、技术和方案，以保证主数据的完整性、一致性和准确性。主数据与交易数据不同，主数据的内容具有稳定、可共享、权威几个特征。总结一下运维主数据的主要数据：

与机器相关的：环控、机房、网络、服务器、存储等。

与软件相关的：系统软件、数据库、中间件、应用系统、DNS等。

与关系相关的：部署架构、逻辑架构、调用链路、上下游关系等。

与人相关的：运维内（运维操作、SRE、运维开发、流程经理等）、IT部（开发、产品、测试等）、IT外的业务人员、客服、客户等。

与流程相关的：与ITIL相关的变更、事件、问题、配置等，以及团队内协同规程等。

与规则相关的：监控策略、性能管理、容量管理等。

3）数据标准管理

数据标准是为了规范对数据的统一理解，促进数据共享，增强跨团队协作中对数据定义与使用的一致性，降低沟通成本。数据标准通常包括组织架构、标准制度、管控流程、技术体系四个方向，应用统一的数据定义、数据分类、编码规范，以及数据字典等。在运维领域数据标准可以考虑如下：

- 组织架构：确定运维元数据、主数据、交易数据涉及的管理决策、数据业主、运营、质量、消费等团队或岗位角色，以及所涉及的责权利。

- 标准制度：围绕源端数据制定分类、格式、编码等规范，制定日志、报警、性能指标等数据标准，这里的标准应该与技术规范区别开。

- 管控流程：要对运维数据管理的供应、变更、申请、共享、质量、运营等流程进行规范化、线上化。

- 技术体系：综合考虑平台架构、接口规范、应用场景等，围绕运维数据的“采存算管用”建立运维数据平台。

4）数据质量管理

数据质量管理是指针对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的数据质量问题，进行识别、度量、监控、预警等管理活动，并通过改善和提高组织的管理水平提高数据质量。相比其它数据，运维数据有如下特点：海量的非结构化数据、秒级以内的实时数据、源端数据标准化程度低、应用场景对实时性要求高、资源投入低、缺乏经验指导。所以，运维数据质量管理，应该聚焦在有限资源的背景下，围绕实时、在线、准确、完整、有效、规范等关键字推进。

5）数据模型管理

数据建模是基于对业务数据的理解和数据分析的需要，将各类数据进行整合和关联，使得数据可以最终以可视化的方式呈现，让使用者能够快速地、高效地获取到数据中有价值的信息，从而做出准确有效的决策。运维数据的模型管理方面，一是要借鉴传统业务大数据的指标数据模型设计方法，毕竟大数据的数据模型已经在很多实时的反欺诈，非实时的海量数据分析等领域成熟运用多年；二要结合运维数据消费场景实时、准确等特征，利用流式计算方式区分源端原始数据，旁路后的加工数据，根据规则生成的指标数据等方式，设计运维实时数据模型；

6）数据安全管理

数据安全管理是实现数据安全策略和流程的制订，数据安全管理需要遵循国家、行业的安全政策法规，比如网络安全法，等级保护，个人隐私安全等要求。另外，数据治理将依赖数据来源、内容、用途进行分类，所以数据安全管理还要求对数据内容敏感程度、影响等进行分级分类。运维数据都是生产数据，生产数据的安全管理，要从技术、管理两个角度对环境、研发、测试、运营、消费进行全流程的安全管理。

7）数据生命周期管理

与软件生命周期（SDLC）管理类似，数据也有生命周期，通常是指数据从产生、采集、存储、整合、分析、消费/应用、归档、销毁等过程的数据管理。数据价值决定着数据全生命周期过程的管理方式，数据价值可能会随着时间的变化而递减，影响着采集粒度、时效性、存储方式、分析应用、场景消费等。数据生命周期管理对于运维是比较好理解，以存储方式为例，在运维过程中为了保障系统稳定性，提升系统性能，我们会对关系型数据进行分库设计，对日志数据进行在线、近线、离线的数据存储方式。对运维数据生命周期各个阶段的特点采取不同的管理方法和控制手段，能从数据中挖掘出更多有效的数据价值。

4 以场景驱动运维数据治理

从上一节可以看出，数据治理是一个复杂的工程性工作，每一部分内容范围很大，涉及大量资源投入，如果要全面铺开做运维数据治理，资源无法保障。所以，我认为运维数据治理要直击实际问题，以应用场景为驱动，选择必要的治理内容，有侧重、有步骤的推行运维数据治理。本节从运维指标体系角度，谈谈我对运维指标体系建设过程中的数据治理内容。

先简单聊一下运维指标体系的背景。运维指标体系的建设主要基于运维研发效能、运维数据自助服务、运维平台扩展性的痛点提出的解决方案。希望通过建立运维指标体系，能够不断沉淀可复用、可共享、可组装的数据指标，并基于标准化的指标建立自助式、低代码的数据应用工具，最终达到提升运维数据研发需求的交付速度，提升端到端的研发效能。而在指标研发过程中，很容易出现同一个指标重复建模、开发，不仅导致工作量成倍增加，指标沟通成本过高，还带来一致性问题，需要引入数据治理的元数据、主数据、标准的内容。

元数据定义运维指标。举个例子，针对特定业务的实时运行看板是我们比较常见的运维数据研发需求，这类看板通常涉及多个系统的数据开发，理论上前期开发的数据指标可以为后面的需求提供基础，但由于数据指标的处理逻辑写在代码上，指标定义不清导致实际的复用性很低。运维数据指标的元数据描述了指标是什么，如何生成，统计口径是什么，数据相关方是谁等基本信息，可以说元数据定义了运维指标。可以考虑分：基本信息、统计信息、口径信息、管理信息。

- 基本信息：比如定义指标分类（硬件指标，软件性能，业务运营、交易等），指标编号（唯一识别编号），指标属性信息（中文名称、英文名称、指标描述等）等。

- 统计信息：指标维度（按机房、机架、主机、系统、渠道、功能号、相关干系人或部门等），统计周期（采集、计算、消费使用的周期），数据格式（数据类型，长度要求等）等。

- 口径信息：指标类型（基础指标、组合指标）、数据来源（统一日志系统、集中监控系统、统一监控事件工具等）、数据产生方式（ 手填报、系统加工等）、数据加工口径等。

- 管理信息：数据业主，数据供应方、维护时间与人员等。

主数据管理指标维度。在上面的元数据管理中提到指标维度，举个例子，在业务连续保障管理中的“互联网交易量”指标，我们遇到从多个不同维度去统计分析交易量指标，比如：系统、站点、终端类型、终端版本、功能号、机构等，这些维度在互联网相关的其他运营、性能指标中同样也会用到。上述的维度信息在指标体系中尤其重要，具有稳定、可共享、权威、连接性等特征，适合作为运维主数据管理。在运维领域中，CMDB配置是运维“监管控析”运维平台体系要实现互联互通的核心数据，在众多运维场景中都将被共享使用。传统CMDB已经实现了操作系统、主机、计算资源、存储资源、网络、机房等信息的配置管理，应用CMDB则从主机进一步向主机上的应用系统、模块、软件、上下游关系、终端、应用配置、环境配置等扩展。通过CMDB持续建设将各维度的配置数据、关系数据、架构数据都由CMDB统一管理，CMDB具备演进为主数据库的条件。

数据标准规范指标源数据。运维指标的生产流程通常包括：采集原始数据，根据模型规则引擎加工数据，写入指标流水，指标消费应用。其中“根据模型规则引擎加工数据”是一个工作量大、琐碎的步骤，要减少加工步骤的返工，保证数据加工过程稳定，并生成正确的指标流水数据，需要确保采集的原始数据的类型、长度、周期等信息可靠。另一边，运维指标数据来源于数据监控、日志、性能、配置、流程、应用运行6类数据，每一类数据的源端很多。以监控体系为例，监控包括了多个层次，多个监控工具共同运作，需要规范各个监控工具生成的性能KPI指标、报警数据的标准化。所以，利用数据治理中的数据标准的制定，有助于规范数据平台建设时对数据的统一理解，规范指标源数据的标准化，减少数据出错，增强数据定义与使用的一致性，降低沟通成本。

关于运维指标体系与数据质量（如何推进运维指标的实时、在线、准确、完整、有效、规范）、数据模型（如何线上化指标模型设计，映射到实体）、数据安全（如何有效控制指标在研发、运营、消费时的安全）、数据生命周期（如何针对性制定指标数据的存储、时效性）的其它思路，后续实践后再进一步分析。

以“运维数据更好用， 用得更好”持续提升运维数据治理成效。前面提到，运维数据治理的最终目标是让运维数据更好用，用得更好，前者与数据质量相关，后者与数据应用场景有关。我个人觉得可以从量化与具象化两种方式评价，量化即线上指标化，比如CMDB数据异常次数、CMDB接口调用次数、交易指标消费次数、具体系统的平均软件发布时间等指标化数据；具象化则是从数据价值交付链路中断情况、用户体验评价等角度评价。在组织与机制上，要建立配套的运维数据治理的运营角色，主动从数据质量与数据应用场景上挖掘流程机制、技术能力、工具平台、场景消费等环节的不足，制定优化措施，跟进措施的执行落地，形成“数据洞察、辅助决策、跟踪执行”的闭环，持续提升运维数据治理成效。

这里再重复本节点的主要观点：运维数据治理要直击实际问题，以应用场景为驱动，选择必要的治理内容，有侧重、有步骤的推行运维数据治理，而非大张旗鼓的搞运维数据治理项目。当然，如果你所在的运维团队有人、有钱，忽略此观点。

5 运维数据治理步骤

数据治理是一个长期过程，在运维数据体系建设过程中要有一个持续演进的运维数据治理步骤。以下整理三个步骤：摸家底、建标准、促消费，抛砖引玉，欢迎大家指正。

第一阶段：摸家底，落地数据资产。在企业数字化转型下的大背景，围绕“增强业务连续性保障、提升软件交付效率、提高IT服务质量、辅助提升客户体验”四个方向，构思要实现什么运维数字化场景。再基于场景，梳理运维数据分析涉及监控、日志、性能、配置、流程、应用运行6类数据存储在哪里，工具或平台架构、数据结构，数据实时性，数据完整性，数据正确性，数据标准化程度等方案。同时，建立统一的数据“采、存、算、用”的基本能力，能够实时整合、加工运维源端数据，形成运维元数据资产管理能力，具备基于已有数据资产快速交付多维度数据视图的需求。

第二阶段：建标准，提供一站式的管控能力。结合第一阶段的成果，建立数据管控的组织、流程、机制、标准、安全体系能力，建立一站式的运维数据平台，从运维数据应用场景角度梳理企业数据质量问题，建立数据运营职能岗位、制定数据标准及配套的流程。基于运维数据标准，结合运维数据项目推动运维数据治理模块的建设，比如：以运维指标体系场景驱动落地数据资产管理模块/系统，以CMDB配置数据为基础落地主数据库。

第三阶段：促消费，以数据消费反向提升数据治理能力。首先，提供自助式服务能力，以用户为中心，加强运维数据运营效能，为用户提供直接获取数据的能力，直接为用户提供价值，向用户提供数据服务化能力，使用户能够自助的获取和使用数据。其次，提供人机协同应用能力，将数据沉淀为知识，形成运维知识图谱，结合ITOA、dataOps、AIOps等理念，将机器优势与运维专家经验相结合，形成数据洞察/预测、决策/自动化、执行/任务的闭环。利用丰富的数据消费场景，反向发现数据质量问题，来持续加强数据治理水平。

总结

他山之石，可以攻玉。借鉴大数据领域成熟的数据治理方法，将有助于运维团队提前认识到运维数据建设过程将面临的痛点，减少不必要的坑，并提前布局相关措施提升运维数据项目的成功，让运维数据更好用，用得更好。相信随着运维数字化工作空间的不断建设，掌握在线的基础、运行、体验数据的运维团队将发挥更大的作用。

相关文章