你所不知道的CMDB ： CMDB起源與發展

6 人贊了文章

## CMDB起源

在今天，配置管理資料庫（CMDB，後面均用這個簡稱，並且暫時不去區分CMDB和CMS）這個名詞對於IT從業人員來說一點都不陌生，甚至有點爛熟了。無論是ITIL在企業落地、自動化運維、標準化運維、DevOps、端到端統一監控，甚至最時髦的運維大數據、智能運維（AIops）等都很難繞開CMDB這個概念。說CMDB是企業IT運維標準化、自動化、數據化和智能化的基石，相信現在應該沒有多少人反對了。

儘管在此之前，和CMDB類似的信息庫已經被IT部門使用了多年，但是CMDB這個名詞其實是源自ITIL（Information Technology Infrastructure Library，信息技術基礎架構庫）。CMDB最開始出現應該是在ITIL V2.0中，其中對於配置管理的定義是這樣的：

- Identify, record and report all IT components that are under the control and scope of CM

- Provide a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of CIs in existence

- CM is basis for other processes

看不懂，是吧？我也看不懂，沒事，有中文翻譯，請看下面。

「CMDB，Configuration Management DataBase，配置管理資料庫，是與 IT 系統所有組件相關的信息庫，它包含 IT 基礎架構配置項的詳細信息。」——CMDB

「由識別和確認系統的配置項、記錄和報告配置項狀態和變更請求、檢驗配置項的正確性和完整性等活動構成的服務管理流程。」——配置管理

- 計量組織和服務中所使用的所有IT資產和配置項的價值；

- 為其它服務管理流程提供有關IT基礎架構配置的準確信息；

- 為事件管理、問題管理、變更管理和發布管理的運作提供支持；

- 核實有關IT基礎架構的配置記錄的正確性並糾正發現的錯誤。

ITIL理論體系大致經過了下面三個階段和版本：

- ITIL V1——1986~1999 由英國國家計算機和電信局（CCTA）實踐開發的，總共有40多捲圖書，出來後很快得到了歐洲的認可；

- ITIL V2——英國商務部（OGC）在1999年推出來的，得到了世界的認可。OGC把它總結為10本圖書；它的發展非常快，到2001年，被接納為英國國家標準BS15000；2005年，被接納為國際標準ISO20000；

- ITIL V3——到了2007年5月30日頒布了3.0版本，基於服務生命周期與時俱進地融入了IT服務管理領域當前的最佳實踐。

可以看到，早在1999年英國國家計算機和電信局（俗稱英國電腦局）就推出V2版本和CMDB概念，那麼為什麼直到最近幾年，CMDB才開始在無論傳統企業還是互聯網企業聲名鵲起，並被我們熟知呢？大致分析起來，應該有以下幾個原因：

1. 中國的IT進程本就落後外國很多年，1999年推出概念到被中國IT界知曉並理解，晚個10年左右是很正常的事情；無論是虛擬化、還是其他技術，基本上都會經歷一個大致的延遲才能在中國得到認知；

2. 早些年，中國的傳統企業要麼IT規模和複雜度有限，要麼即便IT規模很大但是環境迭代十分緩慢（幾年甚至10幾年不升級軟硬體系統是家常便飯），因此即便用「文檔+人肉」的方式，企業IT環境管理也沒有多少痛楚；而那個時間的中國互聯網公司，普遍處於成長過程中，還沒有形成自己特有的配置管理方法論，更談不上理念和技術輸出；

3. 隨著中國企業IT規模和複雜性的迅速增長，以及業務更新迭代的頻率加快，對於IT運維的標準化、統一化和自動化需求水漲船高，傳統的「文檔+人肉」的方式難以吃消，紛紛尋找技術解決方案，這個時候躺在角落裡，身上覆滿灰塵的「CMDB」君重新被挖掘出來，閃亮登場。

4. 並且由於中國互聯網企業的迅猛發展，導致事實上CMDB這個理念在傳統企業和互聯網公司中是以不同的方式和面目落地的：

