共計 2174 個字符，預計需要花費 6 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章將為大家詳細講解有關 CMDB 的示例分析，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

套路 1：CMDB 名字應該改一下了，叫 IT 資源管理

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

我為什么堅持要改名? 從現實的情況來說，大家一說 CMDB 都是那些傳統的討論，自動發現、配置項、配置屬性。另外動不動就是一些一些表單的設計和管理，而忽略一個真正的 CMDB 是什么?

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

套路 2：CMDB 模型有層次

在下圖的模型中，CMDB 的模型是有層次的，我把他定義成核心模型和擴展模型。

核心模型。核心模型是記錄了業務、應用和主機 Host 的關系，其他的關系都可以不記錄。有了這個模型基本上可以運轉后續的自動化和監控系統了; 其次還可以有效的管理公有云上的主機信息。

核心模型絕不是基礎設施級的資源模型!

擴展模型。擴展模型就是依賴核心模型擴展出來的，比如說基于應用需要找到關聯的一些資源信息; 基于主機找到它關聯的一些依賴設備信息，比如說機柜、存儲和交換機等等，不斷的擴展對象模型。

堅持核心模型的導入，逐步驅動周邊的配套資源完善，這是 應用驅動 CMDB 的最核心切入點。

套路 3：CMDB 的對象關系要簡化

從上圖中，你可以看到 CMDB 模型中只有三種關系，三種關系如下：

主從關系。這種關系是一種強父子關系，主不存在了，則從就不存在了。用明細表來表達，屬于對象級別的關系。可以通過明細表來表達，在 easyops 平臺中用內聯表來表達。

依賴關系。是一種對象屬性級之間的關聯關系，比如說服務器放在機柜上，機柜擺在某個機房內，這是對象級別的關系。通過對象的屬性關聯來表達。

連接關系。主機和存儲、主機和網絡設備的關系，是連接關系。這種關系是動態生成的，是一種實例級的關系。

依賴關系和連接關系有什么不同?

依賴是一對多的關系，并且這個關系是靠人維護的，比如說機柜上放了很多服務器。

連接是多對多關系，并且這個關系是因為某種“連接”產生的，比如說服務器連接了交換機。可以通過自動發現來實現，如果是人來維護，基本上不可能。

套路 4：不要太迷信自動發現

自動發現在一定成都上能降低維護的成本和代價，但我不迷信這個能力。一則自動發現的能力一定有需要人工介入的過程，比如說網卡速率的自動發現，出現異常的時候，肯定不能進入 CMDB; 其次自動發現在某種場景是不能直接生效的，舉個例子，比如說某個機器內的進程和端口信息需要做自動監控，此時如果通過自動發現來實現主機上的進程和端口信息維護 (其實簡單)，但這個就需要監控系統適應變更期內進程被暫停的情況，暫停導致機器的進程信息自動發現不全。

仔細思考過自動發現和人工維護的邊界?

***、涉及到資源狀態的變更劃分，其實都應該需要人為參與的。比如說 IP/ 服務器資源從資源池進出的過程; 狀態的變更會涉及到監控策略自動變化的。從狀態這個維度進去，很容易找到人工和自動的邊界，而非狀態屬性的填充則無所謂了。

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

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

套路 5：CMDB 要領導參與，團隊理解一致

領導非常重要，領導參與加上團隊的一致理解，這個 CMDB 不成功都難。很多 CMDB 項目的失敗，不是技術層面上導致的，而是和人有關。

說到一致理解，我覺得 CMDB 的概念、模型、流程、場景、實施方法要足夠的簡單。CMDB 的導入 *** 開始能帶一個場景進去，無論是對事件的支撐、還是對監控的支撐。

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

在 CMDB 系統中其實有很深的層次，云計算的概念層次就是 CMDB 的模型層次。在你構建模型的時候也需要構建這樣的一個分層能力，這個能力劃分開來之后，對持續部署的影響也是在的。我們的實踐檢驗出來是持續部署標準化的規范也需要這樣的分層思路，越界導致系統管理不清楚，監控也是如此!

有一點我沒想清楚的是，PaaS 的資源到底是應用附屬資源管理，還是作為獨立資源管理? 特別是公有云的模式下。

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

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

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

關于“CMDB 的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

向 AI 問一下細節

丸趣 TV 網 – 提供最優質的資源集合！