1、CMDB模型設計這幾年以來，CMDB的模型每隔段時間在腦子里就會折騰一番，近期有一點小小突破，一直沒有時間跟心情沉下來記錄，到現在我仍然認為目前的CMDB的產品層的設計與實施層的建模思想都存在問題，可惜沒有資源去驗證自已的整個想法，我設計的模型如果有任何個人或公司在此之上做產品實現，我都是樂意的，甚至可以考慮提供免費的咨詢支持，一個想法不斷沖擊你的大腦，你卻無法看到它的實現與驗證，這實在是一件讓人沮喪的事情。將這篇文章的標題寫成CMDB模型設計僅僅是為了符合大家的認知與興趣，我對CMDB這個狹義的名稱越來越不感冒了，因為它與一個完整的ITSM系統有著某種二元對立之嫌，同時它又讓大家忘記CMS是

2、什么，所以接下來我講的模型其實有兩個層面，一個是基于CI級的模型，一個基于服務的模型，前者面對服務對象，后者面向服務本身，如果這兩個模型是穩健的，它將一個ITSM的系統架構做了最底層的約束，或者說形成了這個ITSM系統的骨架或靈魂，基于這兩個模型可以做許多延伸與分析，就我個人而言，我覺得它有一定的突破意義，對于外界或行業方面，只能在未來觀察了。首先要介紹的CI本身的構建模型，見下圖與面向對象的思想一樣，用類的方式來構建CI，一個類有二個方面的特性，它與其它的類有什么樣的關系，它有哪一些屬性，首先類、關系、屬性都需要結構化，且不能強制做分層數，即你不能要求CI分類全部要三層，你也不能要求關系只能

3、做一層，這樣等于形成幾個樹狀的結構，以類為中心連接點，它可以與其它三個樹形中的任何節點發生關系，擁有一個節點，則擁有其所有子節點，這會極大的靈活日后的維護，下面分別講解一下這幾個緯度的意義：1. 分類：即把IT架構中所有的元素進行分類別名。在這一個數據集中，只記錄存著分類本身的樹形結構，或者說是所有服務對象的分類結構，所以此處是不會出現虛擬CI的概念的，即類似組織、人員、地點、服務這類信息是不會成為某一種分類的，所以在這個模型之中，是建立IT架構本身的投影，盡可能真實的表達出真實架構的情況，在分類方面可以利用現有的資產清單，并做一次所有部門的服務對象調查，這樣匯總后，做一次分析整理，做到完全窮

4、盡，相互獨立。理論上，如果兩個分類它的關系、屬性、動作全部一樣，則不需要分成兩個類，但在實施時我發現，不要吝嗇分類的設計，許多人覺得屬性一樣時，就合并類，比如將刀片、PC服務器、小型機都置成一個類，叫服務器，這其實并不合適，因為問題是出在了屬性設計上，而不出在類上，你不能因為A病了，讓B去吃藥。類能在、模型表達、動作、關系、統計分析上帶無可比擬的方便性，它可以讓你的一切都只需要基于類級做控制即可，如果只是在類上加一個屬性叫“服務器類型”，這樣的結果是你的系統功能變得非常復雜，你可能需要實現根據屬性去過濾你的模型，需要考慮屬性去計算業務影響，以及你的所有的報表統計。類的數據是整個CMDB的基礎的

5、基礎，一定要嚴格做公司級的評審，當我們定清楚所有類的屬性、關系、動作、生命周期時（注生命周期需要根據類去做不同的定義設計），事實上，我們就定義了變更的最小范圍。為了讓最終模型美觀，可以根據類來設置不同的圖例圖片，來代表這個類，這樣在模型時就可以顯示依賴這個圖片來表達顯示。2. 關系：在以前我一直希望抽象最精簡的關系類型出來，慢慢的我感覺到這個路是不太可行的，可能有更簡潔的方法去作業，我們在幫助一個客戶實現CMDB時，我們可能根本不需要去提前幫客戶抽象有哪幾種關系類型，原因很簡單，當我們定義出所有的類后，只要我們做一件事情，問問每一個類與其它所有的類會有怎樣的關系，當我們把這個數據調查到之后，就

