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畫出來，一直沒有成功)，想到這一點當時很興奮，終于看到了一道門。于在是周末休息時，去書店把數字電路的書找來看了一些篇章，最終確定引入門電路的概念來解決關系的問題。

上面介紹的是思考過程，在完成這個思考過程后，在項目啟動會上，匯報了此構想，得到領導認可，同時為了驗證可行性，我找了一個公司典型的項目做了一次試驗，看一下這樣的模型是否存在問題。這里要說明一下，我們把結構與關系分離，一是考慮結構與關系是互不對等的，二是可以讓其獨立作用在不現的地方，這樣分離之后，結構與關系本身更加嚴謹，我們將結構用于事件定位，關系用于故障推演，一個著眼于現在，一個著眼于未來。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]