CMDB模型設計_計算機軟件及應用_IT計算機_專業(yè)資料

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

2、忘記cms是什么，所以接下來我講的 模型其實有兩個層而，一個是基于ci級的模型，一個基于服務的模型，前者而 對服務對象，后者面向服務本身，如果這兩個模型是穩(wěn)健的，它將一個itsm的 系統(tǒng)架構做了最底層的約朿，或者說形成了這個itsm系統(tǒng)的骨架或靈魂，基于 這兩個模型可以做許多延伸與分析,就我個人而言,我覺得它有一定的突破意義 對于外界或行業(yè)方面，只能在未來觀察了。首先要介紹的ci本身的構建模型，見下圖分類配置分類配置分類配置分類11巴置警11配置分類應用軟件1關系1類型關一關系關系關系類型關系類型11類型-ii服 i服"1與面向對象的思想一樣，用類的方式來構建ci, 一個類有二個方面

3、的特性， 它與其它的類有什么樣的關系，它冇哪一些屈性，首先類、關系、屈性都需要結 構化，且不能強制做分層數(shù)，即你不能要求ci分類全部要三層，你也不能要求 關系只能做一層，這樣等于形成幾個樹狀的結構，以類為屮心連接點，它可以與 其它三個樹形中的任何節(jié)點發(fā)生關系，擁冇一個節(jié)點，則擁冇其所冇子節(jié)點，這 會極大的靈活日后的維護，卜血分別講解一卜這幾個緯度的意義：1. 分類：即把it架構中所有的元素進行分類別名。在這一個數(shù)拯集中，只記錄存著 分類木身的樹形結構，或者說是所有服務對象的分類結構，所以此處是不會擊現(xiàn) 虛擬ci的概念的，即類似組織、人員、地點、服務這類信息是不會成為某一種 分類的，所以在這個模

4、型z中，是建立it架構木身的投影，盡可能真實的表達 出真實架構的情況，在分類方而可以利用現(xiàn)冇的資產(chǎn)清單，并做一次所冇部門的 服務對彖調查，這樣匯總后，做一次分析整理，做到完全窮盡，相互獨立。理論 上，如果兩個分類它的關系、屬性、動作全部一樣，則不需要分成兩個類，但在 實施時我發(fā)現(xiàn)，不要吝嗇分類的設計，許多人覺得屬性一樣時，就合并類，比如 將刀片、pc服務器、小型機都置成一個類，叫服務器，這其實并不合適，因為 問題是出在了屈性設計上，而不出在類上，你不能因為a病了，讓b去吃藥。 類能在、模型表達、動作、關系、統(tǒng)計分析上帶無可比擬的方便性，它可以讓你 的一切都只需要基于類級做控制即可，如果只是在類

5、上加一個屬性叫“服務器類 型”，這樣的結果是你的系統(tǒng)功能變得非常復雜，你口j能需要實現(xiàn)根據(jù)屬性去過 濾你的模型，需?？紤]屈性去計算業(yè)務影響，以及你的所有的報表統(tǒng)計。類的數(shù) 據(jù)是整個cmdb的基礎的基礎，一定要嚴格做公司級的評審，當我們定清楚所 有類的屬性、關系、動作、生命周期時（注生命周期需要根拯類去做不同的定義 設計），事實上，我們就定義了變更的最小范圍。為了讓最終模型美觀，可以根 據(jù)類來設置不同的圖例圖片，來代表這個類，這樣在模型時就可以顯示依賴這個 圖片來表達顯示。2. 關系：在以前我一直希望抽彖最精簡的關系類型出來，慢慢的我感覺到這個路是不 太可行的，可能有更簡潔的方法去作業(yè)，我們在幫

6、助一個客戶實現(xiàn)cmdb吋， 我們口j能根本不需要去提前幫客戶抽象冇哪幾種關系類型，原因很簡單，當我們 定義出所有的類后，只要我們做一件事情，問問每一個類與其它所有的類會有怎 樣的關系，當我們把這個數(shù)據(jù)調查到z后，就會得到一個cmdb的藍圖，這個 藍圖就是這個公司口己的cmdb模型，這樣當在構建ci時，根本不需要用戶再 去決定填哪一種關系，因為關系是由類決定的，不是由ci決定的，當用戶知道 這個ci跟哪一個ci有關系時，模型層會自動添加上正確的關系類型，每個類跟 哪一些類有怎樣的關系，不能跟哪一些類有哪一些關系就在系統(tǒng)層做了控制，也 就是說用戶永遠無法構建出錯誤的模型，他只能構建出錯誤的數(shù)據(jù)，每

