一、認識數據資產
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進行合規檢查；
- 推動實現配置消費閉環，通過消費反饋，自動維護數據可靠性。
