CMDB 集成

在 DevOps 的實踐過程中，流水線的構建具有 4 種方式：以項目批次為基準的價值交付流水線、以資源數據為基準的交付流水線、以支撐數據為基準的交付流水線和以交付數據為基準的交付流水線，其中以資源數據為基準的交付流水線方式主要依托 CMDB 。在 DevOps 的集成體系中， CMDB 是基礎支撐數據的來源，也是基礎元數據平臺。

CMDB 概述

CMDB （ Configuration Management Database ，配置管理數據庫）在傳統企業中稱為資產管理系統，在云計算或互聯網企業中稱為云配置中心。CMDB 可以對企業內外部的 IT 資源進行識別、控制、維護和存儲，從而實現對 IT 資源的高效控制。另外， CMDB 可以管理企業不斷變化的 IT 資源和 IT 服務，還可以為問題管理、事件管理、交付管理和業務連續性管理提供完善且準確的配置信息。

從本質上來說， CMDB 通過收集 IT 資源的各種信息，并根據收集的信息對項目或產品的價值交付進行數據輸出和賦能。CMDB 在能力輸出方面經過多次演進，即從基本的配置管理，到場景消費、應用驅動，再到為價值交付賦能。在實踐過程中，落地后的實際用途和預期存在較大出入，糾其原因，不外乎 CMDB 因運維職能的泛化而導致數據輸出能力的下降。CMDB 的建設通常需要打通 IT 資源使用鏈路上的各個能力子域，因此需要組織協調 和流程推進，而運維職能范圍的不斷拓展，導致數據的標簽和口徑在一定程度上失真，如數據不準確、數據收集不及時、對接困難和數據輸出薄弱等情況，導致最終效果達不到預期。

CMDB 的作用

CMDB 的使用場景較多，如配置管理在 IT 組織內部的應用，因此，我們需要梳理其主要使用場景，從而提升 IT 資源使用的透明度和準確度。同時，我們需要通過配置數據進行價值輸出，通過提供價值交付流水線進行反向集成，如自動化發布、數據查詢、資產審計、容量管理和全鏈路監控。常見的場景主要有兩類：流程場景和數據場景。流程場景主要包括運維自動化的集成（需要 CMDB 提供系統的情況和系統資源的情況）、監控系統的集成（需要 CMDB 提供系統之間的關系和系統的 IP 地址等數據）和運維流程的集成（需要 CMDB 提供配置對象和數據的相關信息）。數據場景一般是指通過 CMDB 提供的數據進行高階使用，也就是將 CMDB 的數據通過 API 方式對其他第三方系統進行輸出，形成基礎模塊，提供統一服務入口，如常見的資源管理過程可視化，以及對 IT 資源進行查詢和分類統計。

在傳統行業中，運維管理流程是 IT 組織內部條目最多、范圍最廣的流程場景， CMDB 需要向運維管理提供數據的支撐服務，以及 IT 資源信息的輸入、變更和存儲。運維管理分為事件管理、問題管理、變更管理、配置管理和資產管理， CMDB 在它們中起到的作用如表 3-1 所示。

表 3-1

在能力子域方面， CMDB 的數據覆蓋率取決于受眾人群的類型， CMDB 的數據主要分為產品目錄，產品團隊，資源和容量，產品安全，服務質量，以及架構成熟度多個維度。

產品目錄中一般包括系統標識、系統名稱、運行狀態、系統交互關系、版本信息、產品干系人、產品屬主、產品功能、部署位置、系統用戶范圍和系統語言等配置信息。

產品團隊中一般包括團隊組織、人員工號和第三方支持團隊信息等配置信息。

資源和容量中一般包括系統實例清單、中間件實例清單、數據庫實例清單、基礎軟件類型、基礎軟件版本、數據中心信息、機房信息、物理機信息、虛擬機信息、容器信息、網絡信息、線路信息和產品的容量規劃等配置信息。

