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

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í)它又讓大家

2、忘記cms是什么，所以接下來我講的 模型其實(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)建模型，見下圖分類配置分類配置分類配置分類11巴置警11配置分類應(yīng)用軟件1關(guān)系1類型關(guān)一關(guān)系關(guān)系關(guān)系類型關(guān)系類型11類型-ii服 i服"1與面向?qū)ο蟮乃枷胍粯樱妙惖姆绞絹順?gòu)建ci, 一個(gè)類有二個(gè)方面

3、的特性， 它與其它的類有什么樣的關(guān)系，它冇哪一些屈性，首先類、關(guān)系、屈性都需要結(jié) 構(gòu)化，且不能強(qiáng)制做分層數(shù)，即你不能要求ci分類全部要三層，你也不能要求 關(guān)系只能做一層，這樣等于形成幾個(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ù)拯集中，只記錄存著 分類木身的樹形結(jié)構(gòu)，或者說是所有服務(wù)對(duì)象的分類結(jié)構(gòu)，所以此處是不會(huì)擊現(xiàn) 虛擬ci的概念的，即類似組織、人員、地點(diǎn)、服務(wù)這類信息是不會(huì)成為某一種 分類的，所以在這個(gè)模

4、型z中，是建立it架構(gòu)木身的投影，盡可能真實(shí)的表達(dá) 出真實(shí)架構(gòu)的情況，在分類方而可以利用現(xiàn)冇的資產(chǎn)清單，并做一次所冇部門的 服務(wù)對(duì)彖調(diào)查，這樣匯總后，做一次分析整理，做到完全窮盡，相互獨(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í)做控制即可，如果只是在類

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

6、助一個(gè)客戶實(shí)現(xiàn)cmdb吋， 我們口j能根本不需要去提前幫客戶抽象冇哪幾種關(guān)系類型，原因很簡單，當(dāng)我們 定義出所有的類后，只要我們做一件事情，問問每一個(gè)類與其它所有的類會(huì)有怎 樣的關(guān)系，當(dāng)我們把這個(gè)數(shù)據(jù)調(diào)查到z后，就會(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ù)，每

7、一個(gè)關(guān)系 的數(shù)據(jù)，最后在實(shí)體ci填充時(shí)，類似屬性一樣，可以填寫一個(gè)值，這個(gè)值即是“關(guān) 系說明”，我們以前在模型層只畫一根線，表達(dá)兩者有一種連接關(guān)系，這種表達(dá) 冇時(shí)是不夠的，尤其在應(yīng)用程序之間的關(guān)系上，比如你在模型上看兩個(gè)應(yīng)用程序 有依賴關(guān)系，當(dāng)你鼠標(biāo)停留在此關(guān)系上時(shí)，系統(tǒng)會(huì)調(diào)用關(guān)系說明的值，顯示出“a 程序需要每隔1小時(shí)調(diào)取b程序的庫存數(shù)據(jù)”。類與類z間的關(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ù)部門做 太多的思考與

8、決定了，當(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)真去做一次，就完 全口j以總結(jié)出一個(gè)整個(gè)it行業(yè)的關(guān)系藍(lán)圖，此吋就口j以做產(chǎn)品數(shù)據(jù)預(yù)制了。為 了最終模型的美觀，還可以定義不同的關(guān)系類型的線條粗細(xì)、顏色、箭頭方向。c吩類ci分類21ci分類3jci分類4jci分類sjci分類6jci分類71ci分類8jb類關(guān)系b類關(guān)系ci分類1ci分類2ci分類3ci分類4ci分類5ci分類6ci分類7ci分類8d類關(guān)系d類關(guān)系3 屬性：性與以前的cmdb設(shè)計(jì)基本類似，不同z