6、會得到一個CMDB的藍圖，這個藍圖就是這個公司自已的CMDB模型，這樣當在構建CI時，根本不需要用戶再去決定填哪一種關系，因為關系是由類決定的，不是由CI決定的，當用戶知道這個CI跟哪一個CI有關系時，模型層會自動添加上正確的關系類型，每個類跟哪一些類有怎樣的關系，不能跟哪一些類有哪一些關系就在系統層做了控制，也就是說用戶永遠無法構建出錯誤的模型，他只能構建出錯誤的數據，每一個關系的數據，最后在實體CI填充時，類似屬性一樣，可以填寫一個值，這個值即是“關系說明”，我們以前在模型層只畫一根線，表達兩者有一種連接關系，這種表達有時是不夠的，尤其在應用程序之間的關系上，比如你在模型上看兩個應用程序有

7、依賴關系，當你鼠標停留在此關系上時，系統會調用關系說明的值，顯示出“A程序需要每隔1小時調取B程序的庫存數據”。類與類之間的關系藍圖是比較花氣力一件事，同時它又非常重要，同樣需要公司級的嚴格評審，一旦通過后，CMDB的模型就穩固了。關系的數據越細，日后的影響分析計算與模型表達就越精準，CMDB在實施時，以往存在的一個問題是，我們代替太多業務部門做太多的思考與決定了，當我們清楚每一個類時，每一個類與其它類有怎樣的關系，其實業務部門最清楚，可以用一個很簡單的調查表就實現盤點與收集，然后匯總評審，我發現這項工作太少人做了，其實只需要有幾家公司認真去做一次，就完全可以總結出一個整個IT行業的關系藍圖，

8、此時就可以做產品數據預制了。為了最終模型的美觀，還可以定義不同的關系類型的線條粗細、顏色、箭頭方向。3. 屬性：屬性與以前的CMDB設計基本類似，不同之處在于，屬性需要實現結構化，結構化的好處在于更加容易實現與類的關系建構，當一個類有一個屬性子集（節點）時，自動擁有其下所有的屬性，日后這個子集增加屬性時，與它有關系的所有的類會自動增加此屬性，同時更加容易讓別人理解一個類的屬性信息情況，單一的平面直列出數十個屬性，會讓人抓不住重點，以前如果要實現同性質的屬性集中顯示又需要進行界面定制開發，這成了一個兩難的局面，一個簡單些的邏輯是，將屬性進行結構化，每一個節點形成一個單獨的標簽頁，一個CI分類有幾

9、個節點就有幾個標簽頁，同時每個標簽頁的屬性顯示可以做排序設定，這樣可以達到既無須定制開發，又可以實現屬性有效顯示的效果。屬性的填寫方式需要進行控制，它如果是由用戶選擇，則需要定義它的數據源，比如地點信息，或者狀態，如果是手工輸入，則需要提供填寫示例或說明的欄位，如果數值型，則需要考慮提供單位的選取等等，目前由于屬性的值基本都是納入了靜態的信息，而且許多是不可變更的，在未來要考慮屬性值的數據接入需要動態，比如象CPU資源等，這樣就真正可以豐富在一個平臺掌握架構的狀況，同時可以基于一個平臺來做性能分析。對于屬性的定義，雖然長遠上我感覺它過于平面單一，但短期內仍然沒有更好的解決方案，什么是屬性，到底

10、是將一個對象的不同的特性作為它的屬性，還是將這個對象的可以配置改變的項次作為屬性呢，又還是屬性只是作為一個描述信息一樣，好比字典里的每一個字，將它們組裝成一句話、一篇文章，來描述說明一個對象呢，直覺上，我覺得是第二種，但如果這樣思考的話，整個CMDB的理解與設計及定位，需要完全進行解構，那也就是我以前所思考的一種終極的模型，我沒有繼續按那種路線思考下去，除非有哪一天有一家公司會專業做這個，請我去做專門研究才有可能了。3. 業務：在以前實施CMDB時，我們會把CI的屬性與關系一次性構建出來，按現在模型的思路，則需要進行分步作業，先不構建具體的CI，而是先定義業務，然后再定義IT服務，按目前中國大

11、多數的公司情況，估計只需要定義IT服務即可，我們要理解、規劃、定義我們到底有多少個IT服務在作業，把它們的層次結構刻畫出來，這就構建成了所謂的業務架構，有了這個業務架構之后，再來梳理IT世界，也就是CMDB本身的CI信息，構建CI信息同樣需要分步走，先不要關心屬性，先關心三個問題：我們有多少個CI？每一個CI跟哪一些CI有什么關系？每一個CI屬于哪一個IT服務？，回答了這三個問題，我們就完成了CMDB所有模型的構建，而且把業務架構與IT架構做了對接，此時一棟大廈已經建立完成了，剩下的只是精裝修了，也就是把每一個CI的屬性進行填充，這種思路有些像先搭建出整個骨架，不把屬性收集放在前面的原因是，發