7、一個關系 的數(shù)據(jù)，最后在實體ci填充時，類似屬性一樣，可以填寫一個值，這個值即是“關 系說明”，我們以前在模型層只畫一根線，表達兩者有一種連接關系，這種表達 冇時是不夠的，尤其在應用程序之間的關系上，比如你在模型上看兩個應用程序 有依賴關系，當你鼠標停留在此關系上時，系統(tǒng)會調用關系說明的值，顯示出“a 程序需要每隔1小時調取b程序的庫存數(shù)據(jù)”。類與類z間的關系藍圖是比較花 氣力一件事，同時它乂非常重要，同樣需要公司級的嚴格評審，一旦通過后， cmdb的模型就穩(wěn)固了。關系的數(shù)據(jù)越細，日后的影響分析計算與模型表達就越精準，cmdb在實施時，以往存在的一個問題是，我們代替太多業(yè)務部門做 太多的思考與

8、決定了，當我們清楚每一個類時,每一個類與其它類有怎樣的關系 其實業(yè)務部門最清楚，可以用一個很簡單的調查表就實現(xiàn)盤點與收集，然后匯總 評審，我發(fā)現(xiàn)這項工作太少人做了，其實只需要有幾家公司認真去做一次，就完 全口j以總結出一個整個it行業(yè)的關系藍圖，此吋就口j以做產(chǎn)品數(shù)據(jù)預制了。為 了最終模型的美觀，還可以定義不同的關系類型的線條粗細、顏色、箭頭方向。c吩類ci分類21ci分類3jci分類4jci分類sjci分類6jci分類71ci分類8jb類關系b類關系ci分類1ci分類2ci分類3ci分類4ci分類5ci分類6ci分類7ci分類8d類關系d類關系3 屬性：性與以前的cmdb設計基本類似，不同z

9、處在丁，屈性需要實現(xiàn)結構化， 結構化的好處在于更加容易實現(xiàn)與類的關系建構，當一個類有一個屬性子集（節(jié) 點）吋，自動擁有其下所有的屬性，日后這個子集增加屬性時，與它有關系的所 冇的類會自動壇加此屬性，同吋更加容易讓別人理解一個類的屬性信息情況，單 一的平面直列出數(shù)十個屈性，會讓人抓不住重點，以而如杲要實現(xiàn)同性質的屬性 集屮顯示又需要進行界而定制開發(fā)，這成了一個兩難的局而，一個簡單些的邏輯 是，將屬性進行結構化，每一個節(jié)點形成一個單獨的標簽頁，一個ci分類有兒 個節(jié)點就有幾個標簽頁，同吋每個標簽頁的屬性顯示可以做排序設定，這樣可以 達到既無須定制開發(fā)，又可以實現(xiàn)屬性有效顯示的效果。屬性的填寫方式需

10、要進 行控制，它如杲是由用戶選擇，則需要定義它的數(shù)據(jù)源，比如地點信息，或者狀 態(tài)，如果是手工輸入，則需要捉供填寫示例或說明的欄位，如杲數(shù)值型，則需要 考慮提供單位的選取等等，目前由于屬性的值基本都是納入了靜態(tài)的信息，而且 許多是不可變更的，在未來要考慮屬性值的數(shù)據(jù)接入需要動態(tài)，比如象cpu資 源等，這樣就真止可以豐富在一個平臺掌握架構的狀況，同時可以基于一個平臺 來做性能分析。對于屈性的定義，雖然長遠上我感覺它過于平而單一，但短期內 仍然沒有更好的解決方案，什么是屬性，到底是將一個對彖的不同的特性作為它 的屬性，還是將這個對象的可以配置改變的項次作為屬性呢，又還是屬性只是作 為一個描述信息一樣

11、好比字典里的每一個字,將它們組裝成一句話、一篇文章， 來描述說明一個對象呢，直覺上，我覺得是第二種，但如果這樣思考的話，整個 cmdb的理解與設計及定位，需要完全進行解構，那也就是我以前所思考的一 種終極的模型，我沒有繼續(xù)按那種路線思考下去，除非有哪一天有一家公司會專 業(yè)做這個，請我去做專門研究才有可能了。3 業(yè)務：在以両實施cmdb時，我們會把ci的屈性與關系一次性構建出來，按現(xiàn)在 模型的思路，則需要進行分步作業(yè)，先不構建具體的ci,而是先定義業(yè)務，然 后再定義it服務按目前中國大多數(shù)的公司情況估計只需要定義it服務即可， 我們要理解、規(guī)劃、定義我們到底有多少個it服務在作業(yè)，把它們的層次結

