不會建造數據資產體系的SRE，不是一名好運維

一、認識資料資產

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中文網其他相關文章！