12、起屬性的采集是難度最大的，一旦收集了屬性，變更必然跟進，不然數據會失真，這樣調整數據的難度很大，我們先只花很小的力氣把整個CMDB的效果展現出來，不過這一關就不許展開屬性的填充工作，其實我們會發現最后對CMDB爭議最大的往往是在這一個環節，要把這一個環節做得專業與嚴謹些，此時的模型效果會全部出來了，每一個系統的模型，甚至CIO看的公司級的模型全部可以展現，這會建立一個很有效的正面剌激，為后面收集屬性建立良好的決策基礎，把眉毛胡子一把抓最后很容易出問題，而且出問題難以調整，切記這一點：業務為先IT為后，關系為先屬性為后。在產品設計時，需要把基礎數據維護與基礎數據間的關系設置一分為二，以方便相互獨

13、立維護作業與權限控制，所以這里應該會產生7個功能點，必須可以由最終用戶來實現CMDB的基礎數據維護與發展。需要依賴開發力量來增加類與屬性或關系，這是一種僵化的系統設計。基于上面的模型，當一個CI構建時，它會繼續這個類的所有關系與屬性，在下圖中是CI實例的模型示意。根據前面的模型，新創建一個CI時，首先要決定它是哪一個類，確定后，就自動繼承這個類所有關系、屬性、動作，需要提供一些比較方便的功能，比如一個CI構建時可以進行克隆另一個CI的數據，如果日后技術上做一些發展，實現在圖例操作，即直接在模型圖上編輯關系與屬性，這些都會帶來一些全然不同的操作體驗。當所有CI構建完成后，此時真正意義上的CMDB

14、已經構建完成，此時的CMDB的數據完全是IT架構的數據，這些CI的關系組織在一起，會形成一張網，沒有邊緣也沒有盡頭，此時做影響分析，是基于IT層的，如果算法正確，我們會發現當CI發生故障時，它的故障路線是如何一步步發展的，當你知道IT架構的CI哪一些存在問題，又知道這些CI是從屬于哪一些IT服務的，業務影響的分析結果就顯示易見了，剩下的只是展示的問題，因為數據結果已然存在，模型展示只是數據的表達。對于一個服務而言，需要明確四個方面的問題，服務的對象是哪一些CI，服務的主體是哪一些單位或個人，服務的體制是哪一些單位與個人，這個服務到底要做些什么。同樣的這會形成一個四面魔方，每一個面都由一個樹形結

15、構所構成，由服務對象的任何一個節點和其它三個面做任意節點連接，見下圖。說明：1. 服務對象：無論是業務服務還是IT服務，都是面向服務，我一直認為在IT服務或IT管理行業中說的業務服務是一種狹義的業務服務，業務服務與IT服務的區別不在于是不是面向服務，而在于IT服務將一切分成IT與非IT的，業務服務將一切分成業務與非業務的，由此帶來范圍與視角的絕大不同，要定義清楚什么是業務，每一個業務環節中哪一是業務的作業內容，哪一些是非作業需要服務的內容，將業務的重點放在核心上，剩余的外包一切，非業務的就是業務服務，業務服務可以包括物業服務、餐飲服務、IT服務等等，我相信業務服務不是IT行業可以玩得轉的，而需

16、要在目前的企業管理運營層面發生革命性的轉折才有可能。但對于模型層面而言，兩者其實并無二致，無論是基于業務服務還是IT服務，上述的模型均可容納，我認可服務可以分解的思路，一個服務可能由若干個子服務構成，但我不認同在CMDB模型層對CI進行層層分解的思路，在CMDB的世界里是沒有聚合之物的，一切只是單一對象，如果把人比作CI，那么我認為家庭不應該是CI，你的CMDB模型里不能既有家庭又有個人，這樣的關系構建邏輯就會有問題，當我們定義清楚每個人的關系時，每一個家庭的關系其實就自然出來了，在這里，我們可以把家庭理解成服務，把個人理解成CI，所以在模型設計時，服務的定義與一個服務有哪一些對象的定義，我是