產品安全中一般包括產品保護級別信息、訪問控制信息、出入口信息、對外服務信息和安全級別信息等配置信息。

服務質量中一般包括業務容量信息、產品分級信息、服務級別信息、業務關鍵場景信息、業務關鍵路徑信息、系統可靠性方面的信息、業務可靠性方面的信息、業務黃金指標信息和服務監控信息等配置信息。

架構成熟度中一般包括容量瓶頸信息，可用性信息，安全風險信息，監控盲點信息，系統和數據庫集群信息，應用狀態信息，多活和災備信息，容器架構信息，數據庫架構信息，微服務架構信息，系統交互信息，關鍵服務耦合信息，業務限流信息，系統熔斷信息，發布策略信息，應用配置信息，業務驗證信息，網絡接入情況，以及多云部署信息等配置信息。

CMDB 的價值

在 CMDB 的價值體系中，配置價值已不再適合被過度放大。尤其在 DevOps 價值交付過程中， CMDB 更多承擔底座的作用，價值的體現需要 DevOps 和業務進行放大。因此， CMDB 的價值需要回歸本源，逐漸錨定到 DevOps 數據的范圍。CMDB 的內在價值主要體現為數據的質量和范圍，外在價值主要體現為場景驅動能力。

1 ）數據的質量

在 CMDB 的落地和推廣過程中，數據質量需要經過前期調研、系統集成和數據治理等不同的階段來保證， IT 組織往往不擅長這些工作，因此，需要從技術層面和管理層面進行數據質量的約束。在技術層面，需要對數據進行分解，通過數據的使用流程和使用場景進行反推和校驗；在管理層面，需要對數據的干系節點進行職責明確，通過技術手段進行數據的校正。

CMDB 獲取數據一般通過自動發現和人工錄入兩種方式。為了保證獲取數據的準確性，需要盡可能提高自動發現的能力，降低配置管理的難度。常見的數據源有云管理平臺、網絡管理平臺和負載均衡系統。對于人工錄入的數據，需要對數據進行大范圍流動，提高存量數據和增量數據的精度和透明度。通過數據的流動，實現場景消費的正向反饋，確保數據質量穩步提升。與此同時，在管理層面，以流程機制的方式定義場景約束，提升集中集成的能力。保證數據質量的流程如圖 3-8 所示。

2 ）數據的范圍

數據的范圍主要依靠場景嵌入和流程約束來擴展。在 CMDB 的運行階段，場景的結合和流程的約束是重要環節。在通常情況下，場景的結合增加數據范圍的廣度，流程的約束增加數據范圍的精度。想要放大數據的范圍，就需要將 CMDB 嵌入大范圍的用戶場景中，降低數據的使用門檻，因此， CMDB 需要具備實時、準確、方便、結構化處理數據的能力，讓使用者察覺不到 CMDB 的存在，降低 CMDB 的影響，通過流量回流的方式進行數據范圍的擴展。流程的約束通過資源申請和資產審計方式來實現，如常見的對計算資源、存儲資源和網絡資源的申請，需要通過流程方式對 CMDB 進行強依賴管理，并加大流程管控和數據審計的范圍，促使數據的范圍放大。

圖 3-8

3 ）數據的場景驅動

CMDB 的外在價值體現為有價值的場景驅動，如安全驅動，業務域保障驅動，自動化驅動， DevOps 集成驅動，以及容量管理和審計驅動。從對場景的選擇來看， CMDB 的場景具備數據輸出的典型特征。打通業務端和 IT 端的數據融合的通道，這也是以資源數據為基準構建 DevOps 流水線方式的能力。在有價值的場景驅動中，可以實現 IT 組織內部的流程貫通和場景適配，也可以實現業務組織和 IT 組織在數據使用方面的整合。

CMDB 和 DevOps 的集成方法

