內容來源：2018年2月5日，優維科技CEO王津銀在“當代CMDB模型應有的破局之道 - EasyTalk - 01期 ”進行《新一代CMDB模型構建指南》演講分享。IT 大咖說（ID:itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：3087 | 8分鐘閱讀
摘要
今天我為大家帶來的分享主題是新一代CMDB模型的構建指南，主要分為四大部分。
困境：當前CMDB模型面臨的普遍困境
很多CMDB建設前期做得風風火火，而後期維護漸漸被開發、運維等角色拋棄，成為廢墟。究其原因，部分是系統本身的各種因素阻礙，但更多是方法論問題，總以為找到了很強的驅動力來建設資源維護的流程和場景，其實都是自己的一廂情願。
從常規部門的角度看，資料中心的基礎設施部門統攬 CMDB 所觸及的配置建設和管理，但是資源部門根本不關心（也無法關心）資源所關聯的上層應用。整個問題看似走進了無解的衚衕。
那麼行業今天的CMDB模型問題點究竟在哪？這些問題可以從哪些視角去拆解分析？
破局：構建CMDB模型的正確思路
在這裡我比較主張分層進行 CMDB 建設，業務和資源層 CMDB 分開建設，但一定要以應用的 CMDB 建設為主，並倒推資源層的 CMDB 建設完善。
但思路歸思路，從實際的業務場景出發，真實存在的物理世界又如何精確對映到模型世界？
我們又該如何構建匹配一切實際場景的模型，是不是你也認為CMDB的模型設計就是和設計資料庫表一樣簡單？基於新思路構建推演的CMDB模型和過去的CMDB模型到底有什麼差異？做這樣改變的原因是什麼？
體系：模型標準框架
CMDB即IT資源管理系統，能有效支撐反應一個應用執行的佔用資源。應用佔用的伺服器是一種資源、佔用的記憶體是一種資源、佔用的儲存是一種資源、佔用的負載均衡是一種資源。
但大家一定要注意，這個資源更多是以一種後端服務形式出現的，比如說IaaS 服務或者是 PaaS 服務。
本次分享會提出IaaS、PaaS和應用層的標準模型框架。這個框架改變了過去簡單二維表的描述，真實構建反映一個符合現當下絕大多數IT體系背景的CMDB模型到底應該是什麼樣。
論證：模型的應用場景推演
當然，基於構建模型，我們還會進行各個CMDB場景的推演，從而驗證新CMDB模型的適應性。
而且本次提出的運維管理新思維經過眾多專案落地實踐證明切實有效，給過去的很多未解問題提供瞭解決方案。貼近業務的資源，驅動力最強。
當前CMDB模型面臨的問題
當前CMDB的模型問題
當今很多CMDB的模型還是聚焦在底層資源。這個底層資源指的一部分是IaaS層的資源管理，另一部分是PaaS層中介軟體的資源管理。到上層應用這塊，其實它的模型表述特別簡單，只有一些應用的基本資訊。
第二個要講的問題是無應用視角。今天我們建立管理了這麼多資源物件，但不知道是給誰用的，其實真正的著力點是應用。這個我將其總結為無應用層的理解力。
模型的動態性不強。每個模型物件調整它的屬性或者關係的時候，在傳統資料庫裡技術端的特點帶來的代價特別高。我把模型的動態性抽象成兩個維度，第一是模型物件之間在CI級別的動態性，第二個就是例項級。
第四個問題是場景過渡的設計。我認為場景是可以預設的，但是細粒度的模型會帶來很大的管理負擔。有時候會把場景考慮得過於複雜，導致這裡面的模型管理後續負擔特別重。從簡到繁很容易，但是從繁到簡很難。
技術限制想象力。受CMDB平臺技術本身的能力限制，導致無法擴充套件這個模型。
欠缺IT架構思考力。我要講的是從業務架構到應用架構再基礎架構。業務架構中還包含了基礎設施架構和資料架構。弄清楚這三者的關係後，就能表達出在每一層架構上所帶來的本質上的關係連線到底是什麼。
CMDB系統截圖
構建CMDB模型的正確思路
新一代CMDB到底新在哪兒？
新思維：突破配置管理的認知，導致邊界不清。配置往IT資源方向轉變。
新方法：自上而下的推動CMDB落地，而不是自下而上。
新模型：模型重構，傳統的關係模型無法滿足。
新技術：使用新的技術，新的功能架構，重新定義功能邊界。
CMDB後設資料的兩類用途
CMDB模型最終是要例項化資料和關係的，正確的模型構建可以為多變的場景提供資料基礎。
第一個是面向管理層的ITSM流程。在很多傳統企業裡面，CMDB還是要為ITSM的流程做好資料支撐服務。
第二個是面向執行層的DevOps過程。端到端整個IT交付過程需要完整的後設資料，特別是應用層面的後設資料。
CMDB架構分基礎資源層架構和應用資源層架構。應用層資源架構把相關的資源以應用為中心實現資源整合。資源及其資源的關係稱之為拓撲（應用拓撲、物理拓撲），資源管理方式有人工維護和自動發現兩種方式，流程是人工維護的一種複雜場景和手段。
基礎CMDB建設五原則
1、面向IaaS和PaaS設計，能夠管理底層的一切資源。
2、狀態控制藉助運維流程自動化完成。
3、CI的維護要深度使用自動發現，而不是人工維護。
4、資源資訊必須能為上層應用提供服務。
5、必須滿足基礎資源的CI管理需要。
應用CMDB建設氣原則
1、提供統一的應用後設資料管理能力，和應用型別無關。
2、核心訴求是應用生命週期管理。
3、以應用為中心，而非基礎資源為中心。
4、從應用資源的角度構建起與IT資源的彈性關係。
5、為應用資源、動作、狀態的統一管理提供支撐。
6、以統一的基礎資源層CMDB作為基礎。
7、核心場景就是持續交付。
應用CMDB模型層次化理解
應用CMDB是面向資源的完整描述，應用的資源分成應用的部署資源、服務資源和動作資源。
部署資源是一次應用部署所依賴的資源，一般又稱本地資源，比如說主機Host、程式包等等。
服務資源是應用執行依賴的資源，一般有稱之為附加資源（來自於12factor），比如說應用的服務介面、應用依賴的PaaS資源、應用依賴的應用資源等等。
場景動作是資源其上附加的動作描述，是資源的管理方法。
新模型的標準化框架
新一代CMDB的資源模型框架
核心準則：一個資源能夠提供服務，還要看它關聯的資源，因此必須採用立體化模型方案。
IaaS層硬體物件模型
針對每一個象例項化描述它們就可以了，無非就是屬性和關係。
IaaS層軟體定義物件模型
如上圖所示，把IaaS層軟體定義物件模型整理成三個層次。最底下的層次其實應該叫做依賴的執行資源，主機只是其中的一種。
這三個層次中必須要包含服務、元件例項和主機。服務執行過程中起了哪些執行例項、這些例項程式在哪些主機上，主機延伸出來就是IP列表。
元件例項有兩種，一種是自有例項，當程式執行的時候需要的應用包例項化。一種是依賴例項，就是將依賴元件例項化。
自有服務是自己啟動的服務對外提供的時候以怎樣的方式暴露出去。依賴服務則是執行時還關聯了哪些服務。
這個模型表達方法和PaaS層物件比較類似。
PaaS層物件模型核心概念
一定要深刻理解服務、例項和主機之間的層次關係，並且要精確表達注意元件和叢集的區別，例如Mysql元件和Mysql叢集。
應用層物件模型核心概念
應用層物件也要深刻理解服務、例項和主機之間的層次關係，並且要精確表達。
今天的分享就到這裡，謝謝大家！
Q&A
Q：虛擬化的資源怎麼描述呢？
A：我們今天把虛擬化和物理機的資源物件疊加在一起管理。在主機物件表裡增加了一個欄位，就所屬母機，僅此一個維度的區別。
Q：像磁碟、網路這些有沒有介紹？
A：我把磁碟、網路歸納到底層IaaS的一部分。對於IaaS那部分物件CI的描述其實也比較簡單。比如硬碟就歸類為硬碟大小、分類資訊等等，只是一些硬體資訊而已，沒有特殊的。網路這塊要分開，要分為各種網路，像接入、匯聚跟核心可以歸為一類的網路裝置，防火牆則要歸為另外一類。網路方面比較需注意資源資訊。
Q：應用如何自動發現？資源自動發現能詳細介紹一下嗎？
A：應用層要真正想做到自動發現，肯定還需要依賴規則庫。系統、子系統、應用元件，這三個名稱其實是一個邏輯的概念，只有人才能準確地知道。如果要把機器執行的例項資訊和我們大腦中所記錄理解的應用元件關聯起來，這就需要依賴規則了。所謂的規則無非就是根據例項所掃描上來的一些資訊去整理規則。底層的資源自動發現，有介面就寫介面，有命令就跑命令，沒什麼特別的。因為資源層自動發現的複雜度不在於它的技術，而在於它本身基礎設施的複雜度