【摘要】雖然我們正在運維的數字化工作空間中協同運作，但我們需要正視的是我們對運維資料的認識及應用還處於皮毛，雖有理念但缺乏必要的、可執行的方法。如何借鑑大資料領域資料治理的經驗，反思運維資料平臺建設應該關注的問題，減少不必要的坑，做好運維資料治理，讓運維資料更好用，用得更好，完善運維數字化工作空間，是本文的目的。

【作者】彭華盛，騰訊TVP，10年+的金融領域運維工作，期間負責參與運維組織、流程、工具建設，包括重大業務系統與資料中心工程性專案實施，標準化工作流程構建，平臺工具體系的規劃與研發、數字化轉型研究與實施相關等，對金融領域的運維有較全面理解，更多資訊見個人公眾號“運維之路”

【主要觀點】

• 運維資料分析需要借鑑當前傳統大資料領域的資料治理經驗，提高資源投入產出比，少走彎路，少跳坑。

• 運維資料體系包括“技術平臺、應用場景、資料治理”三部分，運維資料治理的目標是讓運維資料更好用， 用得更好。

• 運維資料分析場景圍繞在“增強業務連續性保障、提升軟體交付效率、提高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等理念，將機器優勢與運維專家經驗相結合，形成資料洞察/預測、決策/自動化、執行/任務的閉環。利用豐富的資料消費場景，反向發現資料質量問題，來持續加強資料治理水平。

總結

他山之石，可以攻玉。借鑑大資料領域成熟的資料治理方法，將有助於運維團隊提前認識到運維資料建設過程將面臨的痛點，減少不必要的坑，並提前佈局相關措施提升運維資料專案的成功，讓運維資料更好用，用得更好。相信隨著運維數字化工作空間的不斷建設，掌握線上的基礎、執行、體驗資料的運維團隊將發揮更大的作用。