B站運維數倉建設和資料治理實踐

本文由ITPUB整理自嗶哩嗶哩SRE資深研發工程師袁帥在中國系統架構師大會(SACC2022)的演講《B站運維數倉建設和資料治理實踐》，內容將圍繞B站運維數倉的建設，分別從引擎側、平臺側和業務側展開介紹，分享在落地實踐中面臨的挑戰和問題。

隨著B站業務的高速發展，公司內部業務、基礎架構和運維對於通用運維性資料的多樣性、實時性和整合性需求越來越多，對資料質量的要求越來越高。而伴隨著大資料技術的不斷髮展和成熟，B站也對公司內部基礎資料的治理和管控進行了大量嘗試和實踐，最終建設了一體化運維數倉，來支撐滿足內部業務/基礎架構/工程效率/SRE團隊對於資料的強烈需求。

▲嗶哩嗶哩SRE資深研發工程師 袁帥

嘉賓介紹：2020年加入B站，先後從事過大資料運維平臺，TIDB資料庫管控平臺，運維作業流引擎及服務樹&CMDB等運維資料中臺研發工作。個人擅長基礎架構、Devops和SRE等領域架構設計和落地建設，目前專注於SRE體系下效能平臺建設，致力於透過工程化和產品化來提升SRE和運維工作的整體效能。

B站SRE體系是如何構建後設資料和使用

早在幾年前，B站內各個平臺基於對服務元資訊統一管控的強烈訴求，誕生了一個新專案，它就是我們內部所稱的服務樹。服務樹的主要功能是以服務的形式來提供周邊平臺的資源對接支撐。服務樹是一個以應用為視角來組織服務的樹形目錄，基於這個目錄來做資源的細分類和許可權隔離。

事實上，服務對應著應用。服務樹所做的事就是為應用分配全域性唯一Appid，周邊平臺業務資料組織，聚合均已Appid標識。服務樹具備例項管理功能，提供應用部署相關的元資訊(比如，IP、機房、雲廠商等)。

服務樹具備節點角色管理功能，負責一些基於RBAC鑑權的場景。基於內部統一使用者，託管各個系統角色使用者管理功能，實現鑑權。從圖上可以看得出來，服務樹第一層是應用層，第二層是例項層，第三層是人員和角色層。

周邊平臺像資產管理系統、Discovery、跳板機、容器平臺、CICD、日誌、Moni監控、Trace等，都是以服務樹為支撐來進行資料的整合。

如何構建應用的後設資料?主要採用三段式來進行構建，按照部門、專案、應用建立應用組織關係，提供全域性應用ID。

那麼，如何產生管理業務和資產的關聯關係?圖中有提到，在應用的視角出發，會有環境和掛載點，可以區分機器的環境，掛載server、vm、container、db等資產資訊，從而實現機器故障時的業務感知。

此外，後設資料提供RBAC模式業務角色，提供Admin、RD、QA、OP、Vistor預設的五種角色，也就是在部門、專案、應用這三層節點上，繫結使用者和角色的資訊，由於節點之間存在自上而下的繼承，所以許可權也是往下繼承的。

如何使用後設資料?Appid作為平臺資源管理核心。以CI平臺為例，如果以APP視角來構建，就需要APP與Git repo、映象進行關聯，透過編譯映象來構建它的編譯產物。

在CD平臺，無論是容器釋出，還是物理機發布，都是根據應用選擇製品，選擇例項。周邊平臺的資源都圍繞Appid建設，應用提供資源和人員資訊關聯。

一步步，服務樹淪為一個毫無邊界的資料中心

事實上，服務樹是圍繞人事物產生的後設資料中心，伴隨著長期資料注入，卻沒有一個簡單治理的過程，服務樹就一步步淪為一個毫無邊界的資料中心。服務樹具備的四大核心問題：

資料治理不足，靈活性不足。資料直接關聯關係缺失，圍繞應用做的資產關係缺乏統一的規範註冊上報，上報的邏輯不能很好的支援配置項的自定義和擴充套件，導致接入新資源時緩慢，不具備持續治理的能力。

許可權管控不足。RBAC場景無法滿足細粒度、精細化的許可權管控。直接或間接導致周邊平臺亂用服務樹角色，導致角色人員混亂，無法治理。

自動化能力缺失。傳統的資源，自動化能力嚴重不足，很多物理機、雲主機銷燬後無法感知，導致資料準確性降低。對於容器類資訊，同樣面臨該問題。

