如何理解CMDB的套路？
套路1：CMDB名字應該改一下了，叫IT資源管理什么叫配置?的確現(xiàn)在很多配置管理的工具，這些東西也是沿襲下來，但我更喜歡puppet里面提到的資源概念 。資源幾乎可以和對象的概念對等，對象有屬性，資源也有屬性;對象有方法，資源也有動作，額外增加一點，資源還有狀態(tài) 。記住一些，可以把一切對象當成資源來看 。我為什么堅持要改名?從現(xiàn)實的情況來說，大家一說CMDB都是那些傳統(tǒng)的討論，自動發(fā)現(xiàn)、配置項、配置屬性 。
另外動不動就是一些一些表單的設計和管理，而忽略一個真正的CMDB是什么?真正的CMDB就是要把內部所有的IT資源管理起來!套路2：CMDB模型有層次在下圖的模型中，CMDB的模型是有層次的，我把他定義成核心模型和擴展模型 。核心模型 。核心模型是記錄了業(yè)務、應用和主機Host的關系，其他的關系都可以不記錄 。
有了這個模型基本上可以運轉后續(xù)的自動化和監(jiān)控系統(tǒng)了;其次還可以有效的管理公有云上的主機信息 。核心模型絕不是基礎設施級的資源模型!擴展模型 。擴展模型就是依賴核心模型擴展出來的，比如說基于應用需要找到關聯(lián)的一些資源信息;基于主機找到它關聯(lián)的一些依賴設備信息，比如說機柜、存儲和交換機等等，不斷的擴展對象模型 。
堅持核心模型的導入，逐步驅動周邊的配套資源完善，這是 應用驅動CMDB的最核心切入點 。套路3：CMDB的對象關系要簡化從上圖中，你可以看到CMDB模型中只有三種關系，三種關系如下：主從關系 。這種關系是一種強父子關系，主不存在了，則從就不存在了 。用明細表來表達，屬于對象級別的關系 。可以通過明細表來表達，在easyops平臺中用內聯(lián)表來表達 。
依賴關系 。是一種對象屬性級之間的關聯(lián)關系，比如說服務器放在機柜上，機柜擺在某個機房內，這是對象級別的關系 。通過對象的屬性關聯(lián)來表達 。連接關系 。主機和存儲、主機和網(wǎng)絡設備的關系，是連接關系 。這種關系是動態(tài)生成的，是一種實例級的關系 。依賴關系和連接關系有什么不同?依賴是一對多的關系，并且這個關系是靠人維護的，比如說機柜上放了很多服務器 。
【分鐘搭建一個超好用的,CMDB】連接是多對多關系，并且這個關系是因為某種“連接”產生的，比如說服務器連接了交換機 。可以通過自動發(fā)現(xiàn)來實現(xiàn)，如果是人來維護，基本上不可能 。套路4：不要太迷信自動發(fā)現(xiàn)自動發(fā)現(xiàn)在一定成都上能降低維護的成本和代價，但我不迷信這個能力 。一則自動發(fā)現(xiàn)的能力一定有需要人工介入的過程，比如說網(wǎng)卡速率的自動發(fā)現(xiàn)，出現(xiàn)異常的時候，肯定不能進入CMDB;其次自動發(fā)現(xiàn)在某種場景是不能直接生效的，舉個例子，比如說某個機器內的進程和端口信息需要做自動監(jiān)控，此時如果通過自動發(fā)現(xiàn)來實現(xiàn)主機上的進程和端口信息維護(其實簡單)，但這個就需要監(jiān)控系統(tǒng)適應變更期內進程被暫停的情況，暫停導致機器的進程信息自動發(fā)現(xiàn)不全 。
仔細思考過自動發(fā)現(xiàn)和人工維護的邊界?第一、涉及到資源狀態(tài)的變更劃分，其實都應該需要人為參與的 。比如說IP/服務器資源從資源池進出的過程;狀態(tài)的變更會涉及到監(jiān)控策略自動變化的 。從狀態(tài)這個維度進去，很容易找到人工和自動的邊界，而非狀態(tài)屬性的填充則無所謂了 。第二、跨組的資源管理則需要流程驅動，目前來看比如說防火墻、IP地址、服務器是典型的跨組/部門管理的資源 。
資源的管理方和使用方需要一些流程管控 。當然這個地方有改進的地方啊，如果是管理平臺完善，是可以通過平臺來簡化流程的哈 。DNS、負載均衡資源的管理也是一個典型的例子 。圖中的每條線上都是一個CMDB管理流程，【初始化完成】除外!套路5：CMDB要領導參與，團隊理解一致領導非常重要，領導參與加上團隊的一致理解，這個CMDB不成功都難 。
推薦閱讀
- 小米振動棒，小米4手機上每一個孔的作用
- 韭菜是發(fā)物嗎
- wifi和wlan的區(qū)別，哪一個更好？
- 皇冠蛋糕員工工資多少一個月,丹香蛋糕員工工資多少錢
- 二什么的成語有哪些 聞的成語有哪些
- oppoa5手機價格，oppoa5多少錢一個
- 松下ls2，佳能A460索尼DSCS650松下DMCLS2 哪一個好啊
- 問一個錘子系統(tǒng)的問題
- 什么軟件能賺游幣,用什么軟件打開
- 手抓餅批發(fā)多少錢一個,北京手抓餅多少錢一個