內容來源：2018年2月5日，優維科技CEO王金銀在《打破當代CMDB模型應有局面之道——第01期》中發表《新一代CMDB模型構建手冊》的演講分享。 IT大師作為獨家視頻合作伙伴，表示是經過主辦方和主講人審核授權后發布的。
閱讀字數：3087|8分鐘閱讀
概括
明天給大家分享的主題是新一代CMDB模型構建手冊，主要分為四個部分。
困境：當前CMDB模型面臨的普遍困境
前期很多CMDB建設都是倉促完成的，但是后期的維護逐漸被開發、運維等角色拋棄，變成了廢墟。 究其原因，一部分是制度本身的各種激勵因素，但更多的是方法論的問題。 我一直認為我找到了構建資源維護的流程和場景的強大驅動力，雖然這都是我自己的一廂情愿。
從常規部門的角度來看，數據中心的基礎設施部門負責CMDB所觸及的配置建設和管理，而資源部門根本不關心（也很難關心）與資源相關的底層應用。 整個問題似乎陷入了懸而未決的西街。
那么業界明天的CMDB模式存在哪些問題呢？ 可以從什么角度來拆解和分析這個問題呢？
破局：構建CMDB模型的正確思路
這里我更提倡分層CMDB建設，業務層和資源層CMDB分開建設，但一定要以應用CMDB建設為主，逆向建立資源層CMDB建設。
但想法就是想法。 從實際業務場景出發，如何將真實的化學世界精準映射到模型世界？
我們應該如何改進匹配所有實際場景的模型？ 您是否也認為CMDB的模型設計就像數據庫表的設計一樣簡單？ 基于新思路推導出來的CMDB模型與過去的CMDB模型有哪些區別？ 造成這一變化的原因是什么？
體系：模型標準框架
CMDB是一個IT資源管理系統，可以有效支持和反映應用程序運行所占用的資源。 應用占用的服務器是一個資源，占用的顯存是一個資源，占用的存儲是一個資源，占用的負載均衡器是一個資源。
但一定要注意vmware虛擬化物理機教程，這個資源更多地表現為前端服務，比如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流程提供數據支撐服務。
第二個是以執行為導向的流程。 整個端到端的IT交付流程需要完整的元數據，尤其是應用層面的元數據。
兩層CMDB，建立不同的管理視角
CMDB架構分為基礎資源層架構和應用資源層架構。 應用層的資源框架以應用為中心整合相關資源。 資源及其資源之間的關系稱為拓撲（應用拓撲、物理拓撲）。 資源管理有兩種形式：手動維護和手動發現。 該過程是一個復雜的場景和手動維護的手段。
克山CMDB基礎建設規則
1. 專為IaaS和PaaS而設計，以便管理所有底層資源。
2、狀態控制是通過運維過程手動完成的。
3、CI的維護應采用人工深度檢測，而不是人工維護。
4、資源信息必須能夠為底層應用提供服務。
5、必須滿足基礎資源的CI管理需求。
CMDB構建原理應用
1. 提供統一的應用元數據管理能力，無論應用類型如何。
2、核心需求是應用生命周期管理。
3. 關注應用而不是基礎資源。
4、從應用資源的角度與IT資源建立靈活的關系。
5、為應用資源、動作、狀態的統一管理提供支持。
6.基于統一的基礎資源層CMDB。
7、核心場景是持續交付。
CMDB模型分層理解的應用
應用CMDB是一個完整的面向資源的描述。 應用資源分為應用部署資源、服務資源和動作資源。
部署資源是應用程序部署所依賴的資源，通常也稱為本地資源，例如主機、程序包等。
服務資源是應用程序依賴的資源，通常被稱為附加資源（來自），例如應用程序的服務套接字、應用程序依賴的PaaS資源、應用程序依賴的應用程序資源等等。
場景動作是附加在資源上的動作描述，是資源的管理方式。
新模型的標準化框架
新一代CMDB資源模型框架
核心原則：只有一種資源可以提供服務，而且還依賴于其關聯的資源，因此必須采用三維模型解決方案。
IaaS 層硬件對象模型
對每一個圖像進行實例化和描述就足夠了，無非就是屬性和關系。
IaaS 層軟件定義的對象模型
如上圖所示，IaaS層軟件定義對象模型分為三個層次。 最內層好像叫依賴操作資源，主機只是其中之一。
這三個級別必須包括服務、組件實例和主機。 服務運行過程中啟動了哪些運行實例，這些實例進程在哪些主機上vmware虛擬化物理機教程，主機的后綴是一個IP列表。
組件實例有兩種，一種是它自己的實例，應用程序包在程序運行時實例化。 一種是依賴實例，就是實例化依賴組件。
自有服務是自啟動的服務對外暴露的形式。 依賴服務是指在運行時關聯的服務。
該模型的表達與PaaS層對象的表達類似。
PaaS層對象模型的核心概念
需要深入理解服務、實例、主機之間的層次關系，準確表達組件和集群之間的區別，比如Mysql組件和Mysql集群。
應用層對象模型核心概念
應用層對象還應對服務、實例、主機之間的層次關系有深入的理解，并準確地表達出來。