聊聊CMDB的前世今生

我們前面在講标準化的時候，對關鍵的運維對象做了識别，主要分為兩個部分:

基礎設施層面:IDC機房、機櫃、機架、網絡裝置、伺服器等;

應用層面:應用元資訊、代碼資訊、部署資訊、腳本資訊、日志資訊等。

這兩部分是整個運維架構的基礎部分，運維團隊是維護的Owner，需要投入較大的精力去好好地規劃建設。

當我們識别出運維對象和對象間的關系，并形成了統一的标準之後，接下來要做的事情就是将這些标準固化，固化到某個資訊管理平台中，也就是我們常說的配置管理，專業一點就 叫作 CMDB(Confguration Management DataBase)。

其實，如果我們找準了需求和問題在哪裡，你會發現技術手段和平台叫什麼就真的不重要了，隻要是内部能夠達成一個統一共識的叫法就好。

關于如何打造CMDB和應用配置管理，我之前有一篇公開的文章《有了CMDB，為什麼還需要應用配置管理》，寫得已經比較細緻了，會在下一期釋出出來，但不占用我們專欄的篇 幅。

今天我主要來聊一聊CMDB的前世今生，幫助你更加深刻地了解這個運維核心部件，對我們後面開展CMDB的建設大有裨益。

CMDB源起

CMDB并不是一個新概念，它源于ITIL(Information Technology Infrastructure Library，資訊技術基礎架構庫)。而ITIL這套理論體系在80年代末就已經成型，并在當時和後 來的企業IT建設中作為服務管理的指導理論得到廣泛推廣和實施。但是為什麼這個概念近幾年才被我們熟知?為什麼我們現在才有意識把它作為一個運維的核心部件去建設呢?

我想主要有兩個因素，一個起了限制作用，一個起了助推作用。 CMDB這個概念本身的定義問題，限制了CMDB的實施;

網際網路技術的發展驅動了運維技術的發展和演進，進而重新定義了CMDB。 傳統運維思路下的CMDB

我們先來看下第一個原因，按照ITIL的定義:

CMDB，Confguration ManagementDataBase ，配置管理資料庫，是與IT系統所有元件相關的資訊庫，它包含IT基礎架構配置項的詳細資訊。

看完上面這個描述，我們能感覺到，這是一個很寬泛的概念描述，實際上并不具備可落地的指導意義。事實上也确實是這樣，稍後我們會講到。

同時，CMDB是與每個企業具體的IT軟硬體環境、組織架構和流程強相關的，這就決定了CMDB一定是高度定制化的體系。雖然我們都知道它不僅僅是一個存儲資訊的資料庫那麼簡 單，但是它的具體形态是什麼樣子的，并沒有統一的标準。

從傳統IT運維的角度來看，運維的核心對象是資源層面，所謂的基礎架構也就是網絡裝置和硬體裝置這個層面;各種關聯和拓撲關系，基本也是從伺服器的視角去看。是以更多地，我們 是把CMDB建設成為一個以裝置為中心的資訊管理平台。

這也是目前絕大多數公司在建設運維平台時最優先的切入點，因為這些運維對象都是實體存在的，是最容易被識别的和管理的;像應用和分布式中間件這種抽象的邏輯對象反而是不容易被識别的。

這種形态，如果是在軟體架構變化不大的情況下，比如單體或分層架構，以伺服器為中心去建設是沒有問題的。因為無論裝置數量也好，還是申請回收這些變更也好，都是很有限 的，也就是整個IT基礎設施的形态變化不大。

我沒有專門調研過國外的實施情況，但就國内的情形，談下我的經曆。

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

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

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

這也從一個側面說明，CMDB在那個時期更多的還是停留在概念階段，甚至是無概念狀态，也沒有什麼最佳實踐經驗的傳承，CMDB這個概念本身并不具備實踐意義，管理的方式方 法也就停留在原始的Excel表格中。

高大上的ITIL體系更多的是被當做流程規範來落地的，真正展現在技術方案和技術産品上的落地并不多。我想這是實施過程中對ITIL了解和運用的一大誤區。 接下來，我們看第二個原因，也就是網際網路運維的助推力。

網際網路運維體系下的CMDB 值得慶幸的是，進入到互聯時代，随着網際網路運維力量的崛起，CMDB這個概念也真正地得到了落地實踐，從理論概念的方法論階段過渡到了具備具體技術方案的可實施階段，而且得到了業 界的持續分享和傳播。我們現在能夠看到的CMDB經驗分享，基本上都是中大型網際網路公司的運維最佳實踐。

不過，值得注意的是，“此CMDB”已經非“彼CMDB”。我們前面提到，傳統運維階段，我們更多是以裝置為核心進行管理，但是到了網際網路技術階段，這個核心就變了，變成了應用 這個核心對象。

至于原因，我們前面已經講過，主要還是網際網路技術的快速發展，大大推進了微服務技術架構的落地和實踐，這種場景下，應用各次元的管理複雜度、應用的複雜度就逐漸展現出來了，是以我們的很多運維場景就開始圍繞着應用來開展。

與此同時，雲計算技術也在蓬勃發展，逐漸屏蔽了IDC、網絡裝置以及硬體伺服器這樣的底層基礎設施的複雜度，有公有雲或私有雲廠商來專注聚焦這些問題，讓我們的運維不必再 花過多的精力在這些基礎設施上面;同時，單純以硬體為核心的CMDB形态也被逐漸弱化。

是以，此時的CMDB，仍然可以叫做配置管理資料庫，但是這個配置管理的外延已經發生了很大的變化。之前所指的簡單的硬體資源配置管理，隻能算是狹義的了解;從廣義上講， 目前的應用以及以應用為核心的分布式服務化架構、緩存、消息、DB、接入層等基礎元件，都應該納入這個配置管理的範疇。

是以在這個時期，我們提到的運維自動化，遠不是自動化的伺服器安裝部署傳遞或網絡自動化配置這種單一場景，而是出現了持續傳遞、DevOps、SRE等更适合這個時代的對運維 職責的定義和新的方法論。

到了這個階段，傳統運維思路下的CMDB，因為管理範圍有限，可以定義為狹義上的CMDB;而網際網路運維思路下的CMDB外延更廣，我們稱它為廣義的CMDB。新的時期，對于CMDB的理 解也要與時俱進，這個時候，思路上的轉變，遠比技術上的實作更重要。

CMDB進行時 如果我們仔細觀察，會發現一個很有意思的現象。CMDB源于80年代末的ITIL，源于傳統IT運維階段，但真正讓它發揚光大的，确是新興的網際網路運維行業，而且現在很多的傳統行業也在向網際網路學習運維技術。

與此同時，在中大型的網際網路公司中，比如阿裡和騰訊，也越來越重視流程規範的管控，開始更多地将嚴格的流程控制與靈活的網際網路運維技術結合起來，以避免在過于靈活多變的環境下導緻不可控的事件發生。

是以，從這裡我們可以看到，并不是說ITIL的重流程體系就一定是過時老舊的，也不是說網際網路運維技術就一定代表着最先進的技術趨勢，而是在這個過程中，不同體系互相借鑒、互相學習、 共同進步和發展，在碰撞的過程中，催生出更适合這個時代的技術體系。