cmdb(cmdb是什么意思)

經過兩年多的努力，在 2020 年微眾銀行智能化運維建設終于取得了明顯成效，在智能監控領域的異常識別及根因定位方面發揮了巨大作用，甚至可以做到了秒級異常發現與定位。CMDB 系統（配置管理平臺 Configuration Management Dateba）作為智能化運維體系的基石與保障，除了承擔存儲和元數據支撐以外，也為智能化運維體系的正常運作、敏捷擴展提供了有力保障。本文將結合具體實踐，介紹微眾銀行面向智能化運維的 CMDB 系統構建歷程以及實施效果。

前文回顧專題 | 智能時代下的運維

構建 CMBD 系統的三個階段

1.CMDB1.0 所面臨的痛點

在 2015 年微眾銀行成立之初，微眾銀行構建了 CMDB1.0。CMDB1.0 吸取了開源項目 oneCmdb 的經驗， CI 模型配置結合 key-value 形式存儲 CI 數據，靈活的支持了當時的銀行基礎架構建設的初級階段。但隨著不斷擴大的銀行業務規模，配置項越來越多樣，科技類的工具系統如雨后春筍般建立起來。在此過程中，CMDB1.0 的架構在系統間對接方面，配置項多樣性模型建設方面，以及數據量急速增加方面的可擴展性表現得越來越差， 同時用戶體驗方面也暴露出很多問題。在這個階段，痛點和不足主要表現為：

模型定義不完整：CMDB 中管理的配置范圍、配置數據覆蓋不全，配置關系及屬性定義不完整，無法有效支撐日常運維的基礎訴求。數據維護成本高：未建立配置信息的生命周期管理流程，無法達到自動更新維護數據的目的。當時，CMDB 中數據的采集和變更嚴重依賴人員維護，維護成本高，數據滯后于真實運行情況，甚至部分配置信息在系統外維護，CMDB 未能發揮應有的作用。數據質量無法保證：缺乏數據之間邏輯規則校驗機制以及數據同步校驗機制，數據準確性和數據質量無法保證，運維人員不信任 CMDB。

2. 面向智能化運維的 CMDB2.0 系統構建

從 2016 年開始，為構建自動化智能化運維體系，同時滿足微眾銀行分布式架構的運維管理要求，我們重新規劃搭建起了為支撐各運維場景，提供準確靈活基礎數據能力的新一代 CMDB 系統，并徹底解決了 CMDB1.0 階段所面臨痛點。

我們以應用為中心，通過自研提供完整的、準確的，能全網管理運維對象和關系存儲的模型，實現了與運維系統的靈活銜接。CMDB2.0 的優勢主要體現在如下三個方面：

以應用為中心。建立自動化、智能化運維體系，從應用的角度規劃管理各種運維場景。因此，在 CMDB2.0 的模型設計上，我們堅持以應用為中心，全面梳理和分析行內的運維對象及關系，從物理層、邏輯層和應用層幾方面分層構建模型。通過該模型中所定義的配置項及關系，可幫助應用運維在日常工作中快速查詢和了解整體應用資源對象和拓撲關系，提升變更發布、故障分析等運維工作效能。

圖 1 微眾銀行配置模型框架

重視系統的靈活性和可擴展能力性。CMDB2.0 一方面需要提升配置模型的管理能力，即快速靈活的實現模型隨著業務變化而調整、修正和擴展，滿足各個運維團隊對于配置數據的深度和廣度的需求；另一方面，也需要提高配置數據的易用性，幫助用戶或其他運維系統便捷、高效地查詢和引用 CMDB 數據。在這個思路下， CMDB2.0 管理平臺具備如下 6 個方面功能特性：

配置模型動態擴展：在線動態定義配置項，以及配置項的屬性、關系、數據類型、唯一性、組合關鍵字等；定義多維度查詢：支持在線自定義多項配置數據聯合查詢，以及全站檢索；API 接口動態生成：支持在線定義 API 接口，支持在線測試、驗證接口準確性；細粒度權限管控：實現行級列級的數據權限控制；多維度日志查詢：全站數據變遷的歷史追溯；版本基線比對及回退：支持配置模型版和配置數據的版本基線比對及回溯。

圖 2 CMDB 系統 API 接口在線調試功能

3.微服務架構下的 CMDB 3.0

隨著外圍系統對 CMDB2.0 的依賴越來越大，系統間調用關系越來越復雜， CMDB2.0 各模塊耦合高，一個服務節點同時支持規則、審計，報表、接口等功能，如果一個功能點異常可能會影響整個平臺服務。于是，CMDB3.0 進行了微服務架構升級，把系統接口調用、web 用戶訪問，規則處理、數據處理等按功能模塊抽離成單個微服務應用，使用 Dubbo 框架進行微服務治理，另外 3.0WEB 前端是基于 VUE 自研的框架，改善了用戶體驗，提高了團隊開發協作能力，降低了開發風險。