12、構 刻畫出來，這就構建成了所謂的業(yè)務架構，冇了這個業(yè)務架構之后，再來梳理it 世界，也就是cmdb本身的ci信息，構建ci信息同樣需耍分步走，先不耍關 心屈性，先關心三個問題：我們冇多少個ci?每一個ci跟哪一些ci冇什么關 系？每一個ci屬于哪一個it服務？,冋答了這三個問題，我們就完成了 cmdb 所有模型的構建，而且把業(yè)務架構與it架構做了對接，此吋一棟大廈已經(jīng)建立 完成了，剩下的只是精裝修了，也就是把每一個ci的屬性進行填充，這種思路 有些像先搭建出整個骨架，不把屈性收集放在前面的原因是，發(fā)起屈性的采集是 難度最大的，一旦收集了屈性，變史必然跟進，不然數(shù)據(jù)會失真，這樣調整數(shù)據(jù) 的難度很

13、大，我們先只花很小的力氣把整個cmdb的效果展現(xiàn)出來，不過這一 關就不許展開屬性的填充工作，其實我們會發(fā)現(xiàn)最后對cmdb爭議最大的往往 是在這一個環(huán)節(jié)，要把這一個環(huán)節(jié)做得專業(yè)與嚴謹些，此時的模型效果會全部出 來了，每一個系統(tǒng)的模型，甚至cio看的公司級的模型全部可以展現(xiàn)，這會建 立一個很有效的正而剌激，為后而收集屈性建立良好的決策基礎，把眉毛胡子一 把抓最后很容易出問題，而且出問題難以調整，切記這一點：業(yè)務為先it為后， 關系為先屬性為后。在產(chǎn)品設計時，需要把基礎數(shù)據(jù)維護與基礎數(shù)據(jù)間的關系設置一分為二，以 方便相互獨立維護作業(yè)與權限控制，所以這里應該會產(chǎn)生7個功能點，必須可以 由最終用戶來實現(xiàn)

14、cmdb的基礎數(shù)據(jù)維護與發(fā)展。需要依賴開發(fā)力量來增加類 與屬性或關系，這是一種僵化的系統(tǒng)設計?；谏厦娴哪Ｐ停斠粋€ci構建時， 它會繼續(xù)這個類的所有關系與屬性，在下圖中是ci實例的模型示意。分類配置分類配置分類配置分類配置分類配置分類應用軟件11關系1流程流程屬性類型屬性類型a i i關系x關系關系類型關系類型安壯屬性業(yè)務根據(jù)前面的模型，新創(chuàng)建一個ci時，首先要決定它是哪一個類，確定后，就自 動繼承這個類所有關系、屬性、動作，需要提供一些比較方便的功能，比如一個 ci構建時可以進行克隆另一個ci的數(shù)據(jù)，如果口后技術上做一些發(fā)展，實現(xiàn)在 圖例操作，即直接在模型圖上編輯關系與屈性，這些都會帶來一

15、些全然不同的操 作體驗。當所冇ci構建完成后，此時真正意義上的cmdb q經(jīng)構建完成，此時 的cmdb的數(shù)據(jù)完全是it架構的數(shù)據(jù)，這些ci的關系組織在一起，會形成一 張網(wǎng)，沒有邊緣也沒有盡頭，此吋做影響分析，是基于it層的，如果算法正確， 我們會發(fā)現(xiàn)當ci發(fā)生故障時，它的故障路線是如何一步步發(fā)展的，當你知道it 架構的ci哪一些存在問題，又知道這些ci是從屈于哪一些it服務的，業(yè)務影 響的分析結果就顯示易見了，剩下的只是展示的問題，因為數(shù)據(jù)結果已然存在， 模型展示只是數(shù)據(jù)的表達。對于一個服務而言，需要明確四個方面的問題，服務的對象是哪一些ci,服 務的主體是哪一些單位或個人，服務的體制是哪一些

