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

圖片

多模型管理

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

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

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

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

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

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

應用場景

無模型不場景，模型都是為場景服務的，只有在場景驅(qū)動下數(shù)據(jù)資產(chǎn)才會更好的流動起來。

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

痛點

盡管CMDB具有諸多優(yōu)勢，但在實際應用中仍面臨一些挑戰(zhàn)：

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

總結

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