CMDB 和 DevOps 的集成方法在業內已形成共識，這些集成方法包括從架構方面以應用為中心、從模型方面以服務為中心和從能力輸出方面以業務為中心。

1 ）從架構方面以應用為中心

從應用的角度，規劃和管理各種運維服務場景；通過全局視角，分析運維對象之間的關系。根據運維服務場景，建立架構層級，分為應用服務層、應用邏輯層和基礎架構層。對于分層信息，進行拓撲關系的梳理和映射。最終，以 DevOps 為載體，快速實現應用資源內外部的拓撲繪制，提升業務保障域的工作效能。運維服務場景架構層級如圖 3-9 所示。

2 ）從模型方面以服務為中心

服務可以分為業務導向和技術導向，其中業務導向的服務以用戶角色為視角，技術導向的服務以生產角色為視角，通過業務系統的功能，打通端到端的服務。在模型方面，同樣以功能和服務為中心構建模型，通過功能的升級和服務的提升，進行 CMDB 和 DevOps 的集成場景的擴展。

同時，通過用戶角色視角和生產角色視角，對組織中的業務服務進行橫向打通。在用戶角色視角方面，以業務為視角，通過產品、模塊和功能的下鉆，提供給用戶使用；在生產角色視角方面，以業務為視角，通過系統、應用和服務的下鉆，提供產品交付，最終實現以服務為中心的模型構建。以服務為中心的模型如圖 3-10 所示。

圖 3-9

圖 3-10

3 ）從能力輸出方面以業務為中心

以業務為中心的集成通常采取面向終態的方式，這種集成方式強調 CMDB 的靈活性和可擴展能力，需要在 CMDB 數據模型的管理方面具備動態化和可配置化特征，能夠隨著業務的變化快速且靈活地進行 CMDB 數據模型的調整、擴展和修正，滿足交付流水線上各能力子域對配置數據使用深度和廣度的需求。另外， CMDB 需要提高數據的易用性，在使用場景中，實現低成本和高效率。CMDB 一般具備以下能力。

（ 1 ）模型動態擴展能力。配置項動態化，對象屬性上下游繼承。

（ 2 ）數據多維度關聯能力。通過數據屬性的上下游關聯，實現從單維數據到多維數據的轉化，形成多場景的數據鏈路。

（ 3 ） API 能力。通過 API ，實現全量數據接口輸出，快速匹配業務場景和提升第三方集成能力。

（ 4 ）自定義數據基線能力。以場景為邊界，形成自定義數據基線，通過數據的初態、中間態和終態的特征，展現數據的血緣關系和數據的流向關系。

CMDB 和 DevOps 的集成場景

CMDB 和 DevOps 的集成場景主要包括業務場景、架構場景、部署場景、數據輸出場景和傳統的基礎架構場景。在業務場景方面，基于業務訪問流的方式，對服務進行可視化呈現；在架構場景方面，基于架構視圖，對應用的顆粒度進行整合，形成完整的業務和業務的全景視圖；在部署場景方面，包含應用對應的節點和組件，形成應用的部署視圖；在數據輸出場景方面，包括 CMDB 提供的數據所有的對外輸出場景，該場景主要與其他集成場景進行單向和雙向的數據交互；傳統的基礎架構場景是指對底層的基礎設施進行視圖輸出，并提供采集、查詢、存儲和展示功能。

在應用方面， CMDB 輔助業務場景，通過 DevOps 驅動業務流程。在價值交付流水線中， CMDB 為各業務流程提供準確的配置數據。業務系統在架構設計、容量管理、持續交付和業務域保障過程中，通過數據賦能，進行業務流程的落地。同時， CMDB 提供的數據的高階使用方式主要是多場景的數據關聯和通過端到端的視圖輔助 DevOps 在監控領域進行根因分析、故障定位和快速“自愈”。在 DevOps 的度量和反饋環節，對 CMDB 提供的數據進行服務化運營，實現業務的運營分析和成本復盤，以及資源的容量規劃和管理。

