《如何理解CMDB的套路》要點：
本文介紹了如何理解CMDB的套路，希望對您有用。如果有疑問，可以聯(lián)系我們。

CMDB成功和失敗,關(guān)于掌握的CMDB套路的多與少、深與淺!

前幾天在對一個項目進(jìn)行總結(jié),編寫CMDB的配置管理規(guī)范,發(fā)現(xiàn)還是有很多套路,本文就是老王總結(jié)的CMDB套路!

套路1：CMDB名字應(yīng)該改一下了,叫IT資源管理

什么叫配置?的確現(xiàn)在很多配置管理的工具,這些東西也是沿襲下來,但我更喜歡puppet里面提到的資源概念.資源幾乎可以和對象的概念對等,對象有屬性,資源也有屬性；對象有方法,資源也有動作,額外增加一點,資源還有狀態(tài).記住一些,可以把一切對象當(dāng)成資源來看.

我為什么堅持要改名?從現(xiàn)實的情況來說,大家一說CMDB都是那些傳統(tǒng)的討論,自動發(fā)現(xiàn)、配置項、配置屬性.另外動不動就是一些一些表單的設(shè)計和管理,而忽略一個真正的CMDB是什么?

真正的CMDB就是要把內(nèi)部所有的IT資源管理起來!

套路2：CMDB模型有層次

在下圖的模型中,CMDB的模型是有層次的,我把他定義成核心模型和擴(kuò)展模型.

• 核心模型.核心模型是記錄了業(yè)務(wù)、應(yīng)用和主機Host的關(guān)系,其他的關(guān)系都可以不記錄.有了這個模型基本上可以運轉(zhuǎn)后續(xù)的自動化和監(jiān)控系統(tǒng)了；其次還可以有效的管理公有云上的主機信息.

核心模型絕不是基礎(chǔ)設(shè)施級的資源模型!

• 擴(kuò)展模型.擴(kuò)展模型就是依賴核心模型擴(kuò)展出來的,比如說基于應(yīng)用需要找到關(guān)聯(lián)的一些資源信息；基于主機找到它關(guān)聯(lián)的一些依賴設(shè)備信息,比如說機柜、存儲和交換機等等,不斷的擴(kuò)展對象模型.

?堅持核心模型的導(dǎo)入,逐步驅(qū)動周邊的配套資源完善,這是 應(yīng)用驅(qū)動CMDB的最核心切入點.

套路3：CMDB的對象關(guān)系要簡化

從上圖中,你可以看到CMDB模型中只有三種關(guān)系,三種關(guān)系如下：

• 主從關(guān)系.這種關(guān)系是一種強父子關(guān)系,主不存在了,則從就不存在了.用明細(xì)表來表達(dá),屬于對象級別的關(guān)系.可以通過明細(xì)表來表達(dá),在easyops平臺中用內(nèi)聯(lián)表來表達(dá).
• 依賴關(guān)系.是一種對象屬性級之間的關(guān)聯(lián)關(guān)系,比如說服務(wù)器放在機柜上,機柜擺在某個機房內(nèi),這是對象級別的關(guān)系.通過對象的屬性關(guān)聯(lián)來表達(dá).
• 連接關(guān)系.主機和存儲、主機和網(wǎng)絡(luò)設(shè)備的關(guān)系,是連接關(guān)系.這種關(guān)系是動態(tài)生成的,是一種實例級的關(guān)系.

依賴關(guān)系和連接關(guān)系有什么不同?

• 依賴是一對多的關(guān)系,并且這個關(guān)系是靠人維護(hù)的,比如說機柜上放了很多服務(wù)器.
• 連接是多對多關(guān)系,并且這個關(guān)系是因為某種“連接”產(chǎn)生的,比如說服務(wù)器連接了交換機.可以通過自動發(fā)現(xiàn)來實現(xiàn),如果是人來維護(hù),基本上不可能.

套路4：不要太迷信自動發(fā)現(xiàn)

