《如何理解CMDB的套路》要點:
本文介紹了如何理解CMDB的套路,希望對您有用。如果有疑問,可以聯系我們。
CMDB成功和失敗,關于掌握的CMDB套路的多與少、深與淺!
前幾天在對一個項目進行總結,編寫CMDB的配置管理規范,發現還是有很多套路,本文就是老王總結的CMDB套路!
什么叫配置?的確現在很多配置管理的工具,這些東西也是沿襲下來,但我更喜歡puppet里面提到的資源概念.資源幾乎可以和對象的概念對等,對象有屬性,資源也有屬性;對象有方法,資源也有動作,額外增加一點,資源還有狀態.記住一些,可以把一切對象當成資源來看.
我為什么堅持要改名?從現實的情況來說,大家一說CMDB都是那些傳統的討論,自動發現、配置項、配置屬性.另外動不動就是一些一些表單的設計和管理,而忽略一個真正的CMDB是什么?
真正的CMDB就是要把內部所有的IT資源管理起來!
在下圖的模型中,CMDB的模型是有層次的,我把他定義成核心模型和擴展模型.
?堅持核心模型的導入,逐步驅動周邊的配套資源完善,這是 應用驅動CMDB的最核心切入點.
從上圖中,你可以看到CMDB模型中只有三種關系,三種關系如下:
自動發現在一定成都上能降低維護的成本和代價,但我不迷信這個能力.一則自動發現的能力一定有需要人工介入的過程,比如說網卡速率的自動發現,出現異常的時候,肯定不能進入CMDB;其次自動發現在某種場景是不能直接生效的,舉個例子,比如說某個機器內的進程和端口信息需要做自動監控,此時如果通過自動發現來實現主機上的進程和端口信息維護(其實簡單),但這個就需要監控系統適應變更期內進程被暫停的情況,暫停導致機器的進程信息自動發現不全.
第一、涉及到資源狀態的變更劃分,其實都應該需要人為參與的.比如說IP/服務器資源從資源池進出的過程;狀態的變更會涉及到監控策略自動變化的.從狀態這個維度進去,很容易找到人工和自動的邊界,而非狀態屬性的填充則無所謂了.
第二、跨組的資源管理則需要流程驅動,目前來看比如說防火墻、IP地址、服務器是典型的跨組/部門管理的資源.資源的管理方和使用方需要一些流程管控.當然這個地方有改進的地方啊,如果是管理平臺完善,是可以通過平臺來簡化流程的哈.DNS、負載均衡資源的管理也是一個典型的例子.
圖中的每條線上都是一個CMDB管理流程,【初始化完成】除外!
領導非常重要,領導參與加上團隊的一致理解,這個CMDB不成功都難.很多CMDB項目的失敗,不是技術層面上導致的,而是和人有關.
說到一致理解,我覺得CMDB的概念、模型、流程、場景、實施方法要足夠的簡單.CMDB的導入最好開始能帶一個場景進去,無論是對事件的支撐、還是對監控的支撐.
在CMDB系統中其實有很深的層次,云計算的概念層次就是CMDB的模型層次.在你構建模型的時候也需要構建這樣的一個分層能力,這個能力劃分開來之后,對持續部署的影響也是在的.我們的實踐檢驗出來是持續部署標準化的規范也需要這樣的分層思路,越界導致系統管理不清楚,監控也是如此!
有一點我沒想清楚的是,PaaS的資源到底是應用附屬資源管理,還是作為獨立資源管理?特別是公有云的模式下.
這句話說起來好簡單,CMDB不僅僅映射出你管理的IT資源模型,其實更是你組織管理模型的映照.當一個對象找不到Owner的時候,你需要思考到底什么問題?當一個流程無法推行的時候,你同樣要去思考組織的管理是復雜了還是執行力不夠?
CMDB背后有著很多的套路,它和自動化系統有一些不同,做一個管理信息系統比做一個工具系統會更難,理解這些套路,也就接近了成功!
作者:老王
文章來源:互聯網運維雜談(訂閱號ID:waynewang_ops)