CMDB模型設(shè)計說明

頁腳頁腳CMDB模型設(shè)計這幾年以來，CMDB的模型每隔段時間在腦子里就會折騰一番，近期有一點小小突破，一直沒有時間跟心情沉下來記錄，到現(xiàn)在我仍然認為目前的CMDB的產(chǎn)品層的設(shè)計與實施層的建模思想都存在問題，可惜沒有資源去驗證自已的整個想法，我設(shè)計的模型如果有任何個人或公司在此之上做產(chǎn)品實現(xiàn)，我都是樂意的，甚至可以考慮提供免費的咨詢支持，一個想法不斷沖擊你的大腦，你卻無法看到它的實現(xiàn)與驗證，這實在是一件讓人沮喪的事情。將這篇文章的標題寫成CMDB模型設(shè)計僅僅是為了符合大家的認知與興趣，我對CMDB這個狹義的名稱越來越不感冒了，因為它與一個完整的ITSM系統(tǒng)有著某種二元對立之嫌，同時它又讓大家忘記CMS是什么，所以接下來我講的模型其實有兩個層面，一個是基于CI級的模型，一個基于服務(wù)的模型，前者面對服務(wù)對象，后者面向服務(wù)本身，如果這兩個模型是穩(wěn)健的，它將一個ITSM的系統(tǒng)架構(gòu)做了最底層的約束，或者說形成了這個ITSM系統(tǒng)的骨架或靈魂，基于這兩個模型可以做許多延伸與分析，就我個人而言，我覺得它有一定的突破意義，對于外界或行業(yè)方面，只能在未來觀察了。首先要介紹的CI本身的構(gòu)建模型，見下圖配置分類］配置分英I配置分奠|.應(yīng)用軟井配置分類］配置分英I配置分奠|.應(yīng)用軟井1配買項|配置項IT服務(wù)IT眼務(wù)與面向?qū)ο蟮乃枷胍粯?，用類的方式來?gòu)建CI,一個類有二個方面的特性，它與其它的類有什么樣的關(guān)系，它有哪一些屬性，首先類、關(guān)系、屬性都需要結(jié)構(gòu)化，且不能強制做分層數(shù)，即你不能要求CI分類全部要三層，你也不能要求關(guān)系只能做一層，這樣等于形成幾個樹狀的結(jié)構(gòu)，以類為中心連接點，它可以與其它三個樹形中的任何節(jié)點發(fā)生關(guān)系，擁有一個節(jié)點，則擁有其所有子節(jié)點，這會極大的靈活日后的維護，，下面分別講解一下這幾個緯度的意義：分類：即把IT架構(gòu)中所有的元素進行分類別名。在這一個數(shù)據(jù)集中，只記錄存著分類本身的樹形結(jié)構(gòu)，或者說是所有服務(wù)對象的分類結(jié)構(gòu)，所以此處是不會出現(xiàn)虛擬CI的概念的，即類似組織、人員、地點、服務(wù)這類信息是不會成為某一種分類的，所以在這個模型之中，是建立IT架構(gòu)本身的投影，盡可能真實的表達出真實架構(gòu)的情況，在分類方面可以利用現(xiàn)有的資產(chǎn)清單，并做一次所有部門的服務(wù)對象調(diào)查，這樣匯總后，做一次分析整理，做到完全窮盡，相互獨立。理論上，如果兩個分類它的關(guān)系、屬性、動作全部一樣，則不需要分成兩個類，但在實施時我發(fā)現(xiàn)，不要吝嗇分類的設(shè)計，許多人覺得屬性一樣時，就合并類，比如將刀片、PC服務(wù)器、小型機都置成一個類，叫服務(wù)器，這其實并不合適，因為問題是出在了屬性設(shè)計上，而不出在類上，你不能因為A病了，讓B去吃藥。類能在、模型表達、動作、關(guān)系、統(tǒng)計分析上帶無可比擬的方便性，它可以讓你的一切都只需要基于類級做控制即可，如果只是在類上加一個屬性叫“服務(wù)器類型”，這樣的結(jié)果是你的系統(tǒng)功能變得非常復(fù)雜，你可能需要實現(xiàn)根據(jù)屬性去過濾你的模型，需要考慮屬性去計算業(yè)務(wù)影響，以及你的所有的報表統(tǒng)計。類的數(shù)據(jù)是整個CMDB的基礎(chǔ)的基礎(chǔ)，一定要嚴格做公司級的評審，當我們定清楚所有類的屬性、關(guān)系、動作、生命周期時（注生命周期需要根據(jù)類去做不同的定義設(shè)計），事實上，我們就定義了變更的最小圍。為了讓最終模型美觀，可以根據(jù)類來設(shè)置不同的圖例圖片，來代表這個類，這樣在模型時就可以顯示依賴這個圖片來表達顯示。關(guān)系：在以前我一直希望抽象最精簡的關(guān)系類型出來，慢慢的我感覺到這個路是不太可行的，可能有更簡潔的方法去作業(yè)，我們在幫助一個客戶實現(xiàn)CMDB時，我們可能根本不需要去提前幫客戶抽象有哪幾種關(guān)系類型，原因很簡單，當我們定義出所有的類后，只要我們做一件事情，問問每一個類與其它所有的類會有怎樣的關(guān)系，當我們把這個數(shù)據(jù)調(diào)查到之后，就會得到一個CMDB的藍圖，這個藍圖就是這個公司自已的CMDB模型，這樣當在構(gòu)建CI時，根本不需要用戶再去決定填哪一種關(guān)系，因為關(guān)系是由類決定的，不是由CI決定的，當用戶知道這個CI跟哪一個CI有關(guān)系時，模型層會自動添加上正確的關(guān)系類型，每個類跟哪一些類有怎樣的關(guān)系，不能跟哪一些類有哪一些關(guān)系就在系統(tǒng)層做了控制，也就是說用戶永遠無法構(gòu)建出錯誤的模型，他只能構(gòu)建出錯誤的數(shù)據(jù)，每一個關(guān)系的數(shù)據(jù)，最后在實體CI填充時，類似屬性一樣，可以填寫一個值，這個值即是“關(guān)系說明”，我們以前在模型層只畫一根線，表達兩者有一種連接關(guān)系，這種表達有時是不夠的，尤其在應(yīng)用程序之間的關(guān)系上，比如你在模型上看兩個應(yīng)用程序有依賴關(guān)系，當你鼠標停留在此關(guān)系上時，系統(tǒng)會調(diào)用關(guān)系說明的值，顯示出“A程序需要每隔1小時調(diào)取B程序的庫存數(shù)據(jù)”。類與類之間的關(guān)系藍圖是比較花氣力一件事，同時它又非常重要，同樣需要公司級的嚴格評審，一旦通過后，CMDB的模型就穩(wěn)固了。關(guān)系的數(shù)據(jù)越細，日后的影響分析計算與模型表達就越精準，CMDB在實施時，以往存在的一個問題是，我們代替太多業(yè)務(wù)部門做太多的思考與決定了，當我們清楚每一個類時，每一個類與其它類有怎樣的關(guān)系，其實業(yè)務(wù)部門最清楚，可以用一個很簡單的調(diào)查表就實現(xiàn)盤點與收集，然后匯總評審，我發(fā)現(xiàn)這項工作太少人做了，其實只需要有幾家公司認真去做一次，就完全可以總結(jié)出一個整個IT行業(yè)的關(guān)系藍圖，此時就可以做產(chǎn)品數(shù)據(jù)預(yù)制了。為了最終模型的美觀，還可以定義不同的關(guān)系類型的線條粗細、顏色、箭頭方向?！醴诸悺醯ゎ?□舟類2類m□分類4口分類5G分類E□分類了CI甘類81D類關(guān)系1□分類21口分類31D類關(guān)系—B類關(guān)系□分類5iB類關(guān)韻D類關(guān)系D類關(guān)系D類關(guān)系Cl弁類了11I。奐關(guān)系B羨關(guān)系屬性：屬性與以前的CMDB設(shè)計基本類似，不同之處在于，屬性需要實現(xiàn)結(jié)構(gòu)化，結(jié)構(gòu)化的好處在于更加容易實現(xiàn)與類的關(guān)系建構(gòu)，當一個類有一個屬性子集（節(jié)點）時，自動擁有其下所有的屬性，日后這個子集增加屬性時，與它有關(guān)系的所有的類會自動增加此屬性，同時更加容易讓別人理解一個類的屬性信息情況，單一的平面直列出數(shù)十個屬性，會讓人抓不住重點，以前如果要實現(xiàn)同性質(zhì)的屬性集中顯示又需要進行界面定制開發(fā)，這成了一個兩難的局面，一個簡單些的邏輯是，將屬性進行結(jié)構(gòu)化，每一個節(jié)點形成一個單獨的標簽頁，一個CI分類有幾個節(jié)點就有幾個標簽頁，同時每個標簽頁的屬性顯示可以做排序設(shè)定，這樣可以達到既無須定制開發(fā)，又可以實現(xiàn)屬性有效顯示的效果。屬性的填寫方式需要進行控制，它如果是由用戶選擇，則需要定義它的數(shù)據(jù)源，比如地點信息，或者狀態(tài)，如果是手工輸入，則需要提供填寫示例或說明的欄位，如果數(shù)值型，則需要考慮提供單位的選取等等，目前由于屬性的值基本都是納入了靜態(tài)的信息，而且許多是不可變更的，在未來要考慮屬性值的數(shù)據(jù)接入需要動態(tài)，比如象CPU資源等，這樣就真正可以豐富在一個平臺掌握架構(gòu)的狀況，同時可以基于一個平臺來做性能分析。對于屬性的定義，雖然長遠上我感覺它過于平面單一，但短期仍然沒有更好的解決方案，什么是屬性，到底是將一個對象的不同的特性作為它的屬性，還是將這個對象的可以配置改變的項次作為屬性呢，又還是屬性只是作為一個描述信息一樣，好比字典里的每一個字，將它們組裝成一句話、一篇文章，來描述說明一個對象呢，直覺上，我覺得是第二種，但如果這樣思考的話，整個CMDB的理解與設(shè)計及定位，需要完全進行解構(gòu)，那也就是我以前所思考的一種終極的模型，我沒有繼續(xù)按那種路線思考下去，除非有哪一天有一家公司會專業(yè)做這個，請我去做專門研究才有可能了。業(yè)務(wù)：在以前實施CMDB時，我們會把CI的屬性與關(guān)系一次性構(gòu)建出來，按現(xiàn)在模型的思路，則需要進行分步作業(yè)，先不構(gòu)建具體的CI，而是先定義業(yè)務(wù)，然后再定義IT服務(wù)，按目前中國大多數(shù)的公司情況，估計只需要定義IT服務(wù)即可，我們要理解、規(guī)劃、定義我們到底有多少個IT服務(wù)在作業(yè)，把它們的層次結(jié)構(gòu)刻畫出來，這就構(gòu)建成了所謂的業(yè)務(wù)架構(gòu)，有了這個業(yè)務(wù)架構(gòu)之后，再來梳理IT世界，也就是CMDB本身的CI信息，構(gòu)建CI信息同樣需要分步走，先不要關(guān)心屬性，先關(guān)心三個問題：我們有多少個CI?每一個CI跟哪一些CI有什么關(guān)系？每一個CI屬于哪一個IT服務(wù)？，回答了這三個問題，我們就完成了CMDB所有模型的構(gòu)建，而且把業(yè)務(wù)架構(gòu)與IT架構(gòu)做了對接，此時一棟大廈已經(jīng)建立完成了，剩下的只是精裝修了，也就是把每一個CI的屬性進行填充，這種思路有些像先搭建出整個骨架，不把屬性收集放在前面的原因是，發(fā)起屬性的采集是難度最大的，一旦收集了屬性，變更必然跟進，不然數(shù)據(jù)會失真，這樣調(diào)整數(shù)據(jù)的難度很大，我們先只花很小的力氣把整個CMDB的效果展現(xiàn)出來，不過這一關(guān)就不許展開屬性的填充工作，其實我們會發(fā)現(xiàn)最后對CMDB爭議最大的往往是在這一個環(huán)節(jié)，要把這一個環(huán)節(jié)做得專業(yè)與嚴謹些，此時的模型效果會全部出來了，每一個系統(tǒng)的模型，甚至CI0看的公司級的模型全部可以展現(xiàn)，這會建立一個很有效的正面剌激，為后面收集屬性建立良好的決策基礎(chǔ)，把眉毛胡子一把抓最后很容易出問題，而且出問題難以調(diào)整，切記這一點：業(yè)務(wù)為先IT為后，關(guān)系為先屬性為后。在產(chǎn)品設(shè)計時，需要把基礎(chǔ)數(shù)據(jù)維護與基礎(chǔ)數(shù)據(jù)間的關(guān)系設(shè)置一分為二，以方便相互獨立維護作業(yè)與權(quán)限控制，所以這里應(yīng)該會產(chǎn)生7個功能點，必須可以由最終用戶來實現(xiàn)CMDB的基礎(chǔ)數(shù)據(jù)維護與發(fā)展。需要依賴開發(fā)力量來增加類與屬性或關(guān)系，這是一種僵化的系統(tǒng)設(shè)計?；谏厦娴哪Ｐ?，當一個CI構(gòu)建時，它會繼續(xù)這個類的所有關(guān)系與屬性，在下圖中是CI實例的模型示意。