9、處在丁，屈性需要實(shí)現(xiàn)結(jié)構(gòu)化， 結(jié)構(gòu)化的好處在于更加容易實(shí)現(xiàn)與類的關(guān)系建構(gòu)，當(dāng)一個(gè)類有一個(gè)屬性子集（節(jié) 點(diǎn)）吋，自動(dòng)擁有其下所有的屬性，日后這個(gè)子集增加屬性時(shí)，與它有關(guān)系的所 冇的類會(huì)自動(dòng)壇加此屬性，同吋更加容易讓別人理解一個(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分類有兒 個(gè)節(jié)點(diǎn)就有幾個(gè)標(biāo)簽頁，同吋每個(gè)標(biāo)簽頁的屬性顯示可以做排序設(shè)定，這樣可以 達(dá)到既無須定制開發(fā)，又可以實(shí)現(xiàn)屬性有效顯示的效果。屬性的填寫方式需

10、要進(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) 仍然沒有更好的解決方案，什么是屬性，到底是將一個(gè)對(duì)彖的不同的特性作為它 的屬性，還是將這個(gè)對(duì)象的可以配置改變的項(xiàng)次作為屬性呢，又還是屬性只是作 為一個(gè)描述信息一樣

11、好比字典里的每一個(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ù)按目前中國大多數(shù)的公司情況估計(jì)只需要定義it服務(wù)即可， 我們要理解、規(guī)劃、定義我們到底有多少個(gè)it服務(wù)在作業(yè)，把它們的層次結(jié)

12、構(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ì)接，此吋一棟大廈已經(jīng)建立 完成了，剩下的只是精裝修了，也就是把每一個(gè)ci的屬性進(jìn)行填充，這種思路 有些像先搭建出整個(gè)骨架，不把屈性收集放在前面的原因是，發(fā)起屈性的采集是 難度最大的，一旦收集了屈性，變史必然跟進(jìn)，不然數(shù)據(jù)會(huì)失真，這樣調(diào)整數(shù)據(jù) 的難度很

13、大，我們先只花很小的力氣把整個(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ú)立維護(hù)作業(yè)與權(quán)限控制，所以這里應(yīng)該會(huì)產(chǎn)生7個(gè)功能點(diǎn)，必須可以 由最終用戶來實(shí)現(xiàn)

14、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í)例的模型示意。分類配置分類配置分類配置分類配置分類配置分類應(yīng)用軟件11關(guān)系1流程流程屬性類型屬性類型a i i關(guān)系x關(guān)系關(guān)系類型關(guān)系類型安壯屬性業(yè)務(wù)根據(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ì)帶來一

15、些全然不同的操 作體驗(yàn)。當(dāng)所冇ci構(gòu)建完成后，此時(shí)真正意義上的cmdb q經(jīng)構(gòu)建完成，此時(shí) 的cmdb的數(shù)據(jù)完全是it架構(gòu)的數(shù)據(jù)，這些ci的關(guān)系組織在一起，會(huì)形成一 張網(wǎng)，沒有邊緣也沒有盡頭，此吋做影響分析，是基于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ù)的體制是哪一些

16、單位與個(gè)人，這個(gè)服務(wù)到底 要做些什么。同樣的這會(huì)形成一個(gè)四面魔方 每一個(gè)面都由一個(gè)樹形結(jié)構(gòu)所構(gòu)丿m 由服務(wù)對(duì)彖的任何一個(gè)節(jié)點(diǎn)和其它三個(gè)而做任意節(jié)點(diǎn)連接，見下圖。服務(wù)對(duì)象服務(wù)主體部門0務(wù) 服角色角色部門角色部門1單1位單1位1服務(wù)體制1i m i作業(yè)ii作業(yè)動(dòng)作類型動(dòng)作類型服務(wù)目錄說明：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é)

17、中哪一是業(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)的，而需要在目前的企業(yè)管理運(yùn)營層面發(fā)生革命性的轉(zhuǎn)折才有可能。但對(duì)于 模型層面而言，兩者其實(shí)并無二致，無論是基于業(yè)務(wù)服務(wù)還是it服務(wù)，上述的 模型均可容納 我認(rèn)口j服務(wù)口j以分解的思路一個(gè)服務(wù)可能由若干個(gè)子服務(wù)構(gòu)成 但我不認(rèn)同在cmdb模型層對(duì)ci進(jìn)行層層分解的思路，在cmdb的世界里是 沒冇聚合之物的，一切只是單一對(duì)彖，如果把人比作ci,那么我認(rèn)為家庭不應(yīng) 該是ci,你的cmdb模型里不能