消費場景考慮欠缺。圍繞應用建設的運維數倉，本身從設計上沒有考慮應用變動所帶來的消費場景，周邊平臺對接完，發現應用改動後，缺乏感知。

對於API的暴露來說，有個很明顯的問題，在前期缺乏設計的情況下，OpenAPI會出現混亂。主要體現在四方面：缺乏規範和制度，快速迭代，快速滿足需求;平臺呼叫方缺乏治理和維護;介面替換程式碼不處理，介面文件長期不維護;消費場景太多，平臺定製介面太多，很多功能可以複用介面。

資料更新依賴沒有合理的消費場景，是透過全量查詢來閉環所有操作。舉例來講，

服務CMDB和資產CMDB之間是割裂的，CMDB透過各領域提供的全量查詢介面來感知資料變化，不停定時做全量同步，資料準確性、實時性得不到保障。

如果每次都是全量查詢，在資料庫層面是一個比較大的效能損耗。

此外，非標的使用方式太多，總共有六大塊應用的非標使用：應用作為其他平臺的資源概念出現，實現許可權管控;應用存在多個唯一ID;應用組概念強行套用;沒有使用應用，而使用部門和專案，導致部門，專案變動，部門組織調整出錯;應用下的環境和掛載點使用非標;應用作為叢集，元件出現。

無法為應用進行畫像。目前核心的問題在於應用缺乏應用資源註冊，應用上下游依賴關係沒有梳理，導致在水平層面或垂直層面缺乏圍繞應用構建拓撲的能力。

針對上述痛點，SRE團隊做過一些努力，但治理資料卻無從下手。因為最小許可權安全控制原則，服務樹許可權申請審批沒有限制導致人員、許可權資訊混亂，導致應用無法遷移，應用無法交接，應用下所使用的資源，無法做關聯，覆蓋不全。

B站運維數倉建設的整體思路

B站建設運維數倉的目標和準則是什麼?圍繞應用來建設CMDB，大概有以下幾點：以應用為中心，提供統一的後設資料管理中心;CMDB建設的核心訴求就是做好應用的全生命週期管理;資源為輔，構建應用與資源的關聯和拓撲;CMDB核心消費場景就是持續的交付，CMDB是一個持續迭代的過程;

按照場景和能力拆分基礎資源CMDB和應用維度的CMDB，本質上應用也是資源;資源的註冊和消費需要閉環;資料質量的保障：“自動發現，標準流程，人工維護”;邊界，邊界，邊界，有哪些是我們堅決不會做的事情。

後設資料中心作為SRE體系中核心的服務存在，後設資料中心的資料來自CMDB，支援基礎架構服務平臺運轉;後設資料中心為端到端的服務執行時的過程提供資料支撐。

如圖所示，後設資料中心在基礎架構SRE體系最上層。下層會有配置管理資料庫CMDB，基礎配置資訊(人員組織、角色許可權、流程管控)，Adapter(資料管理工具、Plugin、OpenAPI)。底層會有資產採購、LDAP/AD、第三方系統、數倉平臺、DB、Cache等。

往上看，後設資料中心是為基礎架構的所有平臺進行服務，包括：事件運營平臺、作業平臺、流程平臺、微服務平臺、可觀測平臺、CICD平臺、中介軟體平臺、容量平臺、多活平臺等。最終，這些平臺會形成統一的門戶入口，給到研發部門使用。

服務在執行期間，如何與後設資料中心產生關係?後設資料中心為服務全生命週期內提供資料基礎，後設資料中心也是作為服務的支撐平臺存在的，貫穿服務始終。服務資源支撐平臺有云管理平臺、Iaas資源，以及Paas資源，這些統一的資產CMDB資料匯聚到每個資料中心，向上提供服務。

後設資料中心如何建立資料模型?CI配置模型梳理過程有五個核心步驟：定義資料型別、定義資料核心屬性、構建資料模型直接關係、消費場景確認、確立資料規範。總結來看，以資料全生命週期為出發點，確定屬性，理清關係，確定消費場景，自動化流程來保障資料準確性，讓我們建立一個規範的資料模型。

舉例來看，應用資料模型的建立。建立思路基本按照流程一步步細分，自定義一個資料模型，需要產品、研發一起界定資料規範，需要各方遵守。

應用屬性包括，應用名稱/別名、應用等級、應用唯一ID(Appid)、組織/業務、extra。資料模型關係包括，所屬組織/業務、人員/角色、所使用IT資源、依賴的微服務元件、依賴的中介軟體、extra。