隨著對 DevOps 的實踐不斷深入，以及數據不斷豐富， CMDB 的集成的選擇逐漸多樣化。從發展趨勢來看，面向應用和面向業務是實現 CMDB 和 DevOps 集成的核心驅動力。

運維服務流程的集成

經過運維職責的多次演進，運維服務能力模型逐漸實現價值的錨定。該模型通過 SRE 和 DevOps 的重新定義，形成安全、穩定、高效和低成本四大能力要素。

運維的主要職能是通過運維服務流程進行輸出，經過業務反饋后形成有效的運維體系，在從傳統運維發展到互聯網運維的過程中，進行技術迭代和體系建設，最終實現高 SLA （ Service Level Agreement ，服務等級協議）和低成本的業務目標。在 DevOps 價值交付流水線中，運維服務流程主要體現為基礎支撐，并通過運維服務體系進行系統的可靠輸出和業務的連續輸出，這是 DevOps 整體服務框架輸出的“底座”。運維服務能力模型如圖 3-11 所示。

圖 3-11

在運維服務流程方面，需要解決下列 3 個問題。

（ 1 ）為什么需要運維服務流程？

（ 2 ）運維服務流程應該如何設計、運行和處理問題？

（ 3 ）運維服務流程最終能夠帶來什么？

在傳統運維階段，運維能力子域和其他能力子域并無技術的融合，主要是通過資源輸出進行溝通和基本的運維體系的構建，因此，運維服務能力模型呈現無狀態和不規范特點，不能為業務保障帶來質的提升。在這個階段，往往通過制度進行約束和全局規范，價值輸出過度依靠人力和制度，只為結果負責，并不考慮效率。在協作方面，由于技術棧的差異和業務訴求的傳遞衰減，制度不能完全約束運維活動的整個過程，因此，需要運維服務流程進行端到端的貫通。

隨著 DevOps 理念的推廣，運維服務流程開始提升運維組織內部的效率，同時更加關注能力子域之間的協作問題，這是自動化的開端。在這個階段，運維服務流程豐富了運維體系的內容，通過流程驅動，提高了工作效率，同時帶來了制度的重構，以技術和規范逐步對制度進行補充。在這個演進過程中，運維側越來越注重技術棧的延展和融合，通過技術來解決業務問題，人員逐步精簡，崗位職能逐步放大，技術落地成平臺，制度落地成服務流程，相對應的，運維服務流程逐漸深入業務范疇。

在安全保障和穩定方面，運維服務流程涵蓋了規范、資源和服務 3 個大類。其中規范是對流程、資源、服務、業務連續性和系統可靠性的統一標準化；服務體現在業務運維和技術運營兩個場景，具體以監控告警、日志分析、服務預案、配置管理、持續集成和持續交付為主；資源包括計算、存儲、網絡、線路、容器和代碼托管方面，如圖 3-12 所示。

圖 3-12

創建運維服務流程的原因

在創建運維服務流程之前，我們需要了解創建運維服務流程的原因，即需要通過它解決什么問題，如表 3-2 所示。

表 3-2

在業務訴求方面，大多數企業的運維組織需要對業務連續性指標負責，協調各職能組織共同保證業務的連續性，并通過組織能力和技術手段保證系統的可靠性和系統的安全性。

在運維環境方面，由于公司的治理和業務的發展存在不確定性，因此基礎架構、技術棧，以及組織之間的溝通和協調存在一定的問題，最終影響企業可持續、穩定和健康發展，具體表現為產品線隨企業的發展呈線性發展，技術架構的種類繁多。

運維組織最需要解決的問題出現在人員方面。人是運維服務流程中最需要約束的點。日常的運維活動最重要的載體不是技術棧，而是人。由于運維人員的能力參差不齊，運維習慣存在差異，因此需要運維服務流程進行規范的約束和運維體系的固化，從而提升運維效率和降低運維風險，最終通過業務進行運維能力的輸出和放大。