17、不會放到CMDB之中的，而是在ITSM系統之中，也就是虛擬CI解決方式。不管我們是做網絡維護、桌面維護、系統維護，還是物業服務，事實只有我們理清楚對象是什么，我們的服務的灰色地帶才有可能清理清楚，當一個服務沒有獨立的對象支撐時，我認為定義它已經沒有實質意義，就也就是為什么我一直反對將一個應用系統進行的拆分的原因，在實施CMDB時，許多人會把一個系統分解成若干個子功能或子服務，這除了結構好看些外，并沒有會任何好處，反而有壞處，我們要深刻理解軟件即服務的意思，這里面的一個難題在于，我們還沒有找到一個非常穩鍵的概念定義清楚，什么是一個系統。在實際管理中，我們會把許多關系緊密的系統交給一個團隊或一個人

18、管理，然后習慣的叫它XXX系統，其余此時是因為我們在現實業務中沒有定義清楚什么是一個系統，如果我認真審視，我們負責的所有系統清單，我們會發現，其實許多系統只是概念性的聚合之物，它屬于某種業務領域或單元的概念，如果我們不定義清楚什么是一個系統，而用原有的概念去做CMDB的建模時，我們會發現就需要把一個所謂的系統拆成若干個子系統，從而引發建模思想與標準的問題。如果我們足夠聰明，我認為我們是完全可以梳理出一個公司的所有業務及所有IT服務的關系圖的，然后再定義每一個IT服務擁有哪一些對象（CI），此時業務世界與IT世界才真正的結合起來了，此時展現的模型已經超出了CMDB的世界，也就是說我們現在要達到的

19、業務影響分析，是基于ITSM系統的，而不是僅僅基于CMDB的。2. 服務主體：在做業務影響分析時，我們經常想知道到底會引影響哪一些人或部門，事實上服務主體的數據非常重要，我們需要把跟我們服務相關的所有公司的組織與人員數據全部置入ITSM系統之中，這就是我們的客戶數據中心，當們把IT服務與服務主體建立關系時，會通過CI的故障計算出服務的故障，因此會計算出哪一些人員會受影響，需要注意的是，將IT服務與個人數據直接發生關系并不是一種好的方式，因為會帶來維護的極大麻煩（新來一個人，離開一個人，你都需要手工維護更新），最好的方式是通過部門或崗位信息進行互聯，這樣只要維護組織數據的人員保障服務主體的正確就

20、行了。也許有人會問，一個系統的某一個報表模塊只有A部門會用，如要系統功能不往下拆分，那怎么能實現當報表模塊壞時，只有A部門會受影響的結果呢？，答案是，如果在IT架構中，沒有任何一個元素來獨立支撐報表模塊，那么這種故障傳導的結果是不會發生的，因為只要應用程序或數據實體發生問題，會直接導致所有用戶受影響，這種問題也是一個在CMDB實施時常見到的傾向，一切似乎是圍繞著業務影響分析的目的進行的，我的看法是，以目前的CMDB發展情況而言，是無法支撐一個精確的分析結果的，根本原因是一個CI的狀態在分析時只有0與1的取舍，這在客觀上就違背了現實世界的復雜性，用權重百分比之類的做法，也只是在一定程度上緩解這個

21、問題，但因此引發的定義與判斷的成本，甚至要遠遠超過丟掉它，來直接看現實世界的成本，這些做法僅僅是為了滿足不掌握信息的管理者們，實在是無奈之舉，這好比大家都一直覺得在變更管理中，CMDB可以發揮很大的作用一樣，事實上絕大多數變更是根本不需要利用CMDB影響分析的，因為這些提交與分析及實施變更的人是最了解情況的，所以出現的荒唐現象是，當一個變更是要個修改數據庫中的一個客戶數據時，根據現在的業務影響分析是整個公司的業務受到影響，因為整個公司業務中依賴此系統，此系統依賴數據，當領導們審批此變更時，發現這影響不對啊，于是大家細化模型，工程師們花更大的力氣維護數據，但我們一直不敢做一個更簡單決定，讓那些不

22、掌握信息的行政領導們不參與變更審批環節，把一個技術決策扭曲成一個行政決策，除了編制太多的材料以傳遞信息與知識外，還使得各種角色不能歸位去承擔應有的責任。4. 服務體制：要清楚規劃設計出每一個服務的作業體制，即服務經理、一二三線的支持人員，更龐大的服務需要更復雜的體制來應對，要清楚定義是由哪一些角色及人員來完成交付與支持服務，服務體制的數據取自行政組織的數據，行政組織多半以專業為劃分，這樣就形成服務與專業的兩個層面，有的公司會更復雜，會有技能組類似的概念，不管組織數據如何復雜，都需要將這些人員映射到服務體制的某個角色之中，最后一個服務體制中的人員可能會包括多個不同公司的不同崗位的人員。在ITSM