去索類型關(guān)奏型分類關(guān)嘉■關(guān)系■關(guān)系MMMMIT服備IT服務(wù)淤程去索類型關(guān)奏型分類關(guān)嘉■關(guān)系■關(guān)系MMMMIT服備IT服務(wù)淤程業(yè)務(wù)根據(jù)前面的模型，新創(chuàng)建一個CI時，首先要決定它是哪一個類，確定后，就自動繼承這個類所有關(guān)系、屬性、動作，需要提供一些比較方便的功能，比如一個CI構(gòu)建時可以進行克隆另一個CI的數(shù)據(jù)，如果日后技術(shù)上做一些發(fā)展，實現(xiàn)在圖例操作，即直接在模型圖上編輯關(guān)系與屬性，這些都會帶來一些全然不同的操作體驗。當所有CI構(gòu)建完成后，此時真正意義上的CMDB已經(jīng)構(gòu)建完成，此時的CMDB的數(shù)據(jù)完全是IT架構(gòu)的數(shù)據(jù)，這些CI的關(guān)系組織在一起，會形成一網(wǎng)，沒有邊緣也沒有盡頭，此時做影響分析，是基于IT層的，如果算確，我們會發(fā)現(xiàn)當CI發(fā)生故障時，它的故障路線是如何一步步發(fā)展的，當你知道IT架構(gòu)的CI哪一些存在問題，又知道這些CI是從屬于哪一些IT服務(wù)的，業(yè)務(wù)影響的分析結(jié)果就顯示易見了，剩下的只是展示的問題，因為數(shù)據(jù)結(jié)果已然存在，模型展示只是數(shù)據(jù)的表達。對于一個服務(wù)而言，需要明確四個方面的問題，服務(wù)的對象是哪一些CI，