圖 3 CMDB 演進過程

CMDB 的系統設計思路：多維度確保數據的準確性

數據準確性是 CMDB 的生命，我們通過數據維護流程自動化、促進數據消費、數據審計等多維度保證數據的準確性，并提升使用價值，主要包括以下幾個方面：

1.建立數據生命周期管理，自動化流程驅動數據更新

CMDB2.0 在建設之初，就定義了每個配置項從生產、運營、消亡的整個生命周期，并通過設計與之匹配的 ITSM 流程自動化驅動生命周期狀態流轉，實現了數據閉環管理。同時，識別每個階段會影響的屬性及關系，保證配置模型的完整性。

圖 4 服務器生命周期狀態變更流程

2.與多個運維工具對接，促進數據消費，提高數據流動性

結合實際運維場景，與其他運維平臺聯動，數據被積極消費，在其他工具中體現 CMDB 信息的最大價值。數據被廣泛應用才能保持鮮活的生命力。如同池塘里的水，只有水不斷流動和交替，水質才能清澈。基于靈活 API 服務，微眾銀行 CMDB2.0 已實現與 ITSM、監控平臺、容量平臺、應用發布平臺、基礎科技工具平臺以及智能化運維平臺等系統對接。用一個子系統從設計態到運形態的整個生命周期為例，展示數據聯動的消費及流動過程如下。

圖 5 CMDB 和各運維系統交互實現數據消費及流動

3.通過規則校驗以及人工審計確保及時發現和修復異常數據

為了保證數據準確性，通過規則校驗、系統之間的信息同步比對以及人工抽樣審核的方式的定期審計。持續檢視和優化生命周期管理，不斷改善數據質量。微眾銀行關鍵配置項準確率達到 99% 以上。

表 1：CMDB 自動審計規則示例

配置項 自動審計規則 服務器

主機下關聯應用實例，主機狀態不是“已分配”，服務器狀態不是“已投產”主機類別是容器母機，對應服務器類別不是容器；已分配狀態主機沒有部署應用；

業務應用

業務應用狀態“已上線”所屬子系統狀態不是“已上線”；子系統狀態為“已下線”，仍部署業務應用；實施效果及未來展望

自 2017 年起，CMDB 得到全面推廣和運作。從這三年的運營效果來看，CMDB 有效支撐了上層業務運維, 其健壯性、靈活度及準確性得到了廣泛認可，已成為運維同事信任的好伙伴。

在應用規模上看，CMDB 已發展為運維同事管理和獲取配置數據的首選系統，平臺對接需求應接不暇。目前管理配置項總計 226 個，其中關鍵配置項通過流程維護和接口同步更新占比 72%。同時服務行內其他運維系統 50 個，提供系統接口超 300 個。

在服務數據化運營以及支持智能化運維方面，CMDB 已成為微眾銀行自智能化運維體系體系中不可缺少的成員。

驅動業務流程：CMDB 為各業務流程提供高質量的配置數據，所有業務系統架構設計、資源申請、上線部署和運行維護等流程，均是通過 CMDB 與多個系統的協同運作來驅動落地。當前僅 ITSM 系統中對接 CMDB 更新或查詢數據的流程已超過 200 個。服務數據化運營：支持服務容量規劃、成本核算、業務運營分析等場景，例如容量管理系統基于 CMDB 數據可提供業務整體資源利用率數據和各業務使用量數據分析報告。支持智能化運維：基于 CMDB 數據關系，通過監控系統端到端視圖輔助故障診斷定位、根因分析，使故障快速恢復和及時發現，已成功實現了對我行智能化監控系統這種復雜需求場景的有效支持。

圖 6 CMDB 數據輔助智能監控系統故障定位、根因分析

CMDB 的構建仍是一個持續迭代優化過程，2020 年我們基于微服務構建 CMDB3.0，期望 CMDB 能夠通過開源平臺的方式提供服務，同時實現配置項自動發現，圖像化元數據關系展示以及數據異常自動化修復等方面進一步提升。未來 CMDB 的運行效果我們會繼續分享給大家，希望大家持續關注我們的演進腳步。如果希望了解我們在智能運維中使用的機器學習算法以及支持根因分析的具體方法，請參閱該系列其他文章。

作者簡介

本文作者為微眾銀行智能運維系統高級產品經理 楊芳

延伸閱讀：

我們的CMDB模型是不是都錯了-InfoQ

愛奇藝MySQL高可用方案概述-InfoQ

從Oracle到MySQL，金融核心場景在線換庫落地實戰-InfoQ

關注我并轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書，點擊文末「了解更多」，即可移步InfoQ官網，獲取最新資訊～