運維數據建設和管理方法，看這一篇就夠了
本文中，我們著重對運維領域的數據建設和管理進行展開，來描述運維數據的管理方式。
作者：顧黃亮來源：高效運維|2020-07-2911:00收藏分享
作者簡介
顧黃亮，十年研發運維經驗，涵蓋基礎架構、應用架構、數據庫、DevOps，有互聯網，電商，金融從業經歷。專注于DevOps在企業中的應用和落地，致力于企業智慧運維體系的打造。
參加多個行業、國家標準的編寫，《開源許可證使用指南（2018）》作者之一，國標《研發運營一體化（DevOps）能力成熟度模型》作者之一，《企業IT運維發展白皮書》作者之一，曾供職于航天晨光、上汽集團云計算中心，現任蘇寧消費金融安全運維部負責人。
前言
在數據的輸出和變現的過程中，場景化作為最終落地的載體，而運維數據的輸出和變現能力最終還是依靠前期的數據建設和質量管理，本文中，我們著重對運維領域的數據建設和管理進行展開，來描述運維數據的管理方式。
一、運維數據的變現歷程
運維數據的規模和企業規模、業務形態和運維能力有很大的關系，根據信通院的《企業IT運維發展白皮書》中所述，企業規模越大、業務形態越復雜、運維能力越高的企業，運維所納管的數據越多，運維數據變現的效果越好，相對應的，運維數據建設的層次越高，通常使用較為前沿的大數據和AI技術作載體來進行數據的價值交付。典型場景為，知識圖譜、智能監控、動態閾值、根因分析和故障自愈。
在企業規模較小、業務形態較為單一、運維能力較為一般的企業，運維數據變現較弱，更多的數據輸出強依賴場景，因此在這個階段，場景成為運維數據的唯一突破口，主要進行數據的被動采集、被動存儲和被動消費，特征為數據割裂和數據關聯性較弱，典型的場景化驅動主要為，資源管理、基礎架構監控、業務連續性保障和應急知識庫。
在運維數據的變現過程中，一般需要關注三個階段，數據由少到多、單維到多維、覆蓋面由內到外的階段；數據處理由簡單到復雜、技術單一到多樣化的階段；場景由基于需求到基于規劃、輸出能力由淺到深、自動化到智能化的階段，總的概括如下。
1、從數據獲取渠道出發，由少到多
在初級階段，運維數據來源局限于運維側自身，如資源數據、監控數據、文本數據、日志數據，隨著數據源接入進入全覆蓋的時候，運維數據已經覆蓋業務運營數據、后臺支撐數據、財務數據。需要說明的是，運維數據的獲取離不開運維數據輸出的強依賴條件，那就是場景輸出的需要，一切數據的根本都要基于運維能力輸出。
2、數據處理的能力決定了數據價值的范圍，覆蓋面由內到外
在這里，很多人可能疑惑，這不是大數據做的事嗎？說到底，大數據只是一個工具，而非一個職能，因此運維數據處理的能力與否，決定了數據匯聚層的價值模型，也間接的影響數據輸出的覆蓋場景，這也就是我們所理解的運維數據中臺。在這期間，重點要做的是數據的處理能力和數據的衍生能力。
3、有價值的場景化選型決定了數據變現能力，變現能力由淺到深
在我們所理解的變現過程中，其實是最終的價值輸出模型，最終也會得到三個結果，優化、反饋和貢獻價值。因此，有價值的場景化選型也必須遵照，從運維內部的優化開始，到信息科技領域的度量反饋（《建立數據指標體系，推動DevOps全鏈路度量閉環》一文詳細闡述），最后到數據衍生體系的貢獻價值，例如智慧運維、項目后評價體系、信息科技的成本復盤、成本中心的利潤測算。
下面通過一張圖可以通俗的理解。
二、運維數據的管理
做過數據項目的都知道，數據項目的建設是一個循序漸進、持續優化的過程，不可一蹴而就，運維數據的管理也是如此，和業務數據不同，運維數據較為難找，且離散。一般來說，運維數據的管理一般經歷四個過程，簡單歸結為：找數據、建模型、接數據、抓變現。
1、數據的尋找
在運維的數據體系構建過程中，找數據是個很頭痛的問題，這點和業務的數據體系有很大的區別，業務數據的管理大都由前置目標驅動，而運維數據的管理大都由后置目標驅動，這就造成找數據階段需要自上而下進行數據的梳理和調研。這個特性和運維的職能相關，在運維領域，安全、穩定、高效和低成本是運維的能力輸出框架，前兩個和數據低耦合，而后兩個和數據高耦合。
參考數據資源普查的方法，因運維輸出場景的后置性只能采取自上而下的方式，而自上而下的方式一般會用到IPR（信息資源規劃）。關于IPR的描述是這樣的，信息資源規劃（InformationResourcePlanning，簡稱IRP），是指對所在單位信息的采集、處理、傳輸和使用的全面規劃。其核心是運用先進的信息工程和數據管理理論及方法，通過總體數據規劃，奠定資源管理的基礎，促進實現集成化的應用開發，構建信息資源網。
這里通過運維語言進行拆解，簡單的說，根據運維數據的價值輸出模型可以這樣描述。我們也可以從“初態、終態和去處”三個維度來解讀，在運維數據的梳理范圍過程中，通常會擴大到各種系統配置信息、監控系統采集的系統數據、指標數據、固定閾值或動態閾值產生的復雜告警信息、以及各種系統定義的五花八門的海量日志數據等等。而隨著運維能力輸出的泛化，開發和運維的邊界上的模糊和融合，以及大數據技術的發展，運維數據和生產數據的邊界也不再那么清晰，如公司業務的用戶點擊數據既屬于運維數據的范疇也是業務數據的重要組成。
隨著業務的發展，運維數據在階段性過程中產生了爆發式的增長，可惜的是，運維數據的消費方式還是通過豎井式的方案，以不同的系統分別處理，主要還是展現給DevOps或其他使用人員來進行決策。
例如，監控系統以獲取監控數據為始，以輸出規則定義的告警信息給使用人員為終；日志系統已獲取和索引日志內容信息為始，以提供復雜的搜索和內容展現給使用人員為終。運維數據的價值挖掘受制于孤立的運維系統的處理能力和運維人員自身的“帶寬”。因此，我們通過IPR找數據的過程中，會形成一個誤區，總是站在運維的角度來找數據，最終找到的都是掐頭去尾的數據，下面我們通過簡單的一張圖來描述，如何找數據。
在這個階段通常是運維工具化一切的階段，而自上而下的梳理方式更能夠對現有數據資源有全面、系統的認識。特別是通過對數據職能域之間交叉信息的梳理，使我們更加清晰地了解到數據信息的來龍去脈，有助于我們把握各類信息的源頭，有效地消除“信息孤島”和數據冗余、控制數據的唯一性和準確性，確保獲取信息的有效性。在找數據的同時，也可以助推工具化的進一步查漏補缺和優化，下圖為常見的一些數據源。
2、數據的模型
數據模型的階段對于運維領域來說，體現在數據識別方面。在傳統的數據模型理論中，運維數據并沒有明確的操作數據層、明細數據層、匯總數據層和應用數據層的劃分，這是運維邊界所造成。在模型建設過程中，更多的是基于數據的特征來考量，主要有如下幾點：
運維數據的業務價值，如偏業務連續性的運維數據。
運維數據的共享，此部分的數據主要用來和業務系統之間進行共享的數據，如組織數據、技術組件數據、框架配置數據。
運維數據的實體獨立性，主要體現在資產管理和容量管理。
運維數據的唯一識別，這是運維數據形成網狀拓撲的核心能力，一般以CMDB為基準，采取多節點銜接延伸的方式，如基于業務系統的IP進行南北向的資產數據拓撲擴展，基于員工的工號進行東西向工程效率和人效的度量。
運維數據的長期有效性，運維數據模型的基本要素，主要用于數據基線、鏈路基線、容量成本基線。
在模型階段，由于運維數據獨特性，污染比較嚴重，質量也良莠不齊，所以治理和驗證的過程是一個難題。主要體現在運維數據的強即時性方面，某些基礎架構故障會引發一連串的系統級和業務級的故障，在業務較為復雜的情況下，這部分數據的污染性更為動態和復雜，因此需要模型具備一定的降噪和治理能力。
3、數據的接入和接出
運維數據的接入主要為工具數據的接入，較為常見的數據來源為資產管理數據和運維自動化工具所留存的數據，而工具留存的數據存在較多的不確定性，如數據保存方式不同、數據標簽不同、數據定義不同、數據管理方式不同，因此需要在接入層對數據進行加工和清洗。
數據接入是將數據從數據源系統匯集到數據平臺的過程。該過程需要對接入的數據進行清洗、轉換、映射、去重、合并、加載，通過一系列的數據加工和處理形成標準統一的主數據。常用的數據匯集方式包括：（1）ETL抽取，采用ETL工具的方式從數據源系統將數據采集到運維數據數據中臺。（2）文件傳輸，采用文件傳輸方式將文件中的數據導入到運維數據數據中臺。（3）消息推送，采用消息的方式從數據源系統將數據采集到運維數據數據中臺。（4）接口推送，采用接口方式從數據源系統將主數據采集到運維數據數據中臺。（5）內容爬蟲，一般用于WEB頁面的數據爬取，適用于無數據留存場景的匯集。
運維數據的接出，是將標準化的數據分發共享給下游系統使用的過程。在數據接出過程中使用的技術與數據匯集技術基本一致。在運維側實施數據接出過程中，需要根據不同場景選擇不同的集成方式。
在此有幾個大家都比較關心的問題需要探討，運維數據中臺是否需要將CMDB、監控平臺、流水線、持續交付、度量體系的數據集中到一起，這是運維中臺在建設過程中遇到的第一個問題。數據的接入過程其實是多源的運維數據導入過程，其中未必所有的數據都是有用的，監控數據和日志平臺是典型的代表。
在此期間，接入的運維數據往往存在大量的重復和冗余，以監控數據為例，同一個事件可能導致大量重復的指標、告警、日志等，筆者在實施過程中將更接近數據源的位置及早過濾冗余，這不僅會節省時間，而且也能夠節省用在冗余的垃圾數據上的存儲和計算成本。
因此，比較理想的方案是在臨近數據源的地方進行實時數據處理，盡早進行降噪和聚合，完成自動模式發現、異常檢測等算法，只把具備歷史分析價值的數據流傳到數據中臺進行歷史分析。總體來說，如果我們使用主數據和元數據的概念來便于理解，運維能力子域的工具和系統所留存的數據為主數據范疇，而數據中臺的數據為元數據范疇，二者的關系更多的通過單維到多維來識別。
回到數據集中的問題，筆者在實施過程中，CMDB、監控平臺、流水線、持續交付、度量體系的數據依舊維持原狀，接入的數據保持按需接入的同時，更多的體現在多個數據源的多維度的海量異構數據。
4、數據的變現
數據的變現是實現數據價值的唯一標準，和數據的商業化不同，運維數據的變現主要取決于數據的熱點運用，使用的熱度越高，越是黃金數據，也可以稱為核心數據資產。在運維領域，數據的變現主要有以下方面。
（1）整體協同、降本增效
提升組織級的能效和質量是DevOps的價值輸出唯一標準，因此通過數據驅動的方式來達到端到端的流水線交付、端到端的資源交付、端到端的安全輸出、端到端的價值交付。在這個期間，需要運維數據標準統一，來打通項目、需求、研發、測試、運維和資源的各個環節，大幅提升科技各子域的協作效率，減少因數據不一致導致數據傳遞交換的溝通成本。
（2）數據驅動、智能決策
在數據驅動階段，通過數據的反饋來優化價值交付鏈路過程中的問題和缺陷，通過對過程性數據的持續收集和分析發現交付過程中存在的瓶頸，通過對軟件產品和用戶的線上數據獲取反饋并且及時作出調整，通過結果性數據去評價團隊的成效。從而體現數據價值輸出能力和決策成效。
（3）數據即服務、資產
可以通過數據的不斷優化來提升數據共享和交換能力，另一方面，通過對數據進行標簽化和整合，結合各種不同的場景輸出提供給數據使用部門，從而實現整個企業級的全局數據打通。
三、總結
隨著運維的技術發展不斷加快，職能邊界也逐漸模糊，隨之而來的不光是數據的量級呈現幾何級的增長，業務連續性的容忍性也趨于變窄。因此運維數據所凸顯的價值輸出能力得到進一步的提高，對于數據的使用和管理給運維帶來了新的困難和挑戰，相應的也促使智能運維的出現和發展，提前預告下一篇，運維數據的質量管理。