消費場景確認圍繞幾點，分別是應用建立(平臺建立申請)、應用更新(更新等級、名稱、別名、資料關係變更)、應用刪除(廢棄應用)。資料規範包括，明確應用的建立入口，明確應用元資訊變更後，周邊平臺的消費感知。

上圖是後設資料中心產品架構，從上到下分別是Apiserver層、Mng(管控平臺層)、資源採集層、資源物件層。具體而言，所有人都是透過Apiserver來訪問後設資料中心。

Mng(管控平臺層)包括模型管理、拓撲關係管理、事件處理、許可權管理。資源採集層包括Agent採集、SDK上報、定時任務採集、資料校驗採集規則配置下發。資源物件有應用、公/私有云、網路、伺服器、機房、交換機等。

上圖是後設資料中心技術架構，分為接入層、服務層、儲存層、三方服務、運營分析五大塊。接入層可以用http和grpc來呼叫。服務層分為功能層和資源層。儲存層包括Mysql、Redis、內部KV儲存。三方服務包括統一認證、流程Flow。透過ES、Clickhouse、neo4j來做運營分析。

後設資料中心資料採集的核心就是Data-Collector資料採集模組是如何設計?其中包括資料來源(Origin)、DataCollection叢集、資料儲存三部分。其中，資料來源(Origin)是指採集的資料節點採集器會將資料傳送到指定的內部訊息佇列裡，DataCollection訂閱指定Topics接收採集資料。

DataCollection叢集是指分散式，連線Topics消費資料。資料儲存是指資料經DataCollection處理，最終落在Mysql、Redis和內部KV儲存上。

如何處理原始資料關聯關係?把CI和CI之間的關係種類列出來，前提需要產品、業務方進行充分溝通。當我們列出關聯關係之後，需要進行確認。

以應用為例，應用執行在物理主機上，應用的DB安裝在伺服器上，伺服器連結網路交換機，機櫃支撐物理裝置。按照梳理的關係分析，整理出節點型別和邊型別，最後定義出以應用視角的圖模型。

上圖是B站後設資料中心落地實施流程，擁有現狀評估、專案啟動、資料例項化、資料校驗、資料場景消費五個核心點。在專案啟動過程，B站會開設專案啟動會，會上介紹整體的建設思路、核心概念、核心指標等，確立CI模型和關係整理。在資料校驗過程，需要校驗資料匯入情況，確認資料準確性，為生產環境做準備。

關注資料質量

在落地之後，我們要持續關注資料質量。制度規範分為規範要求、流程要求、組織要求、平臺要求四部分。

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

流程要求是能夠真是反映資源狀況;能夠完整的包含所有的資源資訊以及資源間關係;全域性唯一的權威資料來源;資料能夠被使用者及系統方便，及時和高效的獲取。

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

平臺要求要做到以下幾點：逐步實現配置自動發現，自動維護;實時跟蹤資源的狀態及配置變化;模型靈活，能夠根據業務需求實時擴充套件和調整;配置視覺化，能夠支援資源問題的分析和快速定位。

打造資料全生命週期閉環，聚焦資料閉環和資料可靠性建設。依託運維流程引擎閉環，針對資產類資料建設重構。期間存在短期沒有閉環的流程，B站對此類上報的資料沒有匹配上後，將此類資料列入異常資料中，生成資料包表，並且保留所有變更記錄。

資料治理是一個持續的運營和改進的過程。部門導向，資訊分散、孤立、管理無規範。不論是否有CMDB系統，實際都存在CMDB需求，以部門為單元維護配置資訊。

資料導向，共享型CMDB，參考業界標準資料模型。構建共享型CMDB，將各部門都關心的資料及相互關係統一納入CMDB管理，並建立配置管理流程制度。由於消費場景不明確，造成消費價值與生產成本的失衡。

場景導向，面向特定使用場景，如資產管理，流程關聯。區域性資料標準化程度，準確性較高。由於使用場景單一，總體消費價值不高，生產成本相對較高。

服務導向，整合型CMDB，整合更多的管理物件，對外提供資料服務。使用場景全面，提供資料供給服務，支撐日常操作管控，如自動化，監控，作業流管理，運維分析等。引入多樣化的資料生產手段，逐步平衡消費價值與生產成本。

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

總結

無論我們身處CMDB建設的哪個環節，最終都是要面向價值保障。我們可以按照不同階段進行整合，快速迭代，完成CMDB在業務方面的一些價值。