一、認識資料資產
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進行合規檢查；
- 推動實現配置消費閉環，透過消費回饋，自動維護資料可靠性。
以上是不會建造數據資產體系的SRE，不是一名好運維的詳細內容。更多資訊請關注PHP中文網其他相關文章！