服務(wù)的主體是哪一些單位或個人，服務(wù)的體制是哪一些單位與個人，這個服務(wù)

到底要做些什么。同樣的這會形成一個四面魔方，每一個面都由一個樹形結(jié)構(gòu)

所構(gòu)成，由服務(wù)對象的任何一個節(jié)點和其它三個面做任意節(jié)點連接，見下圖。

服務(wù)對壕fI單準單位角色口部門部門部門單位單位服務(wù)主體務(wù)

艮服務(wù)對壕fI單準單位角色口部門部門部門單位單位服務(wù)主體務(wù)

艮

Mn

T部門說明：1.服務(wù)對象：無論是業(yè)務(wù)服務(wù)還是IT服務(wù)，都是面向服務(wù)，我一直認為在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ù)，每一個業(yè)務(wù)環(huán)節(jié)中哪一是業(yè)務(wù)的作業(yè)容，哪一些是非作業(yè)需要服務(wù)的容，將業(yè)務(wù)的重點放在核心上，剩余的外包一切，非業(yè)務(wù)的就是業(yè)務(wù)服務(wù)，業(yè)務(wù)服務(wù)可以包括物業(yè)服務(wù)、餐飲服務(wù)、IT服務(wù)等等，我相信業(yè)務(wù)服務(wù)不是IT行業(yè)可以玩得轉(zhuǎn)的，而需要在目前的企業(yè)管理運營層面發(fā)生革命性的轉(zhuǎn)折才有可能。但對于模型層面而言，兩者其實并無二致，無論是基于業(yè)務(wù)服務(wù)還是IT服務(wù)，上述的模型均可容納，我認可服務(wù)可以分解的思路，一個服務(wù)可能由若干個子服務(wù)構(gòu)成，但我不認同在CMDB模型層對CI進行層層分解的思路，在CMDB的世界里是沒有聚合之物的，一切只是單一對象，如果把人比作CI，那么我認為家庭不應(yīng)該是CI，你的CMDB模型里不能既有家庭又有個人，這樣的關(guān)系構(gòu)建邏輯就會有問題，當我們定義清楚每個人的關(guān)系時，每一個家庭的關(guān)系其實就自然出來了，在這里，我們可以把家庭理解成服務(wù)，把個人理解成CI,所以在模型設(shè)計時，服務(wù)的定義與一個服務(wù)有哪一些對象的定義，我是不會放到CMDB之中的，而是在ITSM系統(tǒng)之中，也就是虛擬CI解決方式。不管我們是做網(wǎng)絡(luò)維護、桌面維護、系統(tǒng)維護，還是物業(yè)服務(wù)，事實只有我們理清楚對象是什么，我們的服務(wù)的灰色地帶才有可能清理清楚，當一個服務(wù)沒有獨立的對象支撐時，我認為定義它已經(jīng)沒有實質(zhì)意義，就也就是為什么我一直反對將一個應(yīng)用系統(tǒng)進行的拆分的原因，在實施CMDB時，許多人會把一個系統(tǒng)分解成若干個子功能或子服務(wù)，這除了結(jié)構(gòu)好看些外，并沒有會任何好處，反而有壞處，我們要深刻理解軟件即服務(wù)的意思，這里面的一個難題在于，我們還沒有找到一個非常穩(wěn)鍵的概念定義清楚，什么是一個系統(tǒng)。在實際管理中，我們會把許多關(guān)系緊密的系統(tǒng)交給一個團隊或一個人管理，然后習慣的叫它XXX系統(tǒng)，其余此時是因為我們在現(xiàn)實業(yè)務(wù)中沒有定義清楚什么是一個系統(tǒng)，如果我認真審視，我們負責的所有系統(tǒng)清單，我們會發(fā)現(xiàn)，其實許多系統(tǒng)只是概念性的聚合之物，它屬于某種業(yè)務(wù)領(lǐng)域或單元的概念，如果我們不定義清楚什么是一個系統(tǒng)，而用原有的概念去做CMDB的建模時，我們會發(fā)現(xiàn)就需要把一個所謂的系統(tǒng)拆成若干個子系統(tǒng)，從而引發(fā)建模思想與標準的問題。如果我們足夠聰明，我認為我們是完全可以梳理出一個公司的所有業(yè)務(wù)及所有IT服務(wù)的關(guān)系圖的，然后再定義每一個IT服務(wù)擁有哪一些對象（CI），此時業(yè)務(wù)世界與IT世界才真正的結(jié)合起來了，此時展現(xiàn)的模型已經(jīng)超出了CMDB的世界，也就是說我們現(xiàn)在要達到的業(yè)務(wù)影響分析，是基于ITSM系統(tǒng)的，而不是僅僅基于CMDB的。2.服務(wù)主體：在做業(yè)務(wù)影響分析時，我們經(jīng)常想知道到底會引影響哪一些人或部門，事實上服務(wù)主體的數(shù)據(jù)非常重要，我們需要把跟我們服務(wù)相關(guān)的所有公司的組織與人員數(shù)據(jù)全部置入ITSM系統(tǒng)之中，這就是我們的客戶數(shù)據(jù)中心，當們把IT服務(wù)與服務(wù)主體建立關(guān)系時，會通過CI的故障計算出服務(wù)的故障，因此會計算出哪一些人員會受影響，需要注意的是，將IT服務(wù)與個人數(shù)據(jù)直接發(fā)生關(guān)系并不是一種好的方式，因為會帶來維護的極大麻煩（新來一個人，離開一個人，你都需要手工維護更新），最好的方式是通過部門或崗位信息進行互聯(lián)，這樣只要維護組織數(shù)據(jù)的人員保障服務(wù)主體的正確就行了。也許有人會問，一個系統(tǒng)的某一個報表模塊只有A部門會用，如要系統(tǒng)功能不往下拆分，那怎么能實現(xiàn)當報表模塊壞時，只有A部門會受影響的結(jié)果呢？，答案是，如果在IT架構(gòu)中，沒有任何一個元素來獨立支撐報表模塊，那么這種故障傳導(dǎo)的結(jié)果是不會發(fā)生的，因為只要應(yīng)用程序或數(shù)據(jù)實體發(fā)生問題，會直接導(dǎo)致所有用戶受影響，這種問題也是一個在CMDB實施時常見到的傾向，一切似乎是圍繞著業(yè)務(wù)影響分析的目的進行的，我的看法是，以目前的CMDB發(fā)展情況而言，是無法支撐一個精確的分析結(jié)果的，根本原因是一個CI的狀態(tài)在分析時只有0與1的取舍，這在客觀上就違背了現(xiàn)實世界的復(fù)雜性，用權(quán)重百分比之類的做法，也只是在一定程度上緩解這個問題，但因此引發(fā)的定義與判斷的成本，甚至要遠遠超過丟掉它，來直接看現(xiàn)實世界的成本，這些做法僅僅是為了滿足不掌握信息的管理者們，實在是無奈之舉，這好比大家都一直覺得在變更管理中，CMDB可以發(fā)揮很大的作用一樣，事實上絕大多數(shù)變更是根本不需要利用CMDB影響分析的，因為這些提交與分析及實施變更的人是最了解情況的，所以出現(xiàn)的荒唐現(xiàn)象是，當一個變更是要個修改數(shù)據(jù)庫中的一個客戶數(shù)據(jù)時，根據(jù)現(xiàn)在的業(yè)務(wù)影響分析是整個公司的業(yè)務(wù)受到影響，因為整個公司業(yè)務(wù)中依賴此系統(tǒng)，此系統(tǒng)依賴數(shù)據(jù)，當領(lǐng)導(dǎo)們審批此變更時，發(fā)現(xiàn)這影響不對啊，于是大家細化模型，工程師們花更大的力氣維護數(shù)據(jù)，但我們一直不敢做一個更簡單決定，讓那些不掌握信息的行政領(lǐng)導(dǎo)們不參與變更審批環(huán)節(jié)，把一個技術(shù)決策扭曲成一個行政決策，除了編制太多的材料以傳遞信息與知識外，還使得各種角色不能歸位去承擔應(yīng)有的責任。服務(wù)體制：要清楚規(guī)劃設(shè)計出每一個服務(wù)的作業(yè)體制，即服務(wù)經(jīng)理、一二三線的支持人員，更龐大的服務(wù)需要更復(fù)雜的體制來應(yīng)對，要清楚定義是由哪一些角色及人員來完成交付與支持服務(wù)，服務(wù)體制的數(shù)據(jù)取自行政組織的數(shù)據(jù)，行政組織多半以專業(yè)為劃分，這樣就形成服務(wù)與專業(yè)的兩個層面，有的公司會更復(fù)雜，會有技能組類似的概念，不管組織數(shù)據(jù)如何復(fù)雜，都需要將這些人員映射到服務(wù)體制的某個角色之中，最后一個服務(wù)體制中的人員可能會包括多個不同公司的不同崗位的人員。在ITSM系統(tǒng)中，一個明確的服務(wù)體制會幫助我們控制權(quán)限（無論是工單還是CI）與派單，同時還會幫助我們了解在一個變更時，需要哪一些人員參與，從正常情況來看，一個變更單如果只涉及其服務(wù)部的專屬CI，則變更經(jīng)理由相應(yīng)的服務(wù)經(jīng)理擔任，如果變更涉及到的CI上支撐著多個服務(wù)時，此時需要進行聯(lián)合審批，即通過變更關(guān)聯(lián)CI的上層所有服務(wù)的服務(wù)體制來判別。服務(wù)目錄：對于服務(wù)目錄的理解，我認為許多人其實是似是而非的，就象我以前講的菜單與菜譜的例子一樣，當然這是ITIL理論不清晰所造成的，對于這個問題的理解，如果站在一個專業(yè)的IT服務(wù)商的角度會相對容易些，菜單其實是服務(wù)產(chǎn)品，菜譜其實是服務(wù)目錄，客戶需要理解的是菜單，IT服務(wù)商需要理解的是服務(wù)目錄，服務(wù)目錄層層折解下來后，最底層的作業(yè)一定是跟CI類對接的，所以其實理論上我們可以定義每一個CI類的動作序列或服務(wù)目錄，一個類,或者說一個配置項，可能有怎樣的維護或操作動作，這事實上屬于服務(wù)標準化的過程，這也是目前整個IT服務(wù)行業(yè)最滯后的地方，每一名IT服務(wù)人員到底會做哪一些動作，每一種設(shè)備對應(yīng)的維護動作有哪一些，最終每一種維護動作需要做多少次，需要多少時間成本，這對服務(wù)分析與服務(wù)管理是非常有意義的，它甚至可以解決能力成長與技能提升的問題，如果足夠標準化，最后每一類設(shè)備的每一種動作形成一個手冊，一個人是否能維護這一類設(shè)備，取決于他是否掌握這段上設(shè)備存在的所有動作，如果將一個設(shè)備的動作分解決了不同層次，那么一線與二線及三線的職能切分也就清楚了，因為大家的動作圍不一樣，這又會帶來派單處理的便利性，一個服務(wù)的容有多少，事實上是由這個服務(wù)有多少個對象，這個對象有多少動作來決定的，這才是真正的服務(wù)目錄。全年下來時，整個IT組織知道了每一種動作的平均時長是多少，全年操作次數(shù)是多少，哪一些人做哪一些動作是最多的，可以想象這種層面的分析，完全可以讓我們的管理水平與分析水平發(fā)生質(zhì)的改變。如果日后人類的作業(yè)行為更加標準化，這個模型還可以發(fā)展，因為動作與關(guān)系與屬性其實存在關(guān)聯(lián)，理論層面則言，一個屬性的改變或一個關(guān)系的改變，一定是由于某個動作所導(dǎo)致的，這又會直接引生成新的變更控制思想，更瘋狂的是，任何對象的事件與變更是可預(yù)見的，如果抽象出來后，我們還會發(fā)現(xiàn)，某一種現(xiàn)象的事件或某一種類型的變更，它一定會由某一種動作來實現(xiàn)完成，此時自動判斷用什么動作來處理事件或變更就

