基于對CMDB的使用，我們又有了新的理解，當然這都是伴隨著收益和痛點而來的。正所謂痛并快樂著，我們最終還是要量力而行。

圖片

多模型管理

CMDB得益于其多模型管理能力，這使得它能夠高效地處理各種技術資產。

我們在CMDB多模型探索過程中，從各個團隊的需求出發，提出了以下幾個模型：

• 「主機模型」：管理各種服務器業務IP，確保每個主機的配置和狀態都清晰可見。
• 「物理機模型」：專注于實際的物理服務器，跟蹤其位置、規格和維護記錄。
• 「應用清單模型」：記錄所有已部署的應用程序及其版本、依賴關系等詳細信息。
• 「Git工程模型」：通過Git進行版本控制，管理代碼庫，確保代碼的每一次變更都可追溯。
• 「證書模型」：管理SSL/TLS證書等安全證書，確保其有效性和合規性。
• 「安全IP黑白名單」：定義允許或阻止的IP地址，增強網絡安全防護。
• 「中間件模型」：系統架構中的中間件類型、集群部署方式等分別定義。

通過這些模型，CMDB能夠為不同部門提供一個全面、準確的技術資產視圖。

另外，模型之前還存在一定的關聯關系，可以讓我們更好的對資產進行關聯查詢：

• 主機模型-物理機模型
• 主機模型-應用清單模型
• 證書模型-應用清單模型
• 中間件模型-應用清單模型
• 等等

應用場景

無模型不場景，模型都是為場景服務的，只有在場景驅動下數據資產才會更好的流動起來。

• 「基礎設施生命周期」：從采購到退役，CMDB全程管理硬件和軟件的生命周期，確保資產的高效利用。
• 「應用系統生命周期（類ALM）」：支持應用程序的開發、測試和維護，促進敏捷開發和持續集成。
• 「證書生命周期」：自動化管理證書的申請、續訂和吊銷，減少安全風險。
• 「系統級流水線」：通過CI/CD管道實現自動化部署，提高軟件交付速度。
• 「DevOps級流水線」：支持DevOps實踐，促進開發與運維的緊密合作。
• 「研發效能統計」：提供研發團隊的效率和生產力指標，助力持續改進。
• 「安全級管控」：確保安全策略和合規性要求的貫徹執行，保護組織免受威脅。

痛點

盡管CMDB具有諸多優勢，但在實際應用中仍面臨一些挑戰：

• 「多部門、多數據來源」：數據的準確性和及時性難以保證，尤其是在多部門協作時。
• 「依賴各團隊治理」：缺乏統一的流程和制度規范，導致數據管理不一致。
• 「缺乏環境、灰度級別場景與技術架構的聯動」：在不同環境或灰度發布場景中，技術架構的集成和聯動不足。

總結

CMDB并非孤立存在，它需要與IT服務管理（ITSM）工具緊密集成，以支持工單審批和流程管理。通過優化流程、架構和場景的依賴關系，可以顯著提高CMDB中資產數據的準確性。然而，隨著業務場景的日益復雜，CMDB的局限性也愈發明顯，需要不斷改進和創新以適應新的需求。