一、認識數據資產

1. 數據資產——企業IT價值

圖片

如圖所示，未進行數據資產化建設時，數據可能呈現離散狀態，數據生產和消費不統一，容易出現數據孤島或零利益的情況。

建設數據資產化后，我們整合不同渠道數據，構造統一的數據源，或數據采集、存儲、分析的流程鏈路，進而統一對應的數據結構、數據關系和消費出口。

運營數據經過采集、整編后，可服務于自身決策和業務流程。

2. 數據資產——以運維場景為例

圖片

上圖以場景為例，介紹了數據資產的分類。理解數據資產，就要理解數據資產所對應的三個要素，即數據類型、數據形式和數據載體。

• 數據類型：運維特征的信息描述

業務指標層面，SRE關注交易耗時、交易訂單量等信息；操作軟件層面，SRE關注用戶IP、接口調用情況等信息；基礎設施層面，則關注對應的網絡丟包率、內存占用或CPU使用率等信息；再深入，SRE會更加關注變更事件、發布試點或緊急變更的數量等數據。

• 數據形式：數據儲存于數據載體的形式

我們根據日志類、關系類及監控類等數據的不同表現形式，選擇相應存儲方式，比如關系型數據庫、持續性數據庫、消息隊列或者日志文件等。

• 數據載體：為運維數據提供存儲的方式

3. 數據資產——提升SRE價值

圖片

首先，使用獲得的運維數據，建設資產化平臺（例如后文將要提到的CMDB）。通過這些平臺，按照消費場景，對海量的運維數據進行拆分治理，進而形成資產化。

其次，依托數字資產平臺，可快速構建并迭代SRE穩定性相關平臺（例如SLO、容量管理等平臺）。平臺成功建立后，我們持續挖掘數據價值，以提升SRE關注的穩定性。

二、數據治理-方法論

1. 運維數據標準面臨的問題

圖片

運維數據標準化面臨的問題，和大數據場景下數據質量的問題類似，主要包括數據孤島、數據質量不高、數據不可知、數據服務不夠、獲取數據的開發耗時長等。

這些問題導致，數據消費場景難以快速迭代，無法滿足業務需求。在人力資源、服務器資源、中間件資源等投入不足的情況下，對數據標準化的建設會產生災難性的影響。

運維數據天生是不標準的，比如，日志和日志監控的數據存儲方式不同。而我們要在資源有限的情況下，進行最大化闡述，完成標準化。

針對近期業內比較火的概念，比如DataOps、AIOps等模型或場景，我們還缺少成熟、全面的數據建模方法論。

2. 建立運維數據治理模型

將運維數據提升為數據資產，需圍繞治理方法、治理過程和技術平臺三部分展開。

圖片

1）治理方法

• 主數據管理：將SRE關注的數據進行定義和拆分。比如，主機和CLP等數據可作為主數據，我們對其進行生命周期管理。
• 廣義元數據管理：這些數據在閉環的上報流程中，進入到CMDB，就是廣義元數據管理。以CMDB的模式為代表，向上層提供相應的數據支撐。
• 關鍵治理鏈路：基于數據標準、治理質量和安全基線三個維度，梳理整個治理鏈路，即數據標準、質量目標、整個變更的基線要求。

2）治理過程

治理過程包括策略、建設與運營。整體建設方面，需要建設平臺和工具，輔助自身運營。

3）技術平臺

建立技術平臺的主要目的是，通過工具支撐存量和增量數據。

3. 聚焦數據治理關鍵要素

數據治理的關鍵要素主要圍繞四方面：組織保障、制度建設、項目落地和平臺支撐。