創建運維服務流程時的目標

運維服務能力模型的 4 個能力要素并不等同于運維服務流程的目標，兩者存在包含與被包含的關系，同時在考核方面存在可量化和可持續的區別，如在安全性和穩定性較高時，需要可持續地進行保持，而非量化地進行比較。總體來說，創建運維服務流程的目的是在合規和敏捷，以及安全和穩定中尋求平衡，最終通過 DevOps 實現對價值交付中業務保障域質量的控制。

在創建運維服務流程時，有 4 個目標，分別是完整、易用、高效和安全。完整是指流程的完整性，即需要覆蓋運維能力輸出過程中的絕大數流程。易用是指流程簡單、好用，如果操作流程比較復雜，那么，在運維能力輸出過程中，流程的使用者需要付出更高的學習成本，效果也可能達不到預期，影響最終的能力輸出。高效是指流程流轉過程中需要技術加持，及時給予流程使用者反饋。安全是運維服務能力模型的 4 個能力要素之一，因此，在流程方面，需要考慮安全因素。

表 3-3 中列出 DevOps 內嵌的常用的運維服務。

表 3-3

建立運維服務流程體系

運維服務流程體系本質上是運維文化和運維職責的延展。從某種程度上來看，和 ITIL （ Information Technology Infrastructure Library ）的理念是相通的。運維服務流程和運維流程的區別是運維價值輸出方式和運維觀念的不同，前者貫穿價值交付鏈路，后者貫穿運維交付鏈路。

在建立運維服務流程體系時，我們需要考慮下面 4 個方面：調查服務需求，設計相匹配的服務級別；通過技術賦能，建設高效的運維服務團隊；創建運維服務目錄，全面受理運維服務請求；規范對事件和問題的管理，形成總體閉環。

在服務級別方面，需要協同價值交付鏈路中的各能力子域從用戶角度、業務角度、系統交付角度、服務角度和基礎架構角度分別對服務進行分級，并針對分級結果形成服務級別協議和提出服務承諾。

在建設運維服務團隊方面，管理者需要具備“小而美、少而精”的團隊建設思想，按照服務的級別和層次，選擇合適的技術工具，規劃遞進的技術迭代路線，配備專業的運維人員，建設層次分明和具備可持續特性的運維服務團隊。

在運維服務目錄方面，打破 IT 組織各能力子域之間的壁壘，構建 IT 組織和業務組織的溝通渠道，提供中心聯絡點，通過服務方式對外賦能，進行有價值的、高效的輸出，同時對運維所要達成的安全和穩定指標進行內部控制。

在事件和問題閉環方面，需要具備完善的監控手段，并根據服務級別制訂對應的應急處置預案，向價值交付鏈路的各能力子域提供對事件和問題的透明管理，推動形成閉環，最大限度地降低對業務和用戶的影響，同時避免發生同類問題。

運維服務流程和 DevOps 的集成

通過將運維服務流程和 DevOps 集成，在 DevOps 層面形成 DevOps 流程，并且面向價值交付流水線所有的職能領域，在運維應用層面，形成一站式運維平臺，通過 DevOps 服務目錄的方式進行 運維服務能力的輸出。

資源輸出、自動化運維工具、運維規范和運維流程的積木式整合可以對內實現安全和穩定，對外實現高效和低成本，涉及基礎架構、支撐平臺、應用運維和業務運維的各個節點。運維服務流程和 DevOps 的集成架構如圖 3-13 所示。

圖 3-13

運維服務流程和 DevOps 的集成架構分為兩層：工具層和服務層，其中服務層主要通過流程內嵌方式實現 SRE 和 DevOps 服務，并管理運維的資源、流程和服務，工具層通過工具實現運維的自動化，并為服務層提供運維服務流程體系的運維能力輸出，實現安全、穩定的運維服務，提升價值交付流水線的用戶體驗水平。