cmdb是什麼？
運維百花齊放繁榮景象的同時，也讓碎片化問題産生；每個人都想整合運維平台，但是往往事與願違。
cmdb就像一個人的大腦核心，是一個資訊協調庫，其存儲的資料是協調身體完成各種複雜運動的資訊來源。
我心中的cmdb
. 碎片整合
面向運維工具的碎片化場景，是盤活整個運維管理的資料核心
. 中繼資料庫
提供運維活動的基礎中繼資料，是唯一可信的運維配置資料服務
. 場景驅動
為運維關聯提供資料驅動，可協調工具來完成各類自動化場景
自動擴容+自動監控
cmdb如何建設？
痛點現象與對策 i 模型建不好
存在的問題：
. 模組化粒度失去控制
粒度若建得太細，連網線、記憶體條都變成配置項，最後cmdb中存儲的70%資料沒有作用，隻是做了大量無用功。
. 缺少行業實踐參考
國内很多時候都是根據bmc、hp等模型來建立一個模型庫，但實際上老外的思路與國人迥異，往往會做出過于複雜的模型體系。
. 模型調整太笨重
使用關系型資料庫，模型中每一個類型的屬性都是一個列，最後調整總是要動用研發，完成一次調整需要2天的時間，而這種調整在資料補充階段，往往要經常進行，耗時耗力。
我們怎麼幹的– 管理
. 目标驅動
持續疊代的方式推進，隻實作目前目标需要的最小模型集合。建議不要使用傳統軟體研發大瀑布模式來建設模型，而是使用持續疊代的方式，每次都設定一下較小的目标，按這個目标去建立剛好滿足要求的模型庫。
. 行業參考
尋找和借鑒行業最佳實踐。尋找行業内的最佳實踐，去學習他們的模型，尤其也是學習其演進路線，切不可一口吃成一個胖子。
我們怎麼幹的– 技術
第一步，資料類型标簽化 ,支援多重身份
傳統的cmdb系統，往往使用科學分類法的思路，按界、門、綱、目等樹型結構去嚴格劃分，但這樣給模組化帶來了非常巨大的挑戰，因為一定有一些資料四不像。比如虛拟機，到底是劃到傳統的計算裝置資源下，還是劃到虛拟資源下？是以我們提議使用資料類型标簽化的方式來進行分類。比如虛拟機，我可以同時打上計算裝置與虛拟資源這樣兩個标簽。
第二步，使用關系建立聯系 ,厘清關系與屬性
使用弱類型限制的關系，而不是屬性。因為屬性往往要提前模組化，但實際上很多配置項在建立時，是想不清楚它可能與哪些配置項産生聯系的，是以使用關系可以更輕量化。
第三步，易于調整模型 ,支援動态屬性
在cmdb系統的技術設計過種中，要注重使用能快速調整的存儲模型，比如使用支援scheme調整友好的資料庫，或postgresql這樣支援json擴充字段的資料庫，可以實作動态屬性。
痛點現象與對策 ii資料不準确
. 人工錄入資料、準确率低
. 沒有及時維護、資料過期
. 資料來源多、存在沖突
. 确定地位
确定cmdb作為唯一資料源，若上下資料流不準确，應從cmdb開始修正
. 職權劃定
自定原則，例如誰提供，誰維護
. 定期審查
從制度上需要确定團隊能定期對cmdb中的資料進行審計，尋找錯誤資料并改進問題。如同一些倉儲管理，需要定期核查帳面與實際庫存，cmdb也需要定期審查資料與生産環境的實際符合度。
. 支援協同
配置變更熱點,訂閱我關注的配置項變更。每個人都可以檢視他人的資料足迹，配置項也允許按變更次數或者被使用次數，作成熱點圖，最後也應允許訂閱我關心的配置項，這樣可以在配置項變更時，相關負責人可以及時收到通知。
. 記錄曆史
允許随時查詢資料的變遷曆史，并可回溯基線。在每一次資料入庫後，都能記錄資料的變更曆史，以便可以随時對比版本變更的内容，以及在糾錯時回溯基線。
. 支援調和
利用政策、規則實作多資料源的調和。資料來源過多，也會導緻出現資料沖突。在資料出現沖突時，能顯示不同資料來源的沖突，并支援人為調和，同時cmdb系統也應學習這些人為的調和依據，可以形成自動化調和。
. 依賴工具
在資料的采集和補充上，以使用監控與自動化工具為主，它們可以減少大量的錄入工作，并且避免人為的錯誤。
痛點現象與對策 iii資料不好用
. 不清楚有哪些使用場景
經常有這樣的情形：為了cmdb而cmdb，導緻最後cmdb隻是當資源台帳使用，最常使用的功能也僅僅變成了excel導入與導出。而實際上，我們需要建設的是一個服務型的cmdb。
. 系統開放性差
cmdb開放性差，往往隻是提供了讀寫api，把cmdb當成一個普通的資料庫來使用。
1. 積極尋找場景，消費資料，讓資料産生價值。
2. 影響分析：使用消息盤，做配置變更演練，做故障演練。
3. 自動監控：當新增一些配置項時，可以通知到監控系統，自動産生監測政策。
4. 自動排障：在監測到故障時，可以自動排障。
5. 容量管理：在配置庫中為應用記錄擴容收容門檻值，以便自動伸縮擴容。
6. 物聯運維：cmdb中的資料，在現在的移動終端場景下，有特别好的消費場景，就是做二維碼、rfid，并與手機結合，能在機房巡檢與排障中産生很大的便利。
我們怎麼幹的– 技術
1. 關系推導：提供從一個配置項按關系提煉其它配置項的能力。
2. 全文檢索：能便捷的使用關鍵字，搜尋符合的配置項。
3. 變更通知：配置項變更不但提供對人的通知，更要利用mq，提供對運維工具的通知，以觸發一些自動化場景。
4. 事務控制：允許通過api建立沙箱，整個沙箱中的配置項是一起送出與一起復原，這特别适用于應用的上線。
5. 版本對比：允許查詢一個配置項的曆史資料與變更情況。
6. web內建：除了api，還應該提供應用間的界面內建還應該提供應用間的界面內建還應該提供應用間的界面內建。
cmdb成功要素
能消費起來的cmdb才是好cmdb！
模型：定義了最小可用的cmdb模型結構與規則
資料：正确地維護了cmdb各類資料及其關系
api：提供了開放友好的api服務
場景：利用cmdb的資料玩轉各種運維場景
cmdb = 模型 + 資料 + api +場景
作者：蔣君偉，任職廣通軟體新一代靈活運維品牌優雲，旗下包含cmdb、監控中心、操作中心、流程中心、度量中心一體化的“一庫四中心”靈活運維産品線，同時支援線上服務與私有部署。官網:https://uyun.cn