18、既有家庭乂有個(gè)人，這樣的關(guān)系構(gòu)建邏輯就會(huì) 有問題當(dāng)我們定義清楚每個(gè)人的關(guān)系吋,每一個(gè)家庭的關(guān)系其實(shí)就自然出來了， 在這里，我們可以把家庭理解成服務(wù)，把個(gè)人理解成ci,所以在模型設(shè)計(jì)時(shí)， 服務(wù)的定義與一個(gè)服務(wù)有哪一些對(duì)彖的定義，我是不會(huì)放到cmdbz中的，ifu 是在itsm系統(tǒng)之中，也就是虛擬cl解決方式。不管我們是做網(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)分解成若

19、干個(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è)人管理，然后習(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ā)建模 思想與

20、標(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á)到的業(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ì)算出服

21、務(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ù)主體的正確就行了。也許有人會(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)致所有用戶受影響，這種問題也是一

22、個(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)重百分比z類的做法，也只是在一定程度上緩解這個(gè) 問題，但因此引發(fā)的定義與判斷的成本，甚至要遠(yuǎn)遠(yuǎn)超過丟掉它，來直接看現(xiàn)實(shí) 世界的成木 這些做法僅僅是為了滿足不掌握信息的管理者實(shí)在是無奈之舉, 這好比大家都一直覺得在變更管理中，cmdb可以發(fā)揮很大的作用一樣，事實(shí) 上絕大多數(shù)變更是根木不需要利用cmdb影響分析的，因?yàn)檫@些提交與分析及 實(shí)施變更的人是最了解

23、情況的，所以出現(xiàn)的荒唐現(xiàn)象是，當(dāng)一個(gè)變更是要個(gè)修改 數(shù)據(jù)庫中的一個(gè)客戶數(shù)據(jù)時(shí)，根拯現(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è)更簡單決定讓那些不掌握信息的行政領(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ì)，要清楚定義是由哪一些角

24、色及人員來完 成交付與支持服務(wù)，服務(wù)體制的數(shù)據(jù)取自行政組織的數(shù)據(jù)，行政組織多半以專業(yè) 為劃分，這樣就形成服務(wù)與專業(yè)的兩個(gè)層面，有的公司會(huì)更復(fù)雜，會(huì)有技能組類 似的概念，不管組織數(shù)據(jù)如何復(fù)雜，都需要將這些人員映射到服務(wù)體制的某個(gè)角 色z中，最后一個(gè)服務(wù)體制中的人員可能會(huì)包括多個(gè)不同公司的不同崗位的人員。 在itsm系統(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) 合審批

25、，即通過變更關(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ù)冃錄，客戶需要理解的是菜單，it服務(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è)最滯后的地

26、方，每一名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)作， 如果將一個(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è)i

27、t組織知道了毎一種動(dòng)作的 平均吋長是多少，全年操作次數(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ì)直接引生成新的變更控制思想，更瘋狂的是，任何 對(duì)象的事件與變更是可預(yù)見的，如果抽象出來后，我們還會(huì)發(fā)現(xiàn)，某一種現(xiàn)象的 事件或某一種類型的變更，它一定會(huì)曲某一種動(dòng)作來實(shí)現(xiàn)完成，此時(shí)自動(dòng)判斷用 什么動(dòng)作來處理事件或變更就成為了可能，但這一步，估計(jì)ft前是做不到的，

28、需 要做全方而的提高后，才能可能成為現(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的數(shù)據(jù)與流程對(duì)接，我們會(huì)發(fā)生一 個(gè)廣闊的天地會(huì)展現(xiàn)在我們眼前，原來我們的管理模式與服務(wù)分析可以有那么大 的空間供我們馳騁。下圖模型是一個(gè)此思路的表達(dá)。服務(wù)對(duì)象it服務(wù) | it服務(wù)|it服務(wù)|it服務(wù)|服務(wù)主體111作業(yè)11作業(yè)

29、11作業(yè)1作業(yè)動(dòng)作類型動(dòng)作類型服務(wù)體制1單1位服務(wù)目錄有了這幾個(gè)模型后，真正把它們實(shí)現(xiàn)在itsm屮吋，我們只需要兩層監(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ù)影響分析吋，由于cmdb'p的cl關(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ù)