- 傳統企業更多的是與ITIL理念結合，作為ITIL中的一部分構建和部署；但由於ITIL的笨重、龐大與臃腫，真正把ITIL用得好的企業很少，導致CMDB後來在傳統企業中往往淪為了純粹的靜態資產管理和數據查詢，而且這種靜態資產往往還是失真的和混亂的；過些年，又要重新梳理或者通過上一套新的系統來重建，再次折騰一遍，下層運維苦不堪言；

- CMDB這個概念在剛剛推出的時候，由於過於寬泛和模糊，即便被企業理解，也註定是難以落地和成功使用的。直到後來BMC等傳統軟體巨頭在自家的ITIL相關產品中推出CMDB管理的產品和解決方案，CMDB才逐漸開始真正在國內外落地開花。而BMC等企業推出比較成熟的CMDB產品，其實已經到了2006年下半年。

- 互聯網公司則要務實的多，對於CMDB的使用效果也好得多。在互聯網公司，CMDB更多的是以應用發布、變更和管理為目的創建的：將與某個應用相關的從上層的進程、服務到底層的伺服器、網路等配置悉數納管，真正將CMDB的數據用起來；並且由於與應用管理流程打通，基本可以確保數據的質量。當然，這也是個坎坷前進的過程，都走過不少彎路，並且由於互聯網公司天生就不看重ITIL這種重流程的模式，因此CMDB早期在每家互聯網企業中的使用註定是個性化的、很難具備通用性，更談不上技術輸出。經過重重演進和互聯網界內部的反覆交流和重新定義，CMDB逐漸形成大致統一的範式和標準，才有最近幾年，互聯網公司紛紛將自己對於CMDB最佳實踐的理解對外輸出到其他行業。

## CMDB早期使用情況

美麗說的趙成同學，在他的技術專欄中，曾經描繪了與CMDB相關的這麼一個案例：

「早期，大約是在2009~2013年，我接觸了一個省級運營商的全國性項目。2012年的時候日PV就到了5億左右，日訂單創建接近2000萬。分層的軟體架構，不到千台伺服器，對於資源的管理，仍然是用Excel表格來記錄的。

運維基於這樣一個表格去管理和分配各種資源，問題也不算太大。究其根本，就是基礎設施層面的架構形態相對穩定，有穩定的軟體模塊數量和架構。但是發展到後來，這樣的軟體架構無法滿足業務的快速迭代，還是做了架構上的拆分，這就是後話了。

這裡我想表達的是，在那個時期，即使是在IT架構相對先進的運營商體系下面，我也沒有太多地聽說過CMDB這個概念，包括運營商自身，以及為運營商提供整體技術解決方案的廠商，還有來自方方面面的資深架構師和諮詢師等，在做系統架構和運維架構設計時，沒有人提及過CMDB，也沒有人提出把它作為核心部件去建設，更多的都是從ITIL管理服務的流程體系去給出諮詢建議；在落地實施的時候，我們最終見到的大多是一條條的流程規範和約束，後來增加的也多是流程和審批，甚至是紙質的簽字審批。

這也從一個側面說明，CMDB在那個時期更多的還是停留在概念階段，甚至是無概念狀態，也沒有什麼最佳實踐經驗的傳承，CMDB這個概念本身並不具備實踐意義，管理的方式方法也就停留在原始的Excel表格中。高大上的ITIL體系更多的是被當做流程規範來落地的，真正體現在技術方案和技術產品上的落地並不多。我想這是實施過程中對ITIL理解和運用的一大誤區。」

瀚緯科技的合伙人張亮同學曾經在他的一次分享中描述過了他所經歷的國內CMDB的發展歷史：

「**2004年**

我從04年開始參與國內某銀行的CMDB建設，這時CMDB的典型場景是資產信息的電子化。配置信息的採集主要採用Excel導入的方式，CMDB模型需要提前預設，不具備動態擴展能力，暫且稱之為CMDB1.0。

2006年

到了06年，我在某銀行主導實施了國內第一個基於BMC Atrium CMDB架構的CMDB項目，這時的CMDB開始側重於與其他ITSM (IT Service Management，IT服務管理 )流程的協同以及故障、變更影響分析等診斷場景。

但由於配置數據的初始化工作仍然需要手工Excel導入，同時配置信息的更新也不及時（無法在一個變更窗口內更新完成），導致上層場景沒有發揮作用。這個階段我們稱之為CMDB2.0。