16、單位與個人，這個服務到底 要做些什么。同樣的這會形成一個四面魔方 每一個面都由一個樹形結構所構丿m 由服務對彖的任何一個節(jié)點和其它三個而做任意節(jié)點連接，見下圖。服務對象服務主體部門0務 服角色角色部門角色部門1單1位單1位1服務體制1i m i作業(yè)ii作業(yè)動作類型動作類型服務目錄說明：1服務對象：無論是業(yè)務服務還是it服務，都是面向服務，我一直認為在it服務或it管理行業(yè)屮說的業(yè)務服務是一種狹義的業(yè)務服務，業(yè)務服務與it服務的區(qū)別不在 于是不是面向服務，而在于it服務將一切分成it與非it的，業(yè)務服務將一切 分成業(yè)務與非業(yè)務的，由此帶來范圍與視角的絕大不同，要定義清楚什么是業(yè)務 每一個業(yè)務環(huán)節(jié)

17、中哪一是業(yè)務的作業(yè)內容，哪一些是非作業(yè)需要服務的內容，將 業(yè)務的重點放在核心上，剩余的外包一切，非業(yè)務的就是業(yè)務服務，業(yè)務服務可 以包括物業(yè)服務、餐飲服務、it服務等等，我相信業(yè)務服務不是it行業(yè)可以玩 得轉的，而需要在目前的企業(yè)管理運營層面發(fā)生革命性的轉折才有可能。但對于 模型層面而言，兩者其實并無二致，無論是基于業(yè)務服務還是it服務，上述的 模型均可容納 我認口j服務口j以分解的思路一個服務可能由若干個子服務構成 但我不認同在cmdb模型層對ci進行層層分解的思路，在cmdb的世界里是 沒冇聚合之物的，一切只是單一對彖，如果把人比作ci,那么我認為家庭不應 該是ci,你的cmdb模型里不能

18、既有家庭乂有個人，這樣的關系構建邏輯就會 有問題當我們定義清楚每個人的關系吋,每一個家庭的關系其實就自然出來了， 在這里，我們可以把家庭理解成服務，把個人理解成ci,所以在模型設計時， 服務的定義與一個服務有哪一些對彖的定義，我是不會放到cmdbz中的，ifu 是在itsm系統(tǒng)之中，也就是虛擬cl解決方式。不管我們是做網(wǎng)絡維護、桌面 維護、系統(tǒng)維護，還是物業(yè)服務，事實只有我們理清楚對象是什么，我們的服務 的灰色地帶才有可能清理清烙當一個服務沒有獨立的對象支撐時，我認為定義 它已經(jīng)沒有實質意義 就也就是為什么我一直反對將一個應用系統(tǒng)進行的拆分的 原因，在實施cmdb時，許多人會把一個系統(tǒng)分解成若

19、干個子功能或子服務， 這除了結構好看些外，并沒有會任何好處，反而有壞處，我們要深刻理解軟件即 服務的意思，這里面的一個難題在于，我們還沒有找到一個非常穩(wěn)鍵的概念定義 清楚，什么是一個系統(tǒng)。在實際管理中，我們會把許多關系緊密的系統(tǒng)交給一個 團隊或一個人管理，然后習慣的叫它xxx系統(tǒng)，其余此時是因為我們在現(xiàn)實業(yè) 務屮沒有定義清楚什么是一個系統(tǒng)如呆我認真審視我們負責的所有系統(tǒng)清單 我們會發(fā)現(xiàn)，其實許多系統(tǒng)只是概念性的聚合之物，它屬于某種業(yè)務領域或單元 的概念，如果我們不定義清楚什么是一個系統(tǒng)，而用原有的概念去做cmdb的 建模時，我們會發(fā)現(xiàn)就需要把一個所謂的系統(tǒng)拆成若干個子系統(tǒng)，從而引發(fā)建模 思想與

20、標準的問題。如果我們足夠聰明，我認為我們是完全可以梳理出一個公司 的所有業(yè)務及所有it服務的關系圖的，然后再定義每一個it服務擁冇哪一些對 彖（ci）,此時業(yè)務世界與it世界才真正的結合起來了，此時展現(xiàn)的模型己經(jīng) 超出了 cmdb的世界，也就是說我們現(xiàn)在要達到的業(yè)務影響分析，是基于itsm 系統(tǒng)的，而不是僅僅基于cmdb的。2.服務主體：在做業(yè)務影響分析時，我們經(jīng)常想知道到底會引影響哪一些人或部門，事實上服 務主體的數(shù)據(jù)非常重要，我們需要把跟我們服務相關的所有公司的組織與人員數(shù) 據(jù)全部置入itsm系統(tǒng)之屮，這就是我們的客戶數(shù)據(jù)屮心，當們把it服務與服 務主體建立關系時，會通過ci的故障計算出服