自動發(fā)現(xiàn)在一定成都上能降低維護(hù)的成本和代價,但我不迷信這個能力.一則自動發(fā)現(xiàn)的能力一定有需要人工介入的過程,比如說網(wǎng)卡速率的自動發(fā)現(xiàn),出現(xiàn)異常的時候,肯定不能進(jìn)入CMDB；其次自動發(fā)現(xiàn)在某種場景是不能直接生效的,舉個例子,比如說某個機器內(nèi)的進(jìn)程和端口信息需要做自動監(jiān)控,此時如果通過自動發(fā)現(xiàn)來實現(xiàn)主機上的進(jìn)程和端口信息維護(hù)(其實簡單),但這個就需要監(jiān)控系統(tǒng)適應(yīng)變更期內(nèi)進(jìn)程被暫停的情況,暫停導(dǎo)致機器的進(jìn)程信息自動發(fā)現(xiàn)不全.

仔細(xì)思考過自動發(fā)現(xiàn)和人工維護(hù)的邊界?

第一、涉及到資源狀態(tài)的變更劃分,其實都應(yīng)該需要人為參與的.比如說IP/服務(wù)器資源從資源池進(jìn)出的過程；狀態(tài)的變更會涉及到監(jiān)控策略自動變化的.從狀態(tài)這個維度進(jìn)去,很容易找到人工和自動的邊界,而非狀態(tài)屬性的填充則無所謂了.

第二、跨組的資源管理則需要流程驅(qū)動,目前來看比如說防火墻、IP地址、服務(wù)器是典型的跨組/部門管理的資源.資源的管理方和使用方需要一些流程管控.當(dāng)然這個地方有改進(jìn)的地方啊,如果是管理平臺完善,是可以通過平臺來簡化流程的哈.DNS、負(fù)載均衡資源的管理也是一個典型的例子.

圖中的每條線上都是一個CMDB管理流程,【初始化完成】除外!

套路5：CMDB要領(lǐng)導(dǎo)參與,團(tuán)隊理解一致

領(lǐng)導(dǎo)非常重要,領(lǐng)導(dǎo)參與加上團(tuán)隊的一致理解,這個CMDB不成功都難.很多CMDB項目的失敗,不是技術(shù)層面上導(dǎo)致的,而是和人有關(guān).

說到一致理解,我覺得CMDB的概念、模型、流程、場景、實施方法要足夠的簡單.CMDB的導(dǎo)入最好開始能帶一個場景進(jìn)去,無論是對事件的支撐、還是對監(jiān)控的支撐.

套路6：云計算的概念層次就是CMDB的層次

在CMDB系統(tǒng)中其實有很深的層次,云計算的概念層次就是CMDB的模型層次.在你構(gòu)建模型的時候也需要構(gòu)建這樣的一個分層能力,這個能力劃分開來之后,對持續(xù)部署的影響也是在的.我們的實踐檢驗出來是持續(xù)部署標(biāo)準(zhǔn)化的規(guī)范也需要這樣的分層思路,越界導(dǎo)致系統(tǒng)管理不清楚,監(jiān)控也是如此!

有一點我沒想清楚的是,PaaS的資源到底是應(yīng)用附屬資源管理,還是作為獨立資源管理?特別是公有云的模式下.

套路7：CMDB是你的IT資源和組織的快照

這句話說起來好簡單,CMDB不僅僅映射出你管理的IT資源模型,其實更是你組織管理模型的映照.當(dāng)一個對象找不到Owner的時候,你需要思考到底什么問題?當(dāng)一個流程無法推行的時候,你同樣要去思考組織的管理是復(fù)雜了還是執(zhí)行力不夠?

CMDB背后有著很多的套路,它和自動化系統(tǒng)有一些不同,做一個管理信息系統(tǒng)比做一個工具系統(tǒng)會更難,理解這些套路,也就接近了成功!

作者：老王

文章來源：互聯(lián)網(wǎng)運維雜談(訂閱號ID：waynewang_ops)

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4417.html