**2007年**

從07年開始，配置自動化發現工具的引入，幫助企業極大簡化了配置數據初始化工作。

**2008年**

緊接著，08年左右業界提出變更閉環的概念，即在變更結束後重新進行配置自動發現並更新配置信息。相比CMDB2.0階段，配置信息更新實時性有一定程度提高。

**2012年**

12年一些銀行開始嘗試通過配置自動發現工具實現配置比對場景，尤其是災備與生產環境配置比對，以及集群環境內任意兩節點間的配置比對。

**近幾年**

應該說，配置自動發現工具一定程度上降低了配置數據初始化和維護的難度，但限於配置自動發現工具的技術局限，發現時間往往較長，發現的信息也存在一定盲區，同時還需使用root等管理員賬號，這些約束一定程度上影響了自動發現工具的實際使用效果。這個階段我們稱之為CMDB3.0。」

而據我個人的了解，即便是騰訊這樣在國內和世界上處於技術領先地位的互聯網公司，他們的核心業務部門也是在2008年左右開始CMDB系統的建設，並在隨後數年反覆更迭和演進，最終形成一個穩定的CMDB系統。

由上可見，CMDB這個概念雖然早早由英國電腦局在ITIL中提了出來，但由於寬泛、模糊和缺乏工具，中間難以在企業落地；在此期間，企業更多的是以「文檔+人肉」的方式實現ITIL中配置管理的一部分功能。

隨後，隨著ITIL的理念在全球的廣泛流行和被認可，BMC等傳統軟體巨頭紛紛跟進推出自有的CMDB產品和解決方案。但那個時候的CMDB依然只是一個靜態的配置存儲中心，問題一大堆，在2006的騰訊新聞中可以略窺一二：

「目前的CMDB產品還有許多需要改進的地方：首先是缺乏標準，ITIL只是提出要建CMDB，但對於怎麼建、建成什麼樣的CMDB並沒有明確的指導性意見，數據的整合、共享非常麻煩。

第二是和ITIL流程的集成性差，限制了CMDB充分發揮其價值，並且造成了CMDB信息無法通過流程提供準確的保障。

第三是和其他系統的集成性差，系統間的信息無法同步，造成信息的矛盾。

第四，缺乏自動化的配置採集，導致很多信息只能手工錄入、人工維護，無法及時、準確地提供配置信息。」

（http://tech.qq.com/a/20061025/000443.htm）

之後，經過這些巨頭在產品層面的反覆迭代，最終CMDB在傳統企業中才與ITIL方面的產品一道在傳統企業落了家；但由於ITIL本身的厚重和難以駕馭，用好的依然不多。

由於中國的互聯網公司從一開始走的就是開源軟體和技術自研這條路，並且天生不看重ITIL這種重流程，因此CMDB事實上在互聯網公司走的是另外一條以應用和業務管理為出發點和目標的道路。中間也是經歷各種坎坷和坑，最終形成了適合互聯網公司的一套CMDB建設和管理思路。雖然百花齊放，各自不同，但大體的思路和理念是想通的。

在下一篇文章中，我們一起聊下CMDB目前在傳統非互聯網企業以及互聯網企業中的應用現狀是怎樣的。敬請期待。

本文首發於微信公眾號：嘉為科技（微信號：canway_service），轉載請註明出處。

------------

**嘉為科技** —— IT解決方案與服務領先者，騰訊藍鯨智雲全國首家授權技術合作夥伴，擁有嘉維藍鯨IT自動化運維、IT基礎架構服務、應用軟體開發、雲計算四大系列業務，提供自本地到雲端、從標準架構到定製開發的一系列優秀IT解決方案和服務，全新打造嘉維藍鯨IT自動化運維解決方案、CMDB解決方案、DevOps解決方案等，提升客戶信息化水平和市場競爭力，助力客戶的業務發展。

**嘉為集團** —— 成立於2001年，由嘉為科技和嘉為教育組成，於廣州、深圳、北京、上海設有分公司，融IT服務和培訓諮詢於一體，為客戶提供解決方案、運維支持、軟體研發及培訓教育服務。歷經18年的發展和積累，嘉為已成為備受客戶讚譽的行業翹楚。