21、務的故障，因此會計算出哪-些 人員會受影響，需要注意的是，將it服務與個人數(shù)據(jù)直接發(fā)生關系并不是一種 好的方式，因為會帶來維護的極大麻煩（新來一個人，離開一個人，你都需要手 工維護更新），最好的方式是通過部門或崗位信息進行互聯(lián)，這樣只要維護組織 數(shù)據(jù)的人員保障服務主體的正確就行了。也許有人會問，一個系統(tǒng)的某一個報表 模塊只有a部門會用，如要系統(tǒng)功能不往下拆分，那怎么能實現(xiàn)當報表模塊壞 時，只有a部門會受影響的結果呢？，答案是，如果在it架構中，沒有任何一 個元素來獨立支撐報表模塊，那么這種故障傳導的結果是不會發(fā)生的，因為只要 應用程序或數(shù)據(jù)實體發(fā)牛問題，會直接導致所有用戶受影響，這種問題也是一

22、個 在cmdb實施時常見到的傾向，一切似乎是圍繞著業(yè)務影響分析的口的進行的， 我的看法是，以目前的cmdb發(fā)展情況而言，是無法支撐一個精確的分析結果 的，根木原因是一個ci的狀態(tài)在分析時只有0與1的取舍，這在客觀上就違背 了現(xiàn)實世界的復雜性，用權重百分比z類的做法，也只是在一定程度上緩解這個 問題，但因此引發(fā)的定義與判斷的成本，甚至要遠遠超過丟掉它，來直接看現(xiàn)實 世界的成木 這些做法僅僅是為了滿足不掌握信息的管理者實在是無奈之舉, 這好比大家都一直覺得在變更管理中，cmdb可以發(fā)揮很大的作用一樣，事實 上絕大多數(shù)變更是根木不需要利用cmdb影響分析的，因為這些提交與分析及 實施變更的人是最了解

23、情況的，所以出現(xiàn)的荒唐現(xiàn)象是，當一個變更是要個修改 數(shù)據(jù)庫中的一個客戶數(shù)據(jù)時，根拯現(xiàn)在的業(yè)務影響分析是整個公司的業(yè)務受到影 咆因為整個公司業(yè)務屮依賴此系統(tǒng)此系統(tǒng)依賴數(shù)據(jù)當領導們審批此變更時， 發(fā)現(xiàn)這影響不對啊，于是大家細化模型，工程師們花更大的力氣維護數(shù)據(jù)，但我 們一直不敢做一個更簡單決定讓那些不掌握信息的行政領導們不參與變更審批 環(huán)節(jié)，把一個技術決策扭曲成一個行政決策，除了編制太多的材料以傳遞信息與 知識外，述使得各種角色不能歸位去承擔應有的責任。4. 服務體制：要清楚規(guī)劃設計出每一個服務的作業(yè)體制，即服務經(jīng)理、一二三線的支持人員， 更龐大的服務需要更復雜的體制來應對，要清楚定義是由哪一些角

24、色及人員來完 成交付與支持服務，服務體制的數(shù)據(jù)取自行政組織的數(shù)據(jù)，行政組織多半以專業(yè) 為劃分，這樣就形成服務與專業(yè)的兩個層面，有的公司會更復雜，會有技能組類 似的概念，不管組織數(shù)據(jù)如何復雜，都需要將這些人員映射到服務體制的某個角 色z中，最后一個服務體制中的人員可能會包括多個不同公司的不同崗位的人員。 在itsm系統(tǒng)屮，一個明確的服務體制會幫助我們控制權限（無論是工單還是 ci）與派單，同時還會幫助我們了解在一個變更時，需要哪一些人員參與，從正 常情況來看，一個變更單如果只涉及其服務內部的專屬ci,則變更經(jīng)理由相應 的服務經(jīng)理擔任，如果變更涉及到的ci上支撐著多個服務時，此時需要進行聯(lián) 合審批