成為了可能，但這一步，估計目前是做不到的，需要做全方面的提高后，才能可能成為現(xiàn)實。根據(jù)服務(wù)模型，當我們真正在做服務(wù)作業(yè)時，假設(shè)一個ITSM系統(tǒng)開始作業(yè)，我們轉(zhuǎn)變一下思路，用面向?qū)ο蟮姆绞饺枂柮恳粋€工單，我們會發(fā)現(xiàn)事件、問題、變更、發(fā)布、監(jiān)控、備份、災(zāi)備等等全部是基于對象的，我們在作業(yè)時需要思考是與哪一個對象相關(guān)，以前我們在填寫單據(jù)時，只是寫我們做了什么，而不會說基于哪一個對象，改變這種行為，讓CMDB的數(shù)據(jù)與流程對接，我們會發(fā)生一個廣闊的天地會展現(xiàn)在我們眼前，原來我們的管理模式與服務(wù)分析可以有那么大的空間供我們馳騁。下圖模型是一個此思路的表達。1!1|IT服務(wù)IT服務(wù)IT服務(wù)一■’1單1II1!1|IT服務(wù)IT服務(wù)IT服務(wù)一■’1單1II門I1作業(yè)有了這幾個模型后，真正把它們實現(xiàn)在ITSM中時，我們只需要兩層監(jiān)控，一個是監(jiān)控服務(wù)，即我們常態(tài)理解的服務(wù)臺，接受服務(wù)受理，另一層監(jiān)控是監(jiān)控IT架構(gòu)，如果是一個用戶報事件，我們就會知道與他相關(guān)的服務(wù)會有哪幾個，每一個服務(wù)又會有哪一些對象，每個對象又需要是誰負責去管理，如果是一個監(jiān)控軟件發(fā)生告警，我們會知道這個CI是從屬于哪一些服務(wù)，它又是誰進行管理。在做業(yè)務(wù)影響分析時，由于CMDB中的CI關(guān)系是網(wǎng)狀的，存在著一個無法截止的問題，所以任何試圖做業(yè)務(wù)影響分析時，必須先確定分析的圍或發(fā)起點，在展現(xiàn)一個服務(wù)的部結(jié)構(gòu)時，可以通過確定一個服務(wù)的所有對象（CI）,加上與這些對象存在關(guān)系的臨近一層的/r/