CMDB翻譯過來，Configuration Management DataBase，其實也是配置管理的意思，但從實際情況看，CMDB的概念定義已經出現了很大的侷限性，之前老王也專門寫過一篇文章《如何理解CMDB的套路》來闡述過這個觀點，今天我從我們團隊自己的實踐過程中的理解和角度再來呼應下，因為這一點理解不清楚，基礎打不好，後續的自動化也好，DevOps也好，等等等等，都將無從談起。

先拋觀點： CMDB是面向資源的管理，應用配置是面向應用的管理。

注意：是資源，不是資產，資源 ≠資產

一、CMDB面向的是資源層面的管理，是運維的基石

通常，我們在建設運維的基礎管理平臺時，通常要做的事情：

1、把伺服器、網路、IDC、機櫃、儲存、配件等這幾大維度先定下來；

2、這些硬體的屬性確定下來，比如伺服器就會有SN序列號、IP地址、廠商、硬體配置（如CPU、記憶體、硬碟、網絡卡、PCIE、BIOS）、維保資訊等等；網路裝置如交換機也會有廠商、型號、頻寬等等；

3、以上資訊之間的關聯關係，或者叫拓撲關係。比如伺服器所在機櫃，虛擬機器所在的宿主機、機櫃所在IDC等簡單關係，複雜一點就會有核心交換機、匯聚交換機、接入交換機以及機櫃和伺服器之間的級聯關係，這個就相對複雜一些

4、其實應該是3.5步，在上面資訊的梳理過程中肯定就會遇到一些規劃問題，比如，IP地址段的規劃，xx網段用於DB，xx網段用於大資料、xx網段用於業務應用等等，再比如同步要做的還有xx機櫃用於做虛擬化宿主機、xx機櫃只放DB機器等等。

以上資訊梳理清楚，通過ER建模工具進行資料建模，再將以上的資訊固化到DB中，一個資源層面的資訊管理平臺就基本成型了。但是，資訊固化不是目的，也沒有價值，只有資訊動態流轉起來才有價值（跟貨幣一樣）。接下來我們可以做的事情：

1、基於這些資訊進行流程規範的建設，比如伺服器的上線、下線、維修、裝機等流程。同時，流程過程中狀態的變更要同步管理起來。

2、拓撲關係的視覺化和動態展示，比如交換機與伺服器之間的級聯關係、狀態（正常or故障）的展示等，這樣可以很直觀的關注到資源節點的狀態。

至此，從資源維度的資訊梳理，以及基於這些資訊的平臺和流程規範建設也算是基本成型了。這個時候，以伺服器簡單示例，我們的視角是下面這樣的：

二、應用配置管理是面向應用的管理，是運維的核心

上面說明了CMDB的基礎資訊部分，如果從傳統的SA運維模式，這些資訊已經足夠，但是從應用運維的角度，這些就遠遠不夠了。這時我們就需要一個非常非常重要的控制代碼——應用名，或者叫應用標示。這時，應用運維裡面最最重要的一條聯絡也就產生了——“應用名—IP“的關聯關係。（注：這裡也可以是定義的其它的唯一主機標示，如主機名、容器ID等等，因為我們使用的方式是IP，所以這裡就以IP示例）

之所以說應用名和應用名-IP關聯關係非常重要，是因為它的影響力不僅僅在運維內部，而是會一直延伸整個技術架構上，後面的文章，我們介紹到的所有的平臺和系統建設，都會跟這兩個概念有關。

CMDB是IP為標示的資源管理維度，有了應用名之後，我們後面就是以應用為視角的管理維度了。首先看一下應用會涉及到的資訊：

1、應用基礎資訊，如應用責任人、應用的Git地址等

2、應用部署涉及的基礎軟體包，如語言包（Java、C++、GO等）、Web容器（Tomcat、JBoss等）、Web伺服器（Apache、Nginx等）、基礎元件（各種agent，如日誌、監控、系統維護類的tsar等）

3、應用部署涉及的目錄，如運維指令碼目錄、日誌目錄、應用包目錄、臨時目錄等

4、應用執行涉及的各項指令碼和命令，如啟停指令碼、健康監測指令碼

5、應用執行時的引數配置，如Java的jvm引數，特別重要的是GC方式、新生代、老生代、永生代的堆記憶體大小配置等

6、應用執行的埠號

7、應用日誌的輸出規範

8、。。。。。。。

我們梳理完上述資訊後就會發現，這些資訊跟CMDB裡面的資源資訊是完全兩個維度的東西，所以從資訊管理維度上講，資源配置和應用配置分開會更清晰，解耦之後也更容易管理。

好了，按照上面CMDB說的套路，梳理完成後，就是要進行資訊的建模和資料的固化，這時就有了我們的——應用配置管理。再往後，就是基於應用配置管理的流程規範和工具平臺的建設，這就涉及到我們經常說的持續整合&釋出&交付，監控、穩定性平臺、成本管理等等。

從應用的視角，我們配置管理，應該是下面這樣一個檢視（簡單示例，不是完整的）：

三、CMDB和應用配置管理的關係

有了資源配置資訊和應用配置資訊，這兩個資訊應該怎麼統一管理起來呢。直接上圖：

至此，CMDB和應用配置管理的分層分解就完成了，應用名關聯著應用配置資訊，IP關聯著資源資訊，二者通過應用名-IP的對應關係，聯絡到一起。

CMDB是運維的基石，但是要發揮更大的價值，光有基礎是不夠的，我們要把更多的精力放到上層的應用和價值服務上，所以我才會講應用才是運維的核心。我們可以看到，如果僅僅基於CMDB的資源資訊作自動化，最多隻能做出自動化的硬體資源採集、自動化裝機、網路-硬體拓撲關係生成等資源層面的工具，這些工具只會在運維層面產生價值，離業務還很遠，就更談不上能給業務帶來什麼價值了。但是基於應用這一層去做，就可以做很多事情，比如持續整合和釋出、持續交付、彈性擴縮容、穩定性平臺、成本控制等等，這些事情，帶來的價值就會大大不同，這些後續會一個個介紹出來。

原文來自微信公眾號：Forrest隨想錄

作者：趙成，出生成長於山東，生活工作在杭州，現蘑菇街運維負責人，2008.5-2014.12在華為公司，歷經傳統電信級軟體產品測試、開發和運維工作，後來有幸完整地經歷了一個網際網路業務，學到了很多，確切的講是很多做人做事地東西，從華為出來後，投身網際網路浪潮，浪的挺happy。