Python linux php mysql 编程 google nginx 云计算 Ubuntu Firefox 开源 centos Android 程序员 Windows wordpress apache 微软 shell java

優雲CMDB專家實踐談:自動化運維的基石CMDB

CMDB是什麽?

運維百花齊放繁榮景象的同時,也讓碎片化問題產生;每個人都想整合運維平臺,但是往往事與願違。

CMDB就像一個人的大腦核心,是一個信息協調庫,其存儲的資料是協調身體完成各種復雜運動的信息來源。

d32f871883056eeb8bf2ce61a1d27c4c237fd1d2

 

我心中的CMDB

. 碎片整合

面向運維工具的碎片化場景,是盤活整個運維管理的數據核心

. 元數據庫

提供運維活動的基礎元數據,是唯一可信的運維配置數據服務

. 場景驅動

為運維聯動提供數據驅動,可協調工具來完成各類自動化場景

d4d3c1c0ea23f0f2cf73c059bcc3aeedb22f5815da983227fe9232177c27c081e8f0f4a80789f572 

 ​自動擴容+自動監控

CMDB如何建設?

痛點現象與對策 I 模型建不好

存在的問題:

. 建模粒度失去控制

粒度若建得太細,連網線、內存條都變成配置項,最後CMDB中存儲的70%數據沒有作用,只是做了大量無用功。

. 缺少行業實踐參考

國內很多時候都是根據BMC、HP等模型來建立一個模型庫,但實際上老外的思路與國人迥異,往往會做出過於復雜的模型體系。

. 模型調整太笨重

使用關系型數據庫,模型中每一個類型的屬性都是一個列,最後調整總是要動用研發,完成一次調整需要2天的時間,而這種調整在數據補充階段,往往要經常進行,耗時耗力。

我們怎麽幹的– 管理

. 目標驅動

持續叠代的方式推進,只實現當前目標需要的最小模型集合。建議不要使用傳統軟件研發大瀑布模式來建設模型,而是使用持續叠代的方式,每次都設定一下較小的目標,按這個目標去建立剛好滿足要求的模型庫。

. 行業參考

尋找和借鑒行業最佳實踐。尋找行業內的最佳實踐,去學習他們的模型,尤其也是學習其演進路線,切不可一口吃成一個胖子。

6aa2b260b9a53eaa299e995ae3c50d502eb22b5f

 我們怎麽幹的– 技術

第一步,數據類型標簽化 ,支持多重身份

傳統的CMDB系統,往往使用科學分類法的思路,按界、門、綱、目等樹型結構去嚴格劃分,但這樣給建模帶來了非常巨大的挑戰,因為一定有一些數據四不像。比如虛擬機,到底是劃到傳統的計算設備資源下,還是劃到虛擬資源下?所以我們提議使用數據類型標簽化的方式來進行分類。比如虛擬機,我可以同時打上計算設備與虛擬資源這樣兩個標簽。

第二步,使用關系建立聯系 ,分清關系與屬性

使用弱類型約束的關系,而不是屬性。因為屬性往往要提前建模,但實際上很多配置項在建立時,是想不清楚它可能與哪些配置項產生聯系的,所以使用關系可以更輕量化。

第三步,易於調整模型 ,支持動態屬性

在CMDB系統的技術設計過種中,要註重使用能快速調整的存儲模型,比如使用支持scheme調整友好的數據庫,或postgresql這樣支持json擴展字段的數據庫,可以實現動態屬性。

痛點現象與對策 II數據不準確

存在的問題:

. 人工錄入數據、準確率低

. 沒有及時維護、數據過期

. 數據來源多、存在沖突

我們怎麽幹的– 管理

. 確定地位

確定CMDB作為唯一數據源,若上下數據流不準確,應從CMDB開始修正

. 職權劃定

自定原則,例如誰提供,誰維護

. 定期審查

從制度上需要確定團隊能定期對CMDB中的數據進行審計,尋找錯誤數據並改進問題。如同一些倉儲管理,需要定期核查帳面與實際庫存,CMDB也需要定期審查數據與生產環境的實際符合度。

4e6e0c87b5ae4d4584b3fab79fd7f39d3ba27ba1

 我們怎麽幹的– 技術

. 支持協同

配置變更熱點,訂閱我關註的配置項變更。每個人都可以查看他人的數據足跡,配置項也允許按變更次數或者被使用次數,作成熱點圖,最後也應允許訂閱我關心的配置項,這樣可以在配置項變更時,相關負責人可以及時收到通知。

. 記錄歷史

允許隨時查詢數據的變遷歷史,並可回溯基線。在每一次數據入庫後,都能記錄數據的變更歷史,以便可以隨時對比版本變更的內容,以及在糾錯時回溯基線。

. 支持調和

利用策略、規則實現多數據源的調和。數據來源過多,也會導致出現數據沖突。在數據出現沖突時,能顯示不同數據來源的沖突,並支持人為調和,同時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,還應該提供應用間的界面集成還應該提供應用間的界面集成還應該提供應用間的界面集成。

41db8990292ff6fb17bfe7ae5ab4f1e56dd19e30

 CMDB成功要素

能消費起來的CMDB才是好CMDB!

模型:定義了最小可用的CMDB模型結構與規則

數據:正確地維護了CMDB各類數據及其關系

API:提供了開放友好的API服務

場景:利用CMDB的數據玩轉各種運維場景

CMDB = 模型 + 數據 + API +場景

延伸阅读

    评论