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