25、，即通過變更關聯(lián)ci的上層所有服務的服務體制來判別。5. 服務目錄：對于服務目錄的理解，我認為許多人其實是似是而非的，就象我以前講的菜單與 菜譜的例子一樣，當然這是itil理論不清晰所造成的，對于這個問題的理解， 如果站在一個專業(yè)的it服務商的角度會相對容易些，菜單其實是服務產(chǎn)品，菜 譜其實是服務冃錄，客戶需要理解的是菜單，it服務商需要理解的是服務冃錄， 服務目錄層層折解下來后，最底層的作業(yè)一定是跟ci類對接的，所以其實理論 上我們可以定義毎一個ci類的動作序列或服務目錄一個類，或者說一個配置項 可能有怎樣的維護或操作動作，這事實上屬于服務標準化的過程，這也是口前整 個it服務行業(yè)最滯后的地

26、方，每一名it服務人員到底會做哪一些動作，每一種 設備對應的維護動作有哪一些，最終每一種維護動作需要做多少次，需要多少時 間成本，這對服務分析與服務管理是非常冇意義的，它其至可以解決能力成長與 技能提升的問題如果足夠標準彳匕最后每一類設備的每一種動作形成一個手冊， 一個人是否能維護這-類設備，取決于他是否掌握這段上設備存在的所有動作， 如果將一個設備的動作分解決了不同層次，那么一線與二線及三線的職能切分也 就清楚了，因為大家的動作范圍不一樣，這又會帶來派單處理的便利性，一個服 務的內容有多少，事實上是由這個服務冇多少個對象，這個對彖冇多少動作來決 定的，這才是真正的服務目錄。全年下來時，整個i

27、t組織知道了毎一種動作的 平均吋長是多少，全年操作次數(shù)是多少，哪一些人做哪一些動作是最多的，可以 想象這種層面的分析，完全可以讓我們的管理水平與分析水平發(fā)生質的改變。如 果日后人類的作業(yè)行為更加標準化，這個模型還可以發(fā)展，因為動作與關系與屈 性其實存在關聯(lián)，理論層而則言，一個屈性的改變或一個關系的改變，一定是由 于某個動作所導致的，這乂會直接引生成新的變更控制思想，更瘋狂的是，任何 對象的事件與變更是可預見的，如果抽象出來后，我們還會發(fā)現(xiàn)，某一種現(xiàn)象的 事件或某一種類型的變更，它一定會曲某一種動作來實現(xiàn)完成，此時自動判斷用 什么動作來處理事件或變更就成為了可能，但這一步，估計ft前是做不到的，

28、需 要做全方而的提高后，才能可能成為現(xiàn)實。根據(jù)服務模型，當我們真正在做服務作業(yè)時，假設一個itsm系統(tǒng)開始作業(yè)，我 們轉變一下思路,用面向對象的方式去問問每一個工單，我們會發(fā)現(xiàn)事件、問題、變更、發(fā)布、監(jiān)控、備份、災備等等全部是基于對象的，我們在作業(yè)時需耍思考 是與哪一個對象相關，以前我們在填寫單據(jù)時，只是寫我們做了什么，而不會說 基于哪一個對彖，改變這種行為，讓cmdb的數(shù)據(jù)與流程對接，我們會發(fā)生一 個廣闊的天地會展現(xiàn)在我們眼前，原來我們的管理模式與服務分析可以有那么大 的空間供我們馳騁。下圖模型是一個此思路的表達。服務對象it服務 | it服務|it服務|it服務|服務主體111作業(yè)11作業(yè)

29、11作業(yè)1作業(yè)動作類型動作類型服務體制1單1位服務目錄有了這幾個模型后，真正把它們實現(xiàn)在itsm屮吋，我們只需要兩層監(jiān)控，一個 是監(jiān)控服務，即我們常態(tài)理解的服務臺，接受服務受理，另一層監(jiān)控是監(jiān)控it 架構，如杲是一個用戶報事件，我們就會知道與他相關的服務會有哪幾個，每一 個服務又會冇哪一些對象，每個對彖又需要是誰負責去管理，如果是一個監(jiān)控軟 件發(fā)生告警，我們會知道這個ci是從屬于哪一些服務，它乂是誰進行管理。在 做業(yè)務影響分析吋，由于cmdb'p的cl關系是網(wǎng)狀的，存在著一個無法截止的 問題，所以任何試圖做業(yè)務影響分析時，必須先確定分析的范圍或發(fā)起點，在展 現(xiàn)一個服務的內部結構時，可以通過確定一個服務的所有對象（ci）,加上與這 些對彖存在關系的臨近一層的ci,通過關系數(shù)