ITIL實施記實之配置管理經驗談
我在這家公司工作了三年，很少象這樣需要開動所有腦力去思考一件工作，配置是一個很重要的基礎，同時也是讓我耗費腦力最多的一塊，所以先把它寫下來。
先介紹一下我們的業務情況，我們公司的運維項目較多，有網絡、系統的、桌面的、軟件的，而且這些項目用到的設備都存在共用的情況，比如一個段線路，會屬于多個項目使用，一臺客戶的電腦，也可能裝有多個管理軟件，同時它又是屬于桌面運維的，這些我們的IT組件一是數量多(光是需要桌面運維的電腦臺數在5000臺以上)，二是相互的關系復雜。
我現在所講的，是經過很多思考與折騰后，所整理出來的，我對配置管理的出發點，是從軟件實現方面考慮的，這可能與其它的公司有一些不一樣，一開始，在思考整個配置的模型，也是CMDB的業務層面邏輯，很長一段時間，在CI的結構與關系方面，我一直無法理清楚，因為當 CI的結構是怎樣，關系是怎樣不確定前，整個模型根本無從建立。最開始首先確定的是，我決定把CI的結構與關系分離，即結構是結構，關系是關系，兩者不互為影響，作用也各自不同，這個想法應該是比較大膽的，而且這是在我對ITIL不熟悉的情況做出的決定，如果這個做法錯誤，后續的很多工作都會受到影響。
決定后，剩下來就是攻破結構與關系了。在那段時間的思考中，CI的結構是首先想通的，可能是因為以前是做ERP實施的關系，也可能是因為客戶是汽車制造商的關系，最終我發現將CI組裝時，它的呈現很象ERP中的BOM結構，這是個父子結構，它可展開任意的節點，這種結構具有很大的擴展空間，也解決了配置管理顆粒度大小變化的問題，經過幾天的思考后，我已非常確定這個思路可以解決我們的CI結構問題。
剩下的關系是花的時間比較久的，查了不少資料，我一直想確定到底CI之間有哪幾種關系，這本身我一直覺得這個ITIL的推廣組織本身需要制定或想通的，而不應該由我來思考，我也看了常態下象IBM他們的做法，但他們關系與結構是互為一體的，而且他們對關系的定義簡單了些，所以***沒有采用。在思考CI的關系時，我甚至上升到哲學的層面，去思考人與人之間的關系有哪一些，事物與事物之間的關系有哪一些，看是否能對得出CI之間的關系有一些啟發作用，也在網上查了很多關于事物關系的說明，可惜沒有找到有用的說明資料。
最終找到一個解決方法，是一個周五下午快下班的時候，當時正在畫一個示意圖，想向領導表達，日后如果我們完成配置的結構與關系構建后，呈現給我們的是一個怎樣的東西，當時只把CI抽象成幾個集合，CI是用一個圓圈圖示代替，在畫了幾個圖示后，突然有一點靈光閃過，我發現當把幾十萬個CI用這樣方式串聯起來時，象一個個燈泡一樣，有的亮有的不亮，通過關系將這數量龐大的燈泡連接起來時，這種情況好象電路圖，每一個CI 位于一個復雜的線路中，形成我們公司自已的配置地圖，而且這是一個三維的圖形，多個項目形成一個面，每個項目的根據結構展開的所有CI形成一個面，而每個 CI之間的關系又形成一個面，腦子里當時形成了這圖象(這個三維的圖形后來嘗試了好幾次用VISIO或PPT畫出來，一直沒有成功)，想到這一點當時很興奮，終于看到了一道門。于在是周末休息時，去書店把數字電路的書找來看了一些篇章，最終確定引入門電路的概念來解決關系的問題。
上面介紹的是思考過程，在完成這個思考過程后，在項目啟動會上，匯報了此構想，得到領導認可，同時為了驗證可行性，我找了一個公司典型的項目做了一次試驗，看一下這樣的模型是否存在問題。這里要說明一下，我們把結構與關系分離，一是考慮結構與關系是互不對等的，二是可以讓其獨立作用在不現的地方，這樣分離之后，結構與關系本身更加嚴謹，我們將結構用于事件定位，關系用于故障推演，一個著眼于現在，一個著眼于未來。下面將展開細節說明。
一、配置管理規劃
由于以前實施REMEDY時，我們積累了一定的經驗與知識，也具備一些配置管理的概念，所以規劃方面，相對單純一些，我們以管理科為主導，各業務領域的主管為成員，目標是所有項目的CI項納入管理，在此作業開展前，我制作了一個作業計劃，主要分幾個階段。
1)CI分類規劃
2)CI屬性設計
3)CI命名規劃
4)CI模版制作
5)配置數據收集
細節的作業進程就不一一介紹了，在做這個計劃與真正執行時，發現一些很有意思的現象，也算是經驗了，這些點我會在下面逐一介紹到，下面將我們的整體的配置模型做一個介紹，
示意1
說明：
客戶組織：指我們的客戶的組織及用戶信息
運維組織：指我們內部的服務機構及員工信息
服務目錄：不作名詞解釋了
運維對象：常態上說的配置管理，即CI的集合
這四個緯度構成我們需要關注的所有配置信息，每一個緯度都是一個結構獨立的樹狀目錄，它可以多層級多節點的細分下去(這一點非常重要)，在CMDB中我只會放入運維對象的所有信息(結構與關系)，而運維對象與其它三個面的關系，也是會存放在CMDB中的，當客戶組織、服務目錄、運維組織都與運維對象發生關聯時，這時，運維組織與客戶組織(一個服務人員服務的客戶是哪一些，或一個客戶對應的服務人員是誰)，客戶組織與服務目錄(一個客戶享用哪一些服務，或一個服務哪一些客戶)，運維組織與服務目錄(一個服務人員可以提供哪一些服務，某個服務哪一些服務人員可以提供)，這些都可以通過虛擬連接起來，這種模型的建立，會帶來日后無比便利的統計分析與查詢匯總，同時也會解決我們現在許多管理上的癥結。
為了后續交流的方便，我還需要對項目這個名詞做一個定義，我是把它當成一個CI的集合，它是運維對象的一個節點，你也可以理解一個項目就是一個CI，這個CI是一個虛擬CI，它可以展開許多子節點，每一個節點都是CI，項目由于是我們公司很重要的一個“單位”，它與結算、人員、組織、服務目錄這些都會存在關聯，所以后續會經常提到它。
整體模型
上面介紹的都是規劃階段的事情，這時具體的配置工作還沒有真正展開，上面的整體模型相當于戰略，也是一個重要的基石，它決定了后續許多的事物構造，比如后續要介紹的內容，同時這種模型如此規劃時，它如何在其它的流程中作用(比如事件管理、變更等)中發揮作用，也是做了考慮的。說到這個就有一個建議了：
在構建ITSM系統時，我的建議是首先從配置管理開始，而不是通常人們建議的從事件管理開始，配置管理決定地你們的運維管理的精細度與作業方向，它如何規劃設計，會直接影響流程，你的絕大多數的數據質量也是由配置管理所決定的，在這個基石沒有想清楚與確定前，展開事件及其它流程，***整個作業可能是松散的，甚至可能是錯誤的，你的配置管理越精細，它對你的事件流程及變更流程，都是會產生影響的，配置管理顆粒度越細，它對我們的服務人員的作業行為要求就越高，引發的變更控制措施也就越多。在我的想象中，配置管理是一個服務平臺的***層建筑，它也是一個約束整個服務機制的重要所在。所以在項目的最初期，我一直是想先開發CMDB的，先把CDMB搞出來，然后灌數據，直接維護，不用事件管理，也不要變更管理，而是光光的 CMDB，到時我想看看所有的CI信息進去后，整個運維地圖是如何的，故障的推演是否能實現，如果這些都是穩固的，再在這個基礎上構建其它的應用模塊。
CMDB先開發出來還有一個好處，解決了配置數據收集維護問題，我們的配置數據屆時會非常龐大，如果先收集，那在系統還未上線前，只能用電子表格維護，考慮到關系、結構的復雜，這基本上是不現實，每天有事件發生，無法做到同步的更新，不先收集，要等到系統上線的準確時間點，完成數據收集，這個難度又太大。(做過ERP的朋友，應該知道在系統上線時，倉庫盤點數據導入的難度，只要業務不停，數據總是一個動態的，而我們的配置數據遠比這種數據復雜)，有了CMDB后，我們有足夠的時間去收集試驗，同時還可以同步更新。 #p#
二、配置模型設計
1)CI結構
在CI的結構定義中，我們的思路中，有兩個關鍵詞，“樹狀目錄”和“父子節點”及“虛擬CI”，基本的理念中，根據BOM的原理去構建我們的配置結構，最終形成的，整個公司的所有CI最終會掛在一個目錄之下，象一棵枝葉茂密的大樹，一個項目相當于一根樹枝，一個CI 相當于樹枝上面的一片樹葉，樹干是父，樹枝是子，樹枝是父，樹葉是子，父與子是一個相對的概念，用一個實例來說明，比如我們一個桌面項目，有2000多臺電腦維護，每個電腦由顯示屏、主機、電源之類的組成，這個項目就是父節點，每一個臺電腦就是子節點，但當顆粒度到更細時，一個電腦由顯示屏及主機組成，這時，相對于顯示屏、主機而言，電腦是父節點，而主機是子節點了，如果顆粒度再精細時，把硬盤、內存、主板、CPU作為CI管理時，此時主機又是父節點了。
這里還有一個現實問題，一個桌面項目，它的子節點就是2000多臺電腦，這樣的目錄，可能會太長了，不利于管理，這時為了統計或管理的方便，我們可以構建幾個虛擬CI，比如按廠區，如果這2000多個臺電腦是分布在十幾個廠區內的，我們可以將這十幾個廠區，也做為節點管理，這時，桌面項目下面的子節點就只有十幾個了(廠區)，每一個子節點下面的節點只有100多臺電腦了，這樣更富于結構，也便于查詢定位，這是虛擬 CI的概念，它是由于管理的需要產生的，這里面要尤其注意一個問題，當廠區已經作為屬性管理時，是不能再為之構建虛擬節點的，因為你的一切管理需求已經在屬性中考慮了，所以結構的設計是一個智慧的事情，你要考慮到分類、屬性設計的空間問題，不然到時有許多要素重疊，這樣一是不效率，二是可能導致數據沖突。
對于偏硬件的項目而言，它的CI結構規劃是相對簡單的，真正復雜的是軟件類的項目，比如象我們的DMS(經銷商管理系統)類項目，它是汽車制造商為了管理它的分銷商而產生的，一般大型的汽車制造商的分銷商(4S店)有200-400家左右，甚至更多。每一家分銷商的店內都有一臺服務器，安裝有DMS的服務端，店內還有許多電腦安裝有客戶端，而汽車制造商本身也有服務器，它與每一家分銷商的服務器對話，交流數據。
這種項目涉及網絡，數據接口，幾百個的數據庫，眾多的服務器與工作站，這時的配置規劃就有一定難度了，但基本上我還是發現存在一定的規律，在項目下面的一級節點中，按應用服務器、數據庫服務器、接口服務器、程序、接口程序、數據庫、專用設備、相關組件、相關網絡等這樣的思種去規劃，再逐個細化，就可以理清整個項目的CI結構，這里需要注意的事情是共用 CI的問題，當一個CI的運維權在某個項目時，這個CI的所有內部信息，別的項目只能調用，不能對其進行解釋，比如上面說的DMS項目中會用到相關網絡(A網路)，A網絡內部的所有結構與關系信息，都是由網絡領域的團隊進行規劃設計的，DMS項目只能調用A網絡本身這一個組件，這一個理念會非常重要，因為當項目眾多，組件復雜龐大時，整個公司級的配置結構是難以合作同時構建的，這時需要制定相應的游戲規劃，教每個團隊按規則去繪制自已的整個樹枝，***會自動組裝成一個參天大樹，把最專業的事情交給最專業的人，用一種比較簡單的邏輯，***形成一個復雜的東西，象計算機的二進制是如此，象我們的整體模型也是如此，每一個緯度只需要與一個續度建立關系，***所有緯度會相互關聯。這種最簡單的邏輯構成的好處在于相互獨立，分拆容易，同時容錯性強，構建容易。 #p#
2) CI關系
如果建立我們公司的所有運維對象地圖，會發現某種意義上，配置項之間的關系類似電路圖，因而引入數字電路的基本邏輯概念，從應用的視角構建新型的組件之間的關系，將組件的結構與關系獨立出來，分而治之。在邏輯電路的基本邏輯的類型如下：
與門(當一個事件由兩個以上的條件決定時，只有全部條件為真時，條件才能成立)
現實中，如果一道門有兩把鎖，只有這兩把鎖全部打開時，門才能打開，這就是一種與的關系。
或門(當一個事件由兩個以上的條件決定時，只要任一條件為真時，條件就能成立)
或的關系，在IT環境中就很多了，比如將一臺編號為A001的電腦這個CI，與其子節點的，CPU、內存、硬盤、操作系統等就是一個或的關系，即只有CPU、內存、硬盤、操作系統這其中任何一個CI出現問題，都會導致A001這個CI出現問題。
非門(當一個事件的條件為假時，對象才為真)
非的關系，我們暫時不考慮加以引用，本來的是考慮利用此非的關系將CI的備件等進行關系構建(備用設備，或維修備件)，但想到一些現實問題，備件用其它的方式進行管理，不直接引用關系，以免過于復雜。
這里面還需要說明幾個比較重要的概念：
關系的視角：
我們構建CI的關系，是從被影響的角度出發的，這一點非常重要，因為事實上中關系總是雙向的，一號CI會影響別的 CI，別的CI也會影響一號CI，這時如果雙向構建很可能會導致重復構建或錯誤構建，由于我們的關系只需要用來分析當故障出現時會導致的結果，所以我們只用單流向的關系，即可滿足需求(這個道理類似以面介紹的，用簡單的邏輯組裝成一個復雜的事物)，因為當所有CI從被影響的角度出來后，網狀關系即已形成。這一點需要很好思考一下，不然理解會出問題。下圖是一個應用方面的示意，我的想法利用關系，屆時可以圖形化推演故障路線，這樣可以直觀的采用緊急預案切斷故障路線(紅色為故障組件)。
關系構建原則：
在邏輯上，可參一個CI會直接與間接與所有CI有關系影響，但很顯然，我們無法將一個CI直接與其它所有CI去構建關系，那需要找到一個機制去解決這個問題，說到這兒要說一下我的愛好，我一直喜歡看DISCOVERY的節目，大家在看到一些自然記錄片時，會看到一大群鳥或蝗蟲在天空飛行時，是聚集在一起的，象一團烏云一般，再或者我們在看海底時，那些魚群在水中游動時，總是保持一個集合，不管它們往哪個方向游動，總是非常有效的保持一個群的形態，這些東西看起來很有美感，并感到有些不可思議，其實在這個下面，只是一個簡單的原則，當魚群游動時，每一條魚只需要與鄰近的魚保持適當的距離，這樣最終就會群。我把這個叫魚群原則，在CI的關系構建時，我當時也碰到如何去有效構建關系的問題，最近我發現利用這個原理，可以解決，即一個CI只與結構相鄰或直接影響的CI構建關系，這樣構建關系就會簡單很多，當每一個CI用這樣的機制去構建完成后，也會形成一個龐大的群，會把所有的CI有機制的串聯在一起。
在用與、或的關系構建關系，我發現一個原理，如果IT環境的與關系越多這個IT環境是會相對穩定的，不易被故障將環境瓦解，同時故障的影響度也會較低，因為一個點發生故障，不會馬上導致業務應用出現問題。或的關系越多，運維將變成更為吃力，因為每一點的影響都會導致后果發生。這也某程度上指導了我們日后的方案設計與運維管理。
是不是我們現在的這種關系構建是***無缺的?它到底存在什么問題，有什么局限性，這一點真正深入思考的人，應該會發現關鍵所在的，在我所構想的整個配置模型中，有兩個比較大的局限，我不打算獨自一個人去挑戰這兩個最難的命題，因為我很清楚對于當前的業務而言，這個模型可以滿足他們很多年，我再深入去挖掘，對于業務需要而言，過于超前了，同時我個人不太希望在這個方面走得太過深入，也因為志不在此，如果真正投入精力去研究，我覺得是有可能找到一個***模型的，因為我已知道方向在哪兒，局限何在。想到這些我就對現在的這些理論傳播者或那些顧問公司有意見，這些東西是不應該由我們這樣的公司，或者我這樣的人去研究的。就象我寫的這些文字，我相信那些ITIL的制定者、傳播者是沒有告訴過我們的，我在項目初期在在百度與 GOOGLE上流浪N久，就是想找到我現在寫的這些文字，但一無所獲，有的只是那些大而空的理論，聽起很有道理，但是你根本無法將它與現實業務去結合起來思考。不扯了，繼續往下! #p#
3) CI分類
本來按正常的邏輯，CI分類應該放在***位去思的，而不是先去說結構談關系，這樣做一是因為我們的確是先把結構與關系理清后，才去做CI分類的，二是覺得在結構關系沒有做一交待前，可能先談后面的東西，會不利于了解，這也是因為社會上沒有把CI的結構與關系跟我們做一些規范或定義，才造成的，正常來說，我們真正開始做具體的配置工作時，CI分類應該是***步，這個過程會非常重要，在沒有真正開始做前，我還沒有意識到它的影響會這么大。
再說明一下項目的情況，配置的結構、配置的關系，基本上我一個人去完成思考的，沒有動用到公司的管理資源，當這些定下來后，開始做CI分類時，這就需要走出辦公室，調動管理資源了，因為這不是一個人思考就可以決定的，這一點很重要，日后各位從事這樣的活動時，也需要把管理資源拉上，能抓到多少資源就要去抓，這是一個很好的洗腦的過程也是一個很好的互動過程，讓具體的業務領域及高層管理者開始真正參與進來。
記住一句話：CI的一級分類決定了配置管理的范圍，CI的***層分類決定了配置管理的顆粒度。這句話是后面真正領悟總結出來，一開始也沒有意識。CI分類我們的做法是這樣的，我們先找一些對業務領域比較熟的專家或管理者，首先談CI的一級分類，我們談著談著，發現談不下去了，因為沒有具體的數據支持，我們根本無法確定一級分類，于是我們轉變策略，先發模版，讓公司的各個業務領域把自已所有的運維對象全部羅列出來，最終收集上來是五花八門的清單，這就是我們最初的數據，然后我們再組織人員討論。現在的體會是，分類真的是一門藝術，更是需要智慧的。這里面要說一下我們有兩個優勢，一是我們是從系統實現的角度才開始這項工作的，所以我腦子里事實是有一個預期的，雖然我不知道具體分一類有一些什么東西，但我很清楚分類對不對，能否有效，有沒有擴展性。二個是我們以前實施過REMEDY，業務領域的人員具備一定的分類基礎。
經過討論后，我們把一級分類確定下來了，這里又得廢話幾句，我一直也不覺得這個工作是我們需要花如此的氣力做的，我們也與顧問公司交流過，他們基本上沒有給出任何有用的建議，IT的設備或環境，全世界也就那么一回事，我一直奇怪居然沒有一個關于分類規范或建議，網上也是查不到相關的有用信息。最終我們把一級二級的分類，大家分工確定下來了，然后再發布給各個業務領域評審，是否有遺漏的，分類是配置的最基礎一項工作，如果分類不當，帶來的后果很嚴重，你的統計分類，你后續的屬性設計都會受到影響，而且日后你想對某一個類做調整時，這是一個非常復雜的工程。
CI的分類我們最終的結果是，將CI分類，分為三層，一層分類為六個：環境、計算機及外設、軟件、通訊、網絡、文檔代碼。***層的分類為190個，現在讓我來說一下我們的分類原則，好象我很難總結得出來，這是一個倒推的結果，我們的分類也不是***的，因為有許多IT 設備你很難去定義它屬于哪一個類，比如我們有兩個二級分類一是計算機配件，一是存儲設備。一個硬盤，你說它屬于哪一類呢，好象兩者都可以放進去，又好象二級分類不對，但是我們有著大量的鼠標、鍵盤、光驅、內存條、顯卡、網卡這些配件存在，所以必須有一個計算機配件的分類，另一方面我們在磁帶設備、磁盤陣列、帶庫、光存儲設備，這些又必須建一個專門的存儲設備的分類出來，這樣的情況還好好多，我相信隨著IT技術的發展，原有的分類還必須打破，因為技術與產品的換代，使許多分類的界限完全打破了，所以在分類時還需要一定程度上考慮未來技術發展，有一些IT設備現在雖然數量不大，種類不多，但現在有明顯的趨勢看出未來一定會獨立發展成一種專門領域的話，那就有必要先把分類建好，一個目的，***可能的減少日后對分類的調整。
另外還有一點需要說明的是，CI的結構與分類，很多時候是會讓人混淆的，比如在我們***層的分類中，硬盤、內存條、CPU與計算機是并列，當時有人認為硬盤、內存條、CPU等是應該在計算機類下面的子類中的，這種意識是好多人都會存在的，包括當時我們的領導也是覺得這樣的分類好象不對，也認為應該如此。但事實上這樣是不對，他們都把CI的分類與CI的結構混淆了，而且忽略了分類的根本意義，硬盤、內存等都是計算機的組成部份，這是一個結構信息，我們分類是為了把所有CI種類做一個分類，然后在構建CI結構時，再把每一個種類進行組裝，分類不需要考慮任何的結構信息，再說分類的作用，分類更多是為了日后的統計，如果把計算機作為一大類，把硬盤、內存等作為子類，這樣統計出來的數據全部是錯誤的，因為這樣分類的話，程序會把每一個硬盤、內存條都作為一臺計算機統計出來，統計一個父分類時，一定會把其所有的子分類全部計入。所以有時我們從程序實現的角度來考慮問題，也帶給我們一些便利。最終我們的做法是，建了兩個大類，一個是計算機整機，一個是計算機配件，把硬盤、內存、CPU這些東西統統丟在計算機配件中。
本段開頭的***句話是：CI分類的***層分類決定了配置管理范圍，***層分類決定了配置管理的顆粒度，我們的一層分類是：環境、計算機及外設、軟件、通訊、網絡、文檔代碼，這是我們的配置管理范圍，告訴我們這些東西是我們統統要管理的，***層分類，比如計算機及外設這個一層分類中，分了計算機整機與計算機配件，而計算機配件這一個分類下面，又分為鼠標、鍵盤、光驅、內存條、硬盤、CPU、顯卡、網卡、電池、電源等，這個***層分類告訴我們，我們日后關于計算機及外設這個配置管理范圍下面的顆粒度要達到CPU級的，事實上CI分類的過程就是你配置規劃的過程，它是你整個運維目標及能力的提現，它決定了你日后約大多數的服務活動。
關于分類有一點說明：如果你的倉庫中存在某一款配件的話，即便你的配置管理顆粒度不想達到一個級別，你也***需要為此構建分類，同時這一類的配件，你需要日后構建為CI進行管理。比如，如果你是做桌面運維的，你的配件倉庫中存在硬盤的備件，那么你就需要建一個分類出來，同時你在構建CMDB時，每一個硬盤你***作為CI管理，不然這會造成許多問題。這也算是分類的一個原則吧，任何你需要加以關注的設備或配件，都必須可以被分配到你CI分類的某個***層分類中。
***一點需要說明的是，分類與屬性的平衡，分類時要注意，如果有一些信息是可以利用屬性控制的，可以適當減少分類，比如鼠標，有光電的，也有普通滑輪的，這是兩個不同種類的東西，但是我們沒有必要為此建兩個分類，我們只需建一個分類，就是鼠標，同時多為這一個CI 分類多設計一個屬性，叫鼠標類型，這樣通過屬性就可控制了，同時后續的統計分統也可以滿足了，這里沒有一個很硬性的標準，比如計算機，有大型機，有小型機，有普通的工作站或服務器，為什么計算機就需要做多個CI分類，而鼠標就不用分類，用屬性控制呢?，這是由屬性的異同決定的，如果同樣一個范圍的IT組件，它們的屬性是很接近或相同，我們就是沒有必要建多個分類;如果它們的屬性差別很大，這時就需要多建分類了，這是為了管理的便利。所以我一直說分類是一個智慧的事情，就象配置管理的顆粒度一樣，這需要去各方面平衡把握的。CI分類就說這些了，真正在做分類時，相信大家就有體會了，這些也不是抄書或誰教的，都具備的作業過程中個人的一些經驗與智慧。 #p#
4)CI屬性設計
當所有CI的分類確定后，下一步的工作就是需要設計屬性了。說到這個可能還是得做一些知識或概念說明，因為這方面的資料并不多。
在編程中有一個概念叫面向對象，我們在配置規劃或構建CMDB時，跟這個道理有一些類似。說簡單些，我跟劉德華，我們是否不同，取決于我們各自的屬性，屬性可能理解為對我們的信息的進一步補充，對我如果我們需要的信息不多，可能我們的屬性只是：身高、性別、體重、面容等等，這時劉德華沒有我偉岸，我也沒有他帥，所以我們就可以區分出來了，我是我，他是他，這是我們的屬性不同，但是這里需要注意，這里我和劉德華是不同的對象，但是我們屬于同一個分類(都是人)、我們屬性范圍是一樣的，只是屬性值不一樣(身高不一樣，長得不一樣)，我們的想法是根據分類設計不同的屬性，兩個不同的分類，是因為屬性范圍不一樣，人的屬性有身高、性別、體重、面容等，計算機的屬性有制造商、品牌、生產日期等，這時人與計算機的屬性范圍是不一樣的，所以是不同的分類，所以我們前面說了CI分類，那一個CI分類跟另一個CI分類有什么不一樣，這是由各自的屬性決定的。這是***個概念。
第二個概念是父子繼承的概念，即子類會繼承父類的屬性，父類有什么屬性，它的子類就一定會有，如果我們的CI分類有三層，那么第三層的分類，會繼承其第二層，以及***級的屬性，比如計算機整機這一個分類，下面分有大型計算機、中型計算機、小型計算機、工作站等這幾個子類，如果計算機整機這一個分類有屬性：制造商、型號、購買日期等這幾個屬性，那么大型計算機、中型計算機、小型計算機、工作站這幾個分類都會有制造商、型號、購買日期這三個屬性。這是繼承的概念。
CI屬性設計，我們的工作是這樣展開的，我們把所有CI分類清單確定后，確定分工，哪一些人對哪一些IT設備是最專業的，就由他們來設計屬性，這個工作是比較復雜的，因為***需要做大量的整理工作，因為事實上許多分類的的大部份屬性是相同的，我們需要把屬性整理好，做到不重復，比如計算機有屬性叫型號，空調有屬性叫機型，這時事實是同樣的屬性，我們需要把它統一起來，我們發放的是***層的190個分類，這樣每一個分類由不同的設計屬性出來后，我們再統一命名，然后將屬性上浮，因為許多屬性可以提升為二層分類屬性，甚至提升為一層分類屬性，甚至是公用屬性，這個工作需要比較好的大腦才行。
CI屬性總的來說，分為公用屬性、一層分類屬性、二層分類屬性、三層分類屬性，還可以設私有屬性。所有屬性最終形成一個“屬性池”供每一個分類去取用。然后當我們真正需要建立一個CI項時，首先要確定這個CI屬于哪一個分類，如果它屬于計算機硬盤，那么它會自動擁有公用屬性、計算機及外設屬性(一級分類屬性)計算機配件(二級分類屬性)硬盤屬性(三級分類屬性)，我們需要做的是填上每個屬性的屬性值，這樣一個CI就完成建立了。
另外有一點需要說明的是，屬性的設計也是一個智慧的事情，取舍會非常重要，我們是先窮盡收集，保證每一個CI類需要關注的信息都收集上來，然后再做挑選，因為有許多信息是沒有價值的，或者本身的信息是難以取得的，象一些高度動態變化的信息，是不宜取用屬性時行管理的，比如CPU的使用率，除非你有底層的監控軟件可以自動通過數據接口讀取到系統中，否則這個信息是無法維護的，所以就不用為CPU這個一個分類，建一個占用率的屬性。要考慮到日后的服務成本，量力而為，如果構建得信息無法進行維護，一是影響CMDB的數據精確度，二是帶來服務成本增加過大，一旦設計了這個屬性，那么日后這一類CI的這個屬性發生變化時，需要進行監控與管理，這個成本是相當可觀的。
三、配置管理的后續工作
當完成上述的配置規劃動作后，需要做二件事件，一是CMDB的構建，二是數據收集模版的設計。我一直的看法是，當 IT服務到達一定的規模后，尤其是當IT組件龐大時，在沒有系統實現或支撐的情況下，做深入IT服務管理是空談的，暫不說事件、變更等流程，光是配置管理，沒有系統的支撐，是根本無從保證質量的，這里我覺得有一個規律，做管理咨詢的公司往往是自身公司的管理最需要被咨詢的，做軟件的公司內部往往也是最需要信息化的，做IT服務管理的，可能也是最需要接受IT服務管理的，我們在提供IT服務的同時，我們自身的IT應用其實做得遠遠不夠。
【編輯推薦】