23、系統中，一個明確的服務體制會幫助我們控制權限（無論是工單還是CI）與派單，同時還會幫助我們了解在一個變更時，需要哪一些人員參與，從正常情況來看，一個變更單如果只涉及其服務內部的專屬CI，則變更經理由相應的服務經理擔任，如果變更涉及到的CI上支撐著多個服務時，此時需要進行聯合審批，即通過變更關聯CI的上層所有服務的服務體制來判別。5. 服務目錄：對于服務目錄的理解，我認為許多人其實是似是而非的，就象我以前講的菜單與菜譜的例子一樣，當然這是ITIL理論不清晰所造成的，對于這個問題的理解，如果站在一個專業的IT服務商的角度會相對容易些，菜單其實是服務產品，菜譜其實是服務目錄，客戶需要理解的是菜單，I

24、T服務商需要理解的是服務目錄，服務目錄層層折解下來后，最底層的作業一定是跟CI類對接的，所以其實理論上我們可以定義每一個CI類的動作序列或服務目錄，一個類,或者說一個配置項，可能有怎樣的維護或操作動作，這事實上屬于服務標準化的過程，這也是目前整個IT服務行業最滯后的地方，每一名IT服務人員到底會做哪一些動作，每一種設備對應的維護動作有哪一些，最終每一種維護動作需要做多少次，需要多少時間成本，這對服務分析與服務管理是非常有意義的，它甚至可以解決能力成長與技能提升的問題，如果足夠標準化，最后每一類設備的每一種動作形成一個手冊，一個人是否能維護這一類設備，取決于他是否掌握這段上設備存在的所有動作，如

25、果將一個設備的動作分解決了不同層次，那么一線與二線及三線的職能切分也就清楚了，因為大家的動作范圍不一樣，這又會帶來派單處理的便利性，一個服務的內容有多少，事實上是由這個服務有多少個對象，這個對象有多少動作來決定的，這才是真正的服務目錄。全年下來時，整個IT組織知道了每一種動作的平均時長是多少，全年操作次數是多少，哪一些人做哪一些動作是最多的，可以想象這種層面的分析，完全可以讓我們的管理水平與分析水平發生質的改變。如果日后人類的作業行為更加標準化，這個模型還可以發展，因為動作與關系與屬性其實存在關聯，理論層面則言，一個屬性的改變或一個關系的改變，一定是由于某個動作所導致的，這又會直接引生成新的變

26、更控制思想，更瘋狂的是，任何對象的事件與變更是可預見的，如果抽象出來后，我們還會發現，某一種現象的事件或某一種類型的變更，它一定會由某一種動作來實現完成，此時自動判斷用什么動作來處理事件或變更就成為了可能，但這一步，估計目前是做不到的，需要做全方面的提高后，才能可能成為現實。根據服務模型，當我們真正在做服務作業時，假設一個ITSM系統開始作業，我們轉變一下思路，用面向對象的方式去問問每一個工單，我們會發現事件、問題、變更、發布、監控、備份、災備等等全部是基于對象的，我們在作業時需要思考是與哪一個對象相關，以前我們在填寫單據時，只是寫我們做了什么，而不會說基于哪一個對象，改變這種行為，讓CMDB

27、的數據與流程對接，我們會發生一個廣闊的天地會展現在我們眼前，原來我們的管理模式與服務分析可以有那么大的空間供我們馳騁。下圖模型是一個此思路的表達。有了這幾個模型后，真正把它們實現在ITSM中時，我們只需要兩層監控，一個是監控服務，即我們常態理解的服務臺，接受服務受理，另一層監控是監控IT架構，如果是一個用戶報事件，我們就會知道與他相關的服務會有哪幾個，每一個服務又會有哪一些對象，每個對象又需要是誰負責去管理，如果是一個監控軟件發生告警，我們會知道這個CI是從屬于哪一些服務，它又是誰進行管理。在做業務影響分析時，由于CMDB中的CI關系是網狀的，存在著一個無法截止的問題，所以任何試圖做業務影響分析時，必須先確定分析的范圍或發起點，在展現一個服務的內部結構時，可以通過確定一個服務的所有對象（CI），加上與這些對象存在關系的臨近一層的CI，通過關系數據將它們的圖例組合出來，這個視圖應非常穩固，要找到一個模型排列