• 組織保障：為解決人力資源問題，我們明確成員角色和職責分工。由產品、運營和研發三種角色，組成數據治理專項團隊。
• 制度建設：需要建設標準化流程，并保證其有序落實，比如資源接入、資源開發、資源數據模型等規范。
• 項目落地：開始整體的專項治理，數據治理是長效的過程，而非簡單的運動式作戰。如果數據質量嚴重不達標，我們會成立專項小組，采取運動式的作戰方式，緊急修復數據質量的問題。但建立長效治理手段需根據數據產品，輸出對應的治理方法論，并將其落實為產品化的平臺手段，以此驅動數據責任方進行數據治理。
• 平臺支撐：平臺建設主要圍繞精細度量、執行治理效率等維度進行。

三、CMDB平臺建設

1. CMDB配置管理庫

CMDB配置管理處，主要圍繞四方面進行建設：基礎備案的技術臺賬、詳細自然屬性、自然關聯關系、資源消費圖譜。我們需要分層建立對應業務的模型，再通過自動化感知或標準化流程，實時推送配置動態。

對應配置也需要有對應的可視化界面，激發協作力量，最終，這些數據通過APP或相應離線場景，促進數據的消費場景。

2. CMDB在ITIL時代的定位——元數據中心

個人理解，CMDB是元數據中心。如上圖所示，我們配置管理的數據庫CMDB，會對組織、人員、決策、權限、流程等相關數據進行清洗或組裝操作。

下層對接的平臺很多，比如監控平臺、郵件、短信、運維的數據庫等。這些數據組裝完畢后，會交由上層（類似服務管理層的平臺）進行數據輸出，完成資產管理、配置管理等一系列服務，并進行平臺建設。

3. CMBD在新時代的定位——以應用為中心

、

以應用為中心，可以實現組織-項目-人員的關聯關系，并與應用綁定。

應用運行過程中，使用對應資源（服務器資源、配置中心、可觀測性指標等），再按照公司的組織架構形成從屬關系，最終把組織架構視角引用到微服務視角，形成資源及其資源的關系——拓撲，其中包括應用拓撲、物理拓撲。

4. 以應用為中心的CMDB優勢

圖片

5. 應用在運行期間與元數據中心的關系

圖片

上圖所示為CMDB，它會將基礎測試設施的元數據、Paas相關數據及運行數據，提供給上層（CI平臺、CD平臺、服務運行平臺和服務運營平臺）使用，圖中所示的下層平臺就形成服務資源支撐平臺。

這樣建設的好處是，為應用的全生命周期提供基本的數據支撐，包括應用創建、應用運行時態（構建、發布、擴容、計費）、回收應用下線后資源。

6. CMDB建設的四大階段

圖片

上圖是建設CMDB的四大階段，我們目前處于從服務導向到價值導向的第四階段。

部門導向：

• 不論有無CMDB系統，實際都存在CMDB需求，以部門為單元維護配置信息；
• 信息是孤立的、不及時的，無法保證完整性和正確性。

數據導向：

• 各部門都關心的數據及相互關系統一納入CMDB管理，并建立配置管理流程制度；
• 由于消費場景不明確，造成消費價值與生產成本的失衡。
• B站數據生產成本建設并非很高，但是數據消費產品建設特別多，或是業務側經常定制場景需求，CMDB需要定制介入開發，完成業務側訴求。由此暴露出問題，CMDB有300多個OKACI，不便于維護。

場景導向：

• 局部數據標準化程度，準確性較高；
• 由于使用場景單一，總體消費價值不高，生產成本相對較高。

服務導向：

• 數據供給服務，支撐日常操作管控，如自動化、監控、作業流管理、運維分析等；
• 引入多樣化的數據生產/消費手段，逐步平衡消費價值與生產成本。

價值導向：

• CMDB全面支撐服務及業務發展，如服務容量管理、可用性管理，成為IT運維的基石；
• 主動推動組織IT管理水平的提升。

7. CMDB模型如何構建

圖片

