關注嘉爲科技，獲取運維新知
自動化運維建設正在成爲很多企業當前或者下一階段的建設目標。這其中，很關鍵的一個組成部分就是配置管理數據庫（CMDB）。CMDB能否建設好是自動化運維建設能否真正落地的一個非常關鍵的因素。
大家都在談：CMDB建設要面向消費，面向應用，要實現可回寫，要保證數據一致性、完整性和準確性，要實現配置的生命週期管理……
這些都沒錯，是CMDB建設中的關鍵點和重要目標。但是，究竟該如何做才能實現上述目標呢？該如何控制，才能確保真實效果沒有與目標偏離呢？我們在這篇文章中一起探討下。以下文章僅代表個人觀點，難免偏頗和愚見，歡迎各位留言，一起討論。
本文的大綱：
- 好的CMDB建設：定義消費場景在先
- 好的CMDB建設：以應用爲中心，控制好範圍和顆粒度
- 好的CMDB建設：打通運維流程，實現數據讀寫閉環
- 好的CMDB建設：應該集成統一監控
- 好的CMDB建設：自動採集，足夠靈活
本篇文章中用到的幾個術語統一解釋如下：
一、定義消費場景在先
脫離CMDB數據使用場景，上來就要把企業全部的IT對象、屬性和關係全部囊括進CMDB的CMDB建設，都是耍流氓。
定義消費場景在先
各種自動化運維操作是場景：
- 比如新服務和應用的自動化發佈，需要知道當前可用的基礎資源有哪些；
IT環境監控和告警也是場景：
- 比如針對某臺數據庫服務器性能告警，需要判斷此服務器所屬業務和集羣；
ITSM流程對接也是場景：
- 比如ITSM的變更流程需要從CMDB中讀取配置對象和數據，以便執行變更；
資產管理和展示也是場景：
- 比如將企業的IT資產分類展示和查詢；
……
配置管理的消費場景很多，每個企業都需要梳理出自己真正需要的場景；並且這種梳理應該是基於企業的日常運維工作以及下一步運維提升的目標來制定，而不應離地三尺，肆意空想。
CMDB消費場景的梳理和挖掘
切忌好高騖遠，一味求全；否則CMDB建設範圍和顆粒度極易失去控制；就像一匹脫繮的野馬在茫茫大草原毫無目標的肆意馳騁。
例如，以下是一個企業的一個業務發佈場景，該場景通過自動化運維平臺實現流程的自動化操作。過程中，自動化操作步驟與CMDB的交互過程如下圖所示：
自動化操作步驟與CMDB的交互
在確定了消費場景的基礎上：
- 才能確定我們需要在CMDB中涵蓋哪些應用、業務、CI、CI項、關聯關係等；
- 才能確保我們錄入的數據最終是能在場景中得到使用和消費的，而不是靜止的死數據；
- 一旦數據被使用起來，並且通過工具和流程將實現配置數據的讀寫閉環之後，數據的一致性、完整性和準確性是必然的結果。
朱熹詩云：“問渠那得清如許，爲有源頭活水來”；一旦數據是能夠消費和使用起來，確保數據的一致性、完整性和準確性相對來說就是比較簡單的了。
二、以應用爲中心，控制好範圍和顆粒度
在確定好CMDB的數據消費場景基礎之上，接下來可以考慮着手進行“設計模型藍圖”的規劃了。
在藍圖規劃中，我們主要考慮三件事情：模型（CI）、屬性（CI項）、關聯關係。
這三者的出發點和落腳點都應該是應用系統或者業務系統。還記得上面那匹脫繮的野馬嗎？我們用應用或者業務系統這個套馬杆，把這匹馬拉回我們的軌道上來。
如下圖所示：手機銀行是某個銀行的應用系統之一，那麼與這個應用相關的全部對象都會被組織在這應用的下方。
以應用爲中心的配置管理
在“手機銀行”這個應用下方以層級的方式逐級展開各層資源：
- 比如應用本身可能是不同羣集環境的：生產羣集、測試羣集、預發佈羣集等；也可能是分不同區域羣集的：華東區域、華南區域、西北區域等；
- 每個羣集內部又分爲不同的模塊：前端web服務模塊、中間件模塊、數據庫模塊、其他組件模塊等；
- 每個模塊內部可能是就具體的虛擬機、物理服務器、容器、公有云、私有云、混合雲等基礎資源，以及中間件應用、數據庫應用、web應用、手機銀行應用本身的進程和服務等上層業務邏輯資源；
- 每個資源對象本身都有自己的配置信息，對象與對象之間有着各種各樣的關聯關係；
到這裏，我們就把“手機銀行”這個應用下方需要的模型（CI）、屬性（CI項）、關聯關係等全部梳理清楚了。
其他的應用大體過程類似。出應用或者業務系統出發，最終迴歸到應用和業務系統。
應用下各對象的關聯關係
三、打通運維流程，實現數據讀寫閉環
很多企業裏已經有了自己的運維工單流，可能是ITIL範式的，也可能是非ITIL範式的；無論哪種，在可能的情況下，最好能將CMDB與運維流程本身集成和打通，這樣CMDB的數據一致性、準確性和完整性纔有了保障。
與流程平臺對接的過程，事實上也是將CMDB配置生命週期管理納入企業統一的運維流程管理的過程。所謂實現“配置的全生命週期管理”並不是要爲配置管理專門生造一個流程，IT對象的生命週期管理過程中本身就涵蓋了配置管理；配置管理的生命週期是隨着IT對象生命週期而運行的，不存在單獨的配置管理生命週期。（ITIL中的配置管理流程事實上是與對象的生命週期管理緊密關聯的，是變更管理和事件管理等其他流程的結果，還不是主動發起方。）
所以，IT對象和資源生命週期管理的好的企業，往往配置信息也能管理的比較好。而IT對象和資源生命週期管理的比較混亂的公司，配置信息管不好簡直是一定的，並且在這種情況下關鍵是要把各個IT對象和資源生命週期管理梳理清楚，而不是腳痛醫腳，只考慮配置的生命週期管理如何建立。
這裏面對接的情況就稍微複雜一些：
- 可能是企業已有ITSM系統或者即將上ITSM系統，ITSM有自己的CMDB，自動化運維的CMDB需要與已有的CMDB做對接和集成；
- 可能是企業已有ITSM系統或者即將上ITSM系統，系統自帶CMDB，企業準備後續停用ITSM的CMDB或者不用ITSM的CMDB，統一用自動化運維的CMDB作爲數據源。
每種情況，我們都需要考慮清楚如果將新建的自動化運維的CMDB與傳統的流程系統對接和集成，實現統一的數據消費、回寫和閉環流程。
在對接流程這個層面，出發點和落腳點依然是實用主義；並不是一股腦要實現全部流程和CMDB的對接和集成；
可以考慮先把日常使用最多、同時會更改IT環境的配置信息的部分流程對接到CMDB，先解決最大的麻煩點和成本點；
後續再逐步將涉及到CMDB配置變更的流程對接到CMDB；至於某些流程本身壓根不需要CMDB參與的，可以暫時不用考慮對接。
CMDB與運維流程對接、集成
除了流程對於CMDB信息的讀寫之外，還有另外一個方向的數據傳遞：配置的變化需要及時通知管理員，並且最好能夠自動啓動一個處理工單。這就要求CMDB本身具備事件推送能力。
CMDB推送事件到外部系統
在這一個層次，技術難度是其次的；考慮清楚整個邏輯鏈條、數據閉環、雙方對接方式、未來流程和配置的持續擴展才是難點和重點，是需要仔細而慎重的去考慮的。
四、應該集成統一監控
監控在以往和自動化運維包括CMDB等的關係好像不大。兩者更多的是分離的兩個系統：自動化運維以CMDB爲基礎，實現運維操作的自動化執行和配置數據的統一讀寫；而監控則依賴自身的採集器和接入的採集對象，實現對象的運行信息、性能信息和安全信息等的統一採集、分析和告警服務。
然後，在一個更高層面的企業IT運維自動化運維藍圖中，統一監控和自動化運維（包括CMDB）兩者應該是辯證統一的。
CMDB、自動化運維和監控系統是有機的整體
在與監控對接和集成中，我們分爲這麼幾個層面來考慮：
1、數據採集
監控和CMDB關係
在數據採集階段，僅僅採集對象的運行數據、性能數據和安全數據顯然是不夠的，還需要知道這些對象具體位於哪個應用或者業務、哪個羣集、哪個模塊下面：某個數據如果異常會影響到具體的哪個業務或者應用系統？這種影響的範圍有多大？重不重要？需要採取何種的處置措施來應對。
這些信息，需要聯動CMDB，讀取相應業務或者應用下的具體對象、配置信息和關聯關係才能獲取；
當然，這些信息可以另外單獨在監控中實現，但事實上這個活CMDB就能幹，並且能幹的很好，又何苦再在監控系統中重複建設呢？
2、數據分析與告警服務
CMDB與監控告警服務
當監控系統觸發某個告警之後，如果單獨將某個對象的某個指標異常報告給管理員，此時管理員會怎麼辦呢？
一般情況是：憑記憶或者手動打開自己的某個Excel表格或者登錄某個數據極可能不太準確的舊的配置管理數據軟件，查詢產生這個告警的具體IT對象實例是誰？哪個業務或者應用下面的？應用本身重不重要？測試環境還是生產環境？然後再決定怎麼處理。
與CMDB集成之後，監控就能在把告警服務通告出來的同時，直接體現上述信息。
這僅僅是第一步，事實上，監控與CMDB集成之後，能夠做的更多：
- 由於集成了CMDB，監控系統事實上能夠獲取某個應用下的全部對象、配置信息和關聯關係，具備這個應用的全部邏輯和物理對象視圖，因此具備了實現高級統一監控的堅實基礎；
- 在告警服務層面能夠實現諸如：告警源清洗、關聯分析、事件定位、告警收斂、告警屏蔽、告警彙總、處理建議、評估分析、告警通知等高級監控服務；
- 在實現了我們前述的對接運維流程的基礎上，還能夠實現：某項告警直接驅動工單生成，並通過應用、郵件、短信和電話等通知到相關責任人處理。實現告警工單的自動化生成和處理。
3、故障自動處理
監控的目的是什麼？
及時發現甚至提前預測可能出現的故障，以便及時處理，儘可能減少對業務的影響。簡而言之就是預測故障（很難，大家整體處於探索階段）、發現故障、處理故障、保證業務或者應用。
因此，高級的監控系統需要具備故障自動處理模塊，以便監控報告故障之後能夠及時、自動化處理故障，將故障的影響範圍和程度降到最低。
故障自愈簡易流程圖
而故障的自動處理事實上依然需要依賴自動化運維平臺的功能和組件，比如腳本執行和文件分發編排、標準運維流程編排等等；而自動化運維的基礎是CMDB，對吧？所有這些操作都需要知曉對象、配置信息和關聯關係。所以，在故障自動處理階段，依然需要CMDB介入，提供應用下的完整配置信息和關聯關係。
綜上：監控處理過程，包括數據採集、數據分析和告警服務、故障自動處理等都需要與CMDB緊密結合，兩者共同構建更爲強大和務實的監控能力。
監控與CMDB的交互過程
五、自動採集，足夠靈活
1、配置數據的自動採集和維護、批量導入和導出是好的CMDB建設的基本要求。
想象一下，如果大部分配置數據都要手動輸入和維護，這是一件多麼痛苦的事情。
因此需要CMDB本身能夠將絕大部分的配置信息實現自動化採集和維護，減輕維護工作量，提升效率和準確性。
CMDB需要支持自動採集
2、能夠支持CI、CI項、關聯關係的靈活自定義
由於每個企業的IT環境和運維流程都不一樣，CMDB在每個企業落地的時候在最佳實踐的框架內，內容和形式註定是個性化的。這就要求CMDB本身具備足夠的靈活性，使得企業能夠根據自己的情況自定義CI、CI項和關聯關係。
CMDB需要支持靈活自定義關聯關係
CMDB需要支持靈活自定義CI和CI項
3、嚴格而靈活的權限控制
由於CMDB中存儲着全部應用和對象資源的配置信息，因此權限控制就顯得尤爲重要。CMDB本身需要能夠實現比較細的、比較靈活的CMDB權限管理。
CMDB要支持靈活的權限管控
CMDB要支持靈活的權限管控
4、 CMDB需要具備足夠開放的API
由於CMDB本身是一個基礎功能組件，本身需要對外提供數據並接受數據的寫入，因此需要CMDB本身提供足夠豐富的API接口。這一點在複雜的環境，以及考慮到企業未來IT環境和管理的擴展的情況下，就顯得尤爲重要。
例如，很多企業有大屏系統，並需要把一些關鍵業務和應用在大屏系統中集中展示，這就需要CMDB能提供相應的接口和服務。
CMDB需要能提供豐富的API接口
CMDB需要能提供豐富的API接口
5、支持審計，並能支持海量跨雲環境
支持審計這點，不必多說。稍微上規模，IT管理有一定規範的企業都會如此要求。
CMDB需要支持審計
支持海量環境這點非常重要。完全可以預計，隨着企業的發展和IT規模的持續擴展，CMDB中入庫的對象和數據會越來越多。因此要求CMDB本身具備納管海量配置的能力，並且經受過實體的業務環境的檢測。
CMDB支持海量環境擴展
總結一下，好的CMDB建設需要：
- 定義消費場景在先
- 以應用爲中心，控制好範圍和顆粒度
- 打通運維流程，實現數據讀寫閉環
- 應該集成統一監控
- 自動採集，足夠靈活
以上是個人對於好的CMDB建設在企業落地的時候應該重點考慮的一些要素。能力所限，偏頗和愚見難免。歡迎各位同學在評論區留言探討。
本文首發於微信公衆號：嘉爲科技，轉載請註明出處。