大型it組織，比如大中型銀行、券商、保險、大型企業的cmdb建設基本上可以定義為三個階段：
第一階段主要是台賬式配置管理，其資料主要是通過手工維護的，基礎需求是為了滿足基礎的硬體資源管理及監管要求。
第二個階段是面向it基礎資源的配置管理，其主要關注各類軟、硬體資源的全生命週期的管理，關係的是各類資源的資訊和關聯關係。
第三個階段是面向應用的全生命週期管理，其重點關注從應用的建立、研發測試、上線、變更、遷移、下線**整個過程，同時重點關注應用之間、應用內各元件以及元件的關係資訊。目前大部分金融客戶和企業的cmdb建設處於第
一、二階段。當然對於企業來講，絕大部分實際是沒有cmdb，就是乙個殘缺不全、缺乏持續更新的cmdb。
現在的cmdb的更多的是基於雲計算、大資料、微服務技術環境的不斷發展，來滿足自動化、智慧型化運維的需求，傳統的cmdb逐漸已無法滿足各類消費需求，具體主要體現在：
1、以iaas、paas為基礎的雲環境與傳統的運維環境共存，雙態模式使得資料中心的基礎架構更加複雜，也使得cmdb的模型和關係建設更加困難，也更多重要。
2、混合雲和微服務的發展使得應用內的拓撲關係、應用間的呼叫關係資訊更加複雜，故障定位與變更影響分析等場景愈加困難，進而對cmdb的消費依賴以及模型粒度，也從傳統的應用級逐步向應用模組、應用服務級轉變。
3、隨著itoa（大資料運維）、aiops（智慧型運維）等理念工具引入運維領域，對配置資料的消費需求越來越旺盛，對cmdb的準確性、全面性、及時性也越來越高。
這就是為什麼越來越多的客戶把cmdb放在devops平台中實施的原因，廠商原來越多的把cmdb作為乙個單獨的產品來做，比如我們神州資訊的cmdb。
運維平台的建設思考
自己最近也在琢磨如何搭建出乙個完善有效的運維平台，當然這個工作不是一朝一夕就能完成，前行的道路上肯定會有各種各樣的困難和牽絆，但是自己還是能夠學以致用，把一些重複性，繁瑣性的工作都能解放出來，能夠更加關注於更高的乙個層級來看待整個系統。我把搭建運維平台的過程分成了5個階段，當然純粹是個人之見，難免有...
運維平台的建設思考 元資料管理
之前也寫過一篇比較基本的文章，也算是自己對運維平台的乙個基本思考。當然想法簡單，而且缺乏實踐，但是朝著這個方向邁進是沒有錯的。從我的觀點來看，現在能夠實現半自動化運維已經很了不得了。而且把這些工作能夠落到實處，更是不易 比如舉幾個簡單的例子。比如對於資料庫的資料檔案新增這個功能來說，其實完全可以實現...
運維平台的建設思考 元資料管理（二）
之前分享過一篇元資料管理的文章 如果伺服器不多，或者人也不多，基本都是按照下面的方式來管理。比如下面是14臺伺服器，會在特定的伺服器 比如中控 設定乙個專門的路徑來存放乙個檔案，即伺服器列表資訊，然後把對應的責任人都劃分出來。當然這種方式是比較簡單，也看起來確實很清晰，對於基本的管理應該是沒有問題，...