• 定義數據類型：包括主機、交換機、應用、應用配置文件，配置人員接到需求后會對此進行調研。
• 定義數據核心屬性：以主機為例，需要上報或采集IP、序列號、機房、云廠商等資源核心屬性。
• 構建數據模型直接關系：梳理資源與資源之間的對應關系，如包含關系、依賴關系、運行關系等，以便后續制作資源拓撲。例如，應用使用一種數據類型，主機使用另一種數據類型，那么應用運行時會依賴主機，主機反過來可以組成應用。
• 消費場景確認：確認消費場景，就是確認數據用于哪些階段。如果用于集群部署，可能需要到應用維度進行相關部署，或對應的運維作業。
• 確立數據規范：生命周期（從創建、生產到部署）是怎樣的過程？數據狀態變化后，平臺如何感知？

綜上所述，我們要以數據全生命周期為出發點，確定屬性、理清關系、明確消費場景，借助自動化流程來保障數據的實時性與準確性。

1）模型關系定義

圖片

2）CI關系DEMO舉例

圖片

3）CMDB落地實施框架

• 現狀評估：當前是否有CMDB平臺？這個平臺建設程度如何？這部分數據質量如何？組織架構和技術架構如何？未來上線的過程中，需要用到的資源狀態如何？
• 項目啟動：啟動時，需要定義接入資源的 CI模型和關系、后期消費場景、數據來源、CI干系方。
• 數據實例化：進行數據實例化檢測時，會搭建測試環境，導入CI模型或實例化數據。
• 數據校驗：在UG環境內，查看數據上報和實際產出的對比情況，確認數據質量能否達標。數據質量達標后，需要建設生產環境，以檢測數據在生產環境的狀態。
• 數據場景消費：數據落到生產環境后，需查看數據消費的場景，我們要與運營平臺或SRE平臺進行對接。

4）標準化先行

標準化先行是，落地之前的所有事項，都圍繞標準化進行建設。其中包括一些強要求，比如規劃要求、流程要求、組織要求和平臺要求。

規范要求：

• 明確定義CMDB平臺的作用，以及其他業務系統間的關系；
• 明確定義資源的管理過程、責任人和責任平臺；
• 明確定義資源的基線標準以及偏差管理辦法；
• 從服務業務場景的視角，規劃和建設配置管理能力。

流程要求：

• 能夠真實反應資源狀況；
• 能夠完整包含所有資源信息以及資源間關系；
• 全局唯一的權威數據源；
• 數據能夠被用戶及系統方便、及時、高效地獲取。

組織要求：

• 成立統一的配置管理能力建設主體；
• 各個業務團隊明確配置消費和完善的責任；
• 形成配置管理討論、優化和需求收集的機制。

平臺要求：

• 逐步實現配置自動發現、自動維護；
• 實時跟蹤資源的狀態及配置變化；
• 模型靈活，能夠根據業務需求實時擴展和調整；
• 配置可視化，能夠支持資源問題的分析和快速定位。

5）打造數據全生命周期閉環

首先，確定應用屬性。應用的屬性可能包括，應用的中英文名稱、應用等級、唯一ID、歸屬業務和業務域等，屬性內容主要取決于個人定義。定義應用后，應用可能與其他CI產生關系，需進一步梳理。

其次，明確應用的屬性負責人。應用具有對應的負責人、研發和SRE等，針對應用構建、發布、變更，以及圍繞用戶進行的其他動作，我們都有對應流程，以保障應用的配置和變更審核。

最后，進行定時的采集任務，以保證應用最終的數據準確性。

6）推動配置的自動發現和更新

上圖提到的“資源”還是傳統意義上的資源，比如服務器資源。通過一定方式采集這些資源，最終上報到資源管理平臺。

• 建設完善的配置采集能力，杜絕人工維護的場景；
• 自動發現資源和應用的配置信息；
• 對接流程、管理平臺和設備，實時獲取和更新配置狀態；
• 建立資源配置和使用規范，通過CMDB進行合規檢查；
• 推動實現配置消費閉環，通過消費反饋，自動維護數據可靠性。