在過去5年，嘉為藍鲸研發運維營運一體化方案已經在近300家企業中落地。企業類型涵蓋了傳統的制造、能源，也有網際網路性質的網際網路金融、遊戲。那麼，CMDB作為研運一體化方案中非常重要和基礎的一環，它的設計理念應該是怎樣的？
本文主要是從三個方面（Why、What、How）對應用CMDB的架構設計進行闡述。暫不涉及到維護營運等與人、流程相關的内容。
CMDB為什麼要以應用為中心（Why）
在手工運維時代， CMDB主要服務于ITSM流程。此時CMDB納管的是IT資産（比如鞋套機這種機房設施也在納管對象中），在CMDB建設之初，其中的資料與線上環境的資料還比較一緻，但CMDB的消費場景十分有限，其價值及維護願望并不高，漸漸的CMDB中的資料與線上環境的資料偏差就越來越大了，漸漸淪落為一個邊緣系統，甚至是一個運維負擔。
在自動化運維時代，CMDB主要服務于各個運維系統如自動釋出、監控、智能運維等。此時CMDB納管的是IT資源（這裡我們進一步縮小IT資源的概念為支撐應用系統的各種IT軟硬體資源，如資料庫、中間件、伺服器、機櫃等，此時并不會包括鞋套機）。随着IT運維系統和工具越來越多，CMDB中的資料作用越來越大，服務的運維消費場景也越來越豐富，此時CMDB的價值及維護訴求非常高。
是以，自動化運維、資料化運維催生出了新一代的CMDB。
不同的運維場景對CMDB有不同的消費訴求，但我們知道CMDB的落地一定不可以追求大而全，否則會把自己做死。那CMDB的邊界是什麼呢，或者說我們應該以什麼為中心來建設CMDB呢？
答案當然是以應用為中心來建設CMDB！
随着數字化轉型的發展，線下業務逐漸線上化，應用數量與日俱增，應用架構也趨于多樣化和複雜化，而 IT基礎設施逐漸雲化标準化并趨于穩定，是以運維的重心和價值漸漸聚焦于應用。另一方面，運維的發展必然走向資料化、智能化，如容量管理、根因定位、故障預測、輔助營運等，這些運維進階場景更多的也都指向了應用。是以，我們認為，CMDB應當以應用為中心進行設計，以滿足各種運維場景對CMDB的消費需求。
什麼是以應用為中心（What）
以應用為中心的CMDB，需要從以下兩個點出發：
從應用的定義出發
這裡的應用，是應用系統的簡稱，指對外提供特定業務服務的一組軟硬體資源的有機組合。對外提供特定業務服務，意味着要從業務的視角；軟硬體資源，對應着應用的組成實體；有機組合，則說明了實體之間存在着一定的關系。那麼，CMDB既是以應用為中心，CMDB的能力需要能支撐起應用的這些特性。
從應用的運維場景對CMDB的消費需求出發
頂尖網際網路公司的經驗告訴我們，應用運維的未來是資料化運維、智能運維、輔助營運。而對于傳統企業和正在轉型中的企業來說，則要立足現在、謀劃未來，建設一個适用于多種架構的、具備先進性基因的、可持續發展的應用運維平台：
CMDB是應用運維平台的基石，上層的應用部署管理場景，需要我們維護好應用拓撲、應用部署執行個體、以及應用與制品之間的關系才能做到持續快速傳遞。
應用運維管理，需要我們維護好應用基本資訊、應用與基礎資源之間的關系才能做到應用次元的監控和操作自動化。
應用性能管理，則需要将應用的調用關系和應用拓撲、部署資源結合起來，才能做到更深層次的分析，并且往容量管理、根因定位等智能化方向發展。
是以在各行各業的應用運維實踐中深化運維場景，并且了解場景對配置資訊的要求，也是CMDB設計的重要依據。
如何設計以應用為中心的CMDB（How）
應用CMDB中應該有哪些關鍵的資料
前面我們提到，應用CMDB需要從業務視角對一個應用進行描述，那麼應用CMDB應該包含以下資料類型：
- 應用資源管理，包括應用的拓撲資訊，應用的基本資訊如程式包目錄、啟停腳本等，應用的部署資訊如叢集、環境、主機、程序等，以及應用與應用之間、應用與基礎資源之間的調用資訊等。
- 基礎資源管理，應用是由各種基礎資源構成的，需要支援各種基礎資源的配置資訊管理。
- 應用制品管理，一般而言，CMDB中不會納管制品，但需要支援與外部制品庫對接，對制品與應用之間的關系進行管理。
應用CMDB架構的十大關鍵設計要素
以應用為中心的CMDB想要在多樣化的應用架構環境中落地，并滿足各種運維場景的消費需求，設計時需要涵蓋以下十個關鍵要素：
1.以應用為中心
CMDB需要以應用作為基本單元，而不是以資源對象、資料中心來進行劃分。比如CMDB中的第一層級，應該是OA系統、電子商城、ERP系統等應用，而不是Windows伺服器、資料庫主機或者北京資料中心、廣州資料中心。
2.使用服務樹拓撲管理應用
服務樹是對應用系統所提供的業務功能進行領域的劃分。一般不要超過3層：
例如：
一般一個企業隻定義一個服務樹拓撲模闆，所有應用的管理都沿用這個拓撲模闆。
3.拓撲設計要同時支援傳統應用架構和網際網路應用架構
傳統應用架構有幾個特點，一是應用并未把子產品劃得很細，二是應用往往有獨享的資料庫、消息隊列等基礎資源，三是應用的架構相對比較簡單，有時由兩台Weblogic伺服器+兩台Oracle伺服器就組成了整個應用系統。比如某保險集團的DBS系統，在三層服務樹拓撲下，可以按照以下方式進行劃分（此時子產品是從基礎資源的次元進行劃分）：
4.支援多環境管理
應用是部署在不同環境中的，我們将應用在不同環境中的資訊管理起來。
5.支援多叢集管理
這裡的叢集指的是分布式的叢集。每個叢集都對外提供相同的業務服務，叢集中包含着一個或多個子產品。叢集一般在網際網路應用架構下出現的比較多。
6.支援子產品與子產品之間的調用關系管理
7.支援子產品與制品（程式包、配置檔案、SQL檔案、鏡像）之間的關聯關系管理
8.支援對基礎資源的模型自定義和執行個體管理
可自定義模型及模型屬性：
執行個體管理：
9.支援子產品與基礎資源之間的調用關系管理
10.支援程序管理，滿足傳統非标準化程序管理的需求
子產品部署後将會執行個體化程序，我們稱之為服務程序，是一個應用系統非常關鍵的實體資源。在網際網路架構下，程序相對比較标準，各台主機上的程序執行個體配置資訊（端口、目錄、啟停腳本等）是一緻的。
在傳統應用架構下，程序可能并不标準，程序執行個體的配置資訊在不同主機上可能是不一緻的，甚至同一個主機上可能運作了該子產品的兩個程序執行個體。此時，需要應用CMDB能夠提供靈活的程序管理能力來适配傳統架構和網際網路架構的需求。
總結
以應用為中心的CMDB，既要支撐得起傳統的單體、SOA應用架構，也要支撐越來越廣泛的分布式、微服務和雲原生應用架構，既要滿足目前自動化運維的需求，也要為資料化、智能化運維打下基礎，既要以應用為中心，也要兼顧基礎架構運維的需求。
企業可以參考上述的CMDB十大設計要素，并結合企業自身的業務特點建設CMDB，保證CMDB中的資料都是“活”的資料，才能讓CMDB保持旺盛的活力，真正成為IT研發運維營運的基石。