CMDB模型設(shè)計(jì)

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

2、什么，所以接下來我講的模型其實(shí)有兩個(gè)層面，一個(gè)是基于CI級(jí)的模型，一個(gè)基于服務(wù)的模型，前者面對(duì)服務(wù)對(duì)象，后者面向服務(wù)本身，如果這兩個(gè)模型是穩(wěn)健的，它將一個(gè)ITSM的系統(tǒng)架構(gòu)做了最底層的約束，或者說形成了這個(gè)ITSM系統(tǒng)的骨架或靈魂，基于這兩個(gè)模型可以做許多延伸與分析，就我個(gè)人而言，我覺得它有一定的突破意義，對(duì)于外界或行業(yè)方面，只能在未來觀察了。首先要介紹的CI本身的構(gòu)建模型，見下圖與面向?qū)ο蟮乃枷胍粯?，用類的方式來?gòu)建CI，一個(gè)類有二個(gè)方面的特性，它與其它的類有什么樣的關(guān)系，它有哪一些屬性，首先類、關(guān)系、屬性都需要結(jié)構(gòu)化，且不能強(qiáng)制做分層數(shù)，即你不能要求CI分類全部要三層，你也不能要求關(guān)系只能

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

4、盡，相互獨(dú)立。理論上，如果兩個(gè)分類它的關(guān)系、屬性、動(dòng)作全部一樣，則不需要分成兩個(gè)類，但在實(shí)施時(shí)我發(fā)現(xiàn)，不要吝嗇分類的設(shè)計(jì)，許多人覺得屬性一樣時(shí)，就合并類，比如將刀片、PC服務(wù)器、小型機(jī)都置成一個(gè)類，叫服務(wù)器，這其實(shí)并不合適，因?yàn)閱栴}是出在了屬性設(shè)計(jì)上，而不出在類上，你不能因?yàn)锳病了，讓B去吃藥。類能在、模型表達(dá)、動(dòng)作、關(guān)系、統(tǒng)計(jì)分析上帶無可比擬的方便性，它可以讓你的一切都只需要基于類級(jí)做控制即可，如果只是在類上加一個(gè)屬性叫“服務(wù)器類型”，這樣的結(jié)果是你的系統(tǒng)功能變得非常復(fù)雜，你可能需要實(shí)現(xiàn)根據(jù)屬性去過濾你的模型，需要考慮屬性去計(jì)算業(yè)務(wù)影響，以及你的所有的報(bào)表統(tǒng)計(jì)。類的數(shù)據(jù)是整個(gè)CMDB的基礎(chǔ)的

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

6、會(huì)得到一個(gè)CMDB的藍(lán)圖，這個(gè)藍(lán)圖就是這個(gè)公司自已的CMDB模型，這樣當(dāng)在構(gòu)建CI時(shí)，根本不需要用戶再去決定填哪一種關(guān)系，因?yàn)殛P(guān)系是由類決定的，不是由CI決定的，當(dāng)用戶知道這個(gè)CI跟哪一個(gè)CI有關(guān)系時(shí)，模型層會(huì)自動(dòng)添加上正確的關(guān)系類型，每個(gè)類跟哪一些類有怎樣的關(guān)系，不能跟哪一些類有哪一些關(guān)系就在系統(tǒng)層做了控制，也就是說用戶永遠(yuǎn)無法構(gòu)建出錯(cuò)誤的模型，他只能構(gòu)建出錯(cuò)誤的數(shù)據(jù)，每一個(gè)關(guān)系的數(shù)據(jù)，最后在實(shí)體CI填充時(shí)，類似屬性一樣，可以填寫一個(gè)值，這個(gè)值即是“關(guān)系說明”，我們以前在模型層只畫一根線，表達(dá)兩者有一種連接關(guān)系，這種表達(dá)有時(shí)是不夠的，尤其在應(yīng)用程序之間的關(guān)系上，比如你在模型上看兩個(gè)應(yīng)用程序有

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

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

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

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

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

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

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

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

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

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

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

