轉載：http://blog.vsharing.com/xqscool/A607190.html
CMDB最後的吹牛
經過半年多的時間，終於把CMDB的設計工作結束了，時間雖然不長，但感覺象是很長一樣，同時感覺到經過一次的思考過程，對於管理或事物有了一種新的視角，說不清是什麼，只是更清晰了，好象有一點面對對象的概念一樣，發現現在去破解一件任務或工作，更加容易了。
俺是一個喜歡思考的人，對事物的看法比一般人要深入些，有些象越獄裏那個MICHAEL SCOFIELD，那傢伙看東西可以把內在的物理結構看清楚，俺沒有那麼高杆，只是情況有些類似，喜歡去思考事物的本質，俺也不認爲我是一個智商過人的人，因爲這在讀書時已證明不是了，這種情形我不知道是後天訓練的結果還是先天的性格等造成的，有時我感興趣的東西跟別人不太一樣，我喜歡坐在公交車裏去思考那個該死的無人售票車的車票錢是如何交付的，怎樣避免不被人貪污盜用？，那些態度惡劣的司機們每天象塞沙丁魚罐頭一樣往車裏裝人，是一個怎樣的績效管理機制讓他們如此？美國的登月工程與他們的第一個核子工程是如何實現管理的，數十萬人要組織協同，各種物資的調配是怎樣實現管理的，我會好奇這些東西，有時達到一種病態的地步。
在我規劃設計CMDB時，有各種人與資料告戒我，CMDB的設計要如何如何，難度是怎樣怎樣，今天回過頭來看，真正理解CMDB並把握應用的人是極少的，包括那些顧問公司的顧問們，最終完成這份工作，外界的人與資料起到的作用很小，有時個人覺得國內可以獨立完成這種設計結果的人不會超過50人（可能10個也不到），這可能讓大家覺得狂妄了，但我個人真是如此認爲的，但這份工作本身並沒有結束，後續的應用纔是關鍵，但我相信最終如果出面質量問題應該不會出在模型本身。下面是我將對一些我不太認同的觀點進行說明一下，希望大家不象我一樣在一開始又是被顧問恐嚇，又是被網上的資料恐嚇，搞得誠惶誠恐的，真正把腳站在你業務上，有一個清晰的頭腦與思路，比什麼都重要：
1、配置管理的顆粒度問題
顆粒度過細的問題，我一直強調一個觀點，全世界沒有一個人可以給某個公司正確的配置管理的顆粒度的硬性指導原則，這不是一個硬性或可以測量的事物，但有一些基本的道理在內可以幫助我們思考，第一原則是顆粒度與我們運維能力成正比，當你可以去修復一臺電腦的內存條或硬盤時，你的顆粒度就需要到達內存條這一顆粒度，如果沒有這個運維能力，你只需要關注整機；第二個原則是當你需關注配件時，你的顆粒度最好能夠覆蓋到這一層級，因爲在配置管理中，備用件的信息是起碼需要關注的；第三個原則是你的管理需求決定你關注信息的多少（屬性池）。而我正是根據這些原則引入模型來具體應用的（CI類有多少，CI屬性有多少），討論CI類有多少，這些一定要與具體負責運維服務作業的主管與工程師討論交流確定，要防止有爲了某種完美去追求極致的現象發生。對配置這項工作而言，需要有人能夠超前思考，我們不能去確定一個CI分類與屬性池，結果過不了一年就進行大的調整，因爲CI分類與屬性池局部的調整是可以的，但大範圍改變，勢必會引發混亂，比如打印機，現在大家爲了貪圖省力，只建了一個分類是打印機，那麼我們幾百個針式的、噴墨、激光的各式打印機都會被劃入打印機這個分類中，但用了一段時間後，發現這樣信息是不夠或管理不方便，又想把打印機下面再建幾個子類，把針式、噴墨、激光這幾個建成子分類，這樣意味着需對在CMDB中的已有幾百臺打印機進行重新維護分類。這還不是最麻煩的，如果日後的有一種既可以打印又可以傳真的機器比較多時，而我們又沒有提前設計好這個分類，到時如何劃分呢，劃分到打印機不合適，劃分到傳真機也不合適，甚至有可能對原有的分類造成衝擊，這樣原有的整個分類體系就可以需要調整，這纔是最可怕的。所以在配置管理活動中，需要超前意識到管理需求與技術發展，這是一個智慧的事件，不能爲了圖一時之便去把難題都留給未來解決，一定需要預留空間發展，減少未來大的調整次數。關於配置管理顆粒度的最後一點意見是，一定要關注你的運維能力（變更控制能力）如果你沒有辦法能力對你置入CMDB的信息進行控制，必然會導致失敗，建議的做法是，歸劃好CI分類，屬性池可以逐步有戰略的擴充，如果你的運維管理能力成熟度高，那OK，一步到位。
2、CMDB的維護成本問題
CMDB日後的維護成本也是大家比較關心的一個問題，事實上CMDB的維護成本與顆粒度是與正比的，因爲信息越大，維護成本就可能越大，這裏面我要說明三個觀點：一顧問公司與我們的目標並不是時刻一致的，他們的意見有時我們需要過濾。二是維護成本與服務活動是相關的，當我們的服務活動真的造成配置信息改變，是必須記錄的，這個成本是必須付出的。第三是維護成本真正分析後，我們會發現它是一個弱成本。具體說明如下：
我們對日後維護成本的擔心，更多來自顧問們的建議，對於成本問題，我在半年前構建我們公司模型時就考慮過，要構建配置模型時，如何應用，如何維護，如果調用，甚至在事件、問題、變更中哪幾個界面會有接口調用，我都考慮好了。我們公司也是一個項目型的公司，出於成本考慮，當合同金額確定時，我們會希望客戶在最短的時間完成項目交付，同樣的道理，顧問也會一樣考慮，顧問們第一考慮是認證的問題，你的配置做得粗放，不會影響認證，但你做得越細，對顧問公司而言，沒有收益，只會增加相應的作業成本，因爲你會把項目週期拉長，也會產生一定項目風險，是不是把CMDB做實，這不是顧問公司關心的，這一點會非常重要，對顧問公司的建議，首先要考慮他們利益立場，然後再理性的客觀分析，我從來不迷信所謂的專業權威，這隻會導致盲從。
在運維服務作業中，真正的成本取於我們的運維活動，你的運維活動越多，你的成本就會越大，而你每一個運維活動如果產生或改變了信息，從管理角度而言，就必須記錄的，當我們把客戶的5000臺電腦的配置記錄在CMDB時，當一個工程師把一臺電腦的硬盤更換了或者操作系統升級了，我們不應該做相應的記錄與控制嗎？這裏面真正的成本是工程師在更換硬盤與操作系統升級的時間，而不是在CMDB中做信息維護的時間（這是大家一直混淆這兩個概念，真正的運維成本與CMDB的維護成本是兩回事，CMDB不管是不是需要維護，我們的運維成本還是擺在哪兒的，因爲那個硬盤你還是得去更換，操作系統你還是得去升級），這種信息的管理是最起碼而必須的，我們不可能說客戶把5000臺機器交給我們，而最後我們這5000臺機器的起碼配置信息都不知道，這裏不談什麼我們的服務產品化，而是一個最基本的管理規範問題，這種因管理規範而產生的成本，作爲服務商必須自我消化，如果連這種信息成本都無法承擔，只能說明兩種情況：要麼，我們的運維業務根本沒有市場競爭力，要麼客戶服務支付價格過低，不值得簽訂下一次運維合同。就我對當前的運維業務的瞭解，一般是完全有空間去規範這種基礎管理的。
最後具體來談談CMDB的維護成本，CMDB維護成本取決於兩點，一是我們的配置管理顆粒度，二是作業過程中對配置信息產生變更的次數。首先說我們的配置管理顆粒度，配置信息的多少與CMDB維護成本是有關係的，但不一定是成正比的，因爲有許多我們關心的信息事實是不會發生改變的，所以不會產生維護成本，比如一臺服務器，它的製造商、技術參數、生產日期、停用日期、存放在點等等，這些信息是我們關心的，但是基本不可能發生變化，所以這種信息不會帶來日後的維護成本。第二點關於作業過程中對配置信息產生變更的次數，這纔是真正對我們CMDB維護成本起到決定性因素的地方，因爲你的配置信息每發生一次更改，就得做一次維護控制，但現實中，我們的配置信息真正多是桌面類的項目上，發生變更最多也是桌面項目上，在應用軟件項目中，除了軟件版本會偶爾發生變化外，其餘的配置信息是很少變動的。而系統類項目的配置信息更是改變更少，因爲服務器的配置信息很少在他們作業過程中發生變更。而網絡領域發生配置信息變化的情況也是相對很少的，如果多是一定出了問題，因爲這種最基礎的設施是不可能經常做調整改動的。如果大家真正把自已的CI分類與屬性池真正分析一次，然後分析一下各個業務領域的作業特性的話，我相信大家會得出和我一樣的結論，真正日後頻繁做CMDB維護動作的只有桌面類的項目，在上一段落我已說明了做這個維護CMDB動作的必須性（因爲你的確把人家的硬盤更換了，把操作系統升級了），現在再具體說成本，在系統設計時，我一直站在一線工程師的角度考慮，怎麼操作便利，怎麼才能把大家的時間資源從系統維護中釋放出來，而投入到真正的生產過程中。真正在CMDB中把一硬盤的信息完成更新，需要多久時間呢？我的估計最多是一分鐘，這裏大家就會發現CMDB維護的時間是零散的分在各個業務活動中的，我無法相信工程師做了一分鐘的工作就會引發成本變化或生產就會受到影響了。就算一名工程師一天可以修十臺機器，一天需要花15分鐘來做CMDB的維護，就對我們的運維成本產生影響了嗎？我們的運維成本是取決於我們的人員工資，我們會因爲CMDB上線就爲桌面多招一名工程師嗎？不可能，我們會因爲CMDB上線後，而讓人員加班嗎或者因此發放加班費嗎？不會。所以不會帶來成本的上升。另一方面我們的工程師真的忙到一天連十幾鐘的軟件填寫時間都沒有嗎？就我看到的業務情況，運維人員一般還不至於忙到這個地步。所以對成本上升一事，不深入到業務細節是無法正確得出結論的，CMDB的維護對公司的整個運維成本不會產生直接影響的，當網上與所謂的ITIL專家們叫着在實施CMDB實施時，要注意日後的維護成本一事，我認爲這更多是一個業務問題，也是一個能力問題，當你真正把握事物的本質時，真正洞悉業務後，這其實是一個僞問題了
3、 CMDB的構建原則
什麼自上而下，什麼自下而上，這些大家應該聽說過，老實說我認爲這不叫什麼原則，同時這種所謂的原則連顧問公司也沒有幾個人可以真正說清楚，更沒有真正應用實踐過，我的建議是，大家老實老實把自已的CI分類搞清楚再說，搞清楚了分類，再去談屬性，最後想好CI如何組裝在一起，方便調用，CMDB不是孤立存在的，一定要想好各個其它流程的調用與關聯問題，沒有想好前，就不要動手設計數據庫。
關於配置管理與CMDB我寫得太多了些，就差不多到這兒了，短時間內不打算再針對這一塊寫什麼東西了，我們搞ISO20000的體系的認證，每個流程有安排流程經理負責，CMDB寫這麼多，主要是我除了負責整個體系的推行又專門負責了配置管理這個流程，後續我有時間寫寫ISO20000體系方面的，那纔是我花時間最多的地方，時間夠的話，最好是能每一個流程都寫一篇，但懷疑可能性不大，因爲太耗時間了，最近也忙得有些受不了了。CMDB就吹牛到這兒吧，大家對付着看看了。。。
除了死亡，一切只是概率