18、管理，然后習(xí)慣的叫它XXX系統(tǒng)，其余此時(shí)是因?yàn)槲覀冊(cè)诂F(xiàn)實(shí)業(yè)務(wù)中沒有定義清楚什么是一個(gè)系統(tǒng)，如果我認(rèn)真審視，我們負(fù)責(zé)的所有系統(tǒng)清單，我們會(huì)發(fā)現(xiàn)，其實(shí)許多系統(tǒng)只是概念性的聚合之物，它屬于某種業(yè)務(wù)領(lǐng)域或單元的概念，如果我們不定義清楚什么是一個(gè)系統(tǒng)，而用原有的概念去做CMDB的建模時(shí)，我們會(huì)發(fā)現(xiàn)就需要把一個(gè)所謂的系統(tǒng)拆成若干個(gè)子系統(tǒng)，從而引發(fā)建模思想與標(biāo)準(zhǔn)的問題。如果我們足夠聰明，我認(rèn)為我們是完全可以梳理出一個(gè)公司的所有業(yè)務(wù)及所有IT服務(wù)的關(guān)系圖的，然后再定義每一個(gè)IT服務(wù)擁有哪一些對(duì)象（CI），此時(shí)業(yè)務(wù)世界與IT世界才真正的結(jié)合起來了，此時(shí)展現(xiàn)的模型已經(jīng)超出了CMDB的世界，也就是說我們現(xiàn)在要達(dá)到的

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

20、行了。也許有人會(huì)問，一個(gè)系統(tǒng)的某一個(gè)報(bào)表模塊只有A部門會(huì)用，如要系統(tǒng)功能不往下拆分，那怎么能實(shí)現(xiàn)當(dāng)報(bào)表模塊壞時(shí)，只有A部門會(huì)受影響的結(jié)果呢？，答案是，如果在IT架構(gòu)中，沒有任何一個(gè)元素來獨(dú)立支撐報(bào)表模塊，那么這種故障傳導(dǎo)的結(jié)果是不會(huì)發(fā)生的，因?yàn)橹灰獞?yīng)用程序或數(shù)據(jù)實(shí)體發(fā)生問題，會(huì)直接導(dǎo)致所有用戶受影響，這種問題也是一個(gè)在CMDB實(shí)施時(shí)常見到的傾向，一切似乎是圍繞著業(yè)務(wù)影響分析的目的進(jìn)行的，我的看法是，以目前的CMDB發(fā)展情況而言，是無法支撐一個(gè)精確的分析結(jié)果的，根本原因是一個(gè)CI的狀態(tài)在分析時(shí)只有0與1的取舍，這在客觀上就違背了現(xiàn)實(shí)世界的復(fù)雜性，用權(quán)重百分比之類的做法，也只是在一定程度上緩解這個(gè)

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

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

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

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

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

26、更控制思想，更瘋狂的是，任何對(duì)象的事件與變更是可預(yù)見的，如果抽象出來后，我們還會(huì)發(fā)現(xiàn)，某一種現(xiàn)象的事件或某一種類型的變更，它一定會(huì)由某一種動(dòng)作來實(shí)現(xiàn)完成，此時(shí)自動(dòng)判斷用什么動(dòng)作來處理事件或變更就成為了可能，但這一步，估計(jì)目前是做不到的，需要做全方面的提高后，才能可能成為現(xiàn)實(shí)。根據(jù)服務(wù)模型，當(dāng)我們真正在做服務(wù)作業(yè)時(shí)，假設(shè)一個(gè)ITSM系統(tǒng)開始作業(yè)，我們轉(zhuǎn)變一下思路，用面向?qū)ο蟮姆绞饺枂柮恳粋€(gè)工單，我們會(huì)發(fā)現(xiàn)事件、問題、變更、發(fā)布、監(jiān)控、備份、災(zāi)備等等全部是基于對(duì)象的，我們?cè)谧鳂I(yè)時(shí)需要思考是與哪一個(gè)對(duì)象相關(guān)，以前我們?cè)谔顚憜螕?jù)時(shí)，只是寫我們做了什么，而不會(huì)說基于哪一個(gè)對(duì)象，改變這種行為，讓CMDB

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