前聚美優品運維負責人：CMDB的那些事兒

本文根據張川老師在〖2017 Gdevops全球敏捷運維峰會成都站〗現場演講內容整理而成。

講師介紹

張川，前聚美優品運維負責人。任職聚美優品四年間，負責運維自動化系統、監控系統及網站系統架構的優化與重構。主導設計並參與建設運維平台，推動完成了整個運維團隊從工具化、人工化到平台化的過渡。同時，在公司的多次大促活動中（瞬時並發達到平時幾十倍），保證各業務線系統的穩定。

分享大綱：

什麼是CMDB

CMDB的表現形式與現狀

怎樣管理與設計CMDB

關於CMDB的一些構想

一、什麼是CMDB

CMDB大家並不陌生，在運維的工作中幾乎都會用到CMDB，在聚美內部我們也稱它為資產系統，管理整個伺服器的資產，當然也包括一些配置上的變更。

二、CMDB的表現形式與現狀

這個截圖可能算是聚美優品第一版的CMDB，這是剛進公司，我們在做第一版監控系統時（那時用的是Nagios），通過這個去管理資產信息，再通過用腳本去讀取這個文件，最後生成報警配置，這樣我們管理監控時只需要修改這個文件，最後再執行腳本就可以達到監控變更的目的。

上面的圖是Ansible的CMDB模塊，這是官網上的截圖，大概的原理就是基於hosts文件裡面的主機信息，生成相應的資產信息，大家可以看到，這裡的信息已經比較豐富了，包括硬體及系統相關的一些信息，而且顆粒度已更細緻。

CMDB的表現形式非常多，上面只是舉了兩個例子。很多時候大家可能都沒有意識到我們在使用它，我再舉個例子，早期的時候，大家或許有過這樣的經歷，我們用excel去管理伺服器信息，這其實也可算做是CMDB的表現形式之一，只是這種方式的對象是人，而非某個系統。

這類的方式都有一個比較大的問題。大家可以從上面的例子看到，監控系統和自動化系統的CMDB其實是隔離的，CMDB是沒有辦法去做到統一修改的，所以在變更了監控系統相應配置之後，自動化系統是不會生效的，我們又要單獨的去變更自動化系統的信息，導致額外的維護成本，所以很多時候我們面臨的都是這樣一個現狀——有多套CMDB並存。

在開始做CMDB之前，理想是美好的，希望CMDB是中心化的，就像這張圖所表達的一樣，如果說整個遠維平台是一個大樹的話， 那麼CMDB就相當於這顆樹的樹榦和樹根，有著非常重要的作用，而其它子系統，像是監控系統，自動化系統，還有業務相關的一些系統等就像樹的樹枝和樹葉，大家互相依存，在CMDB上面做任何的變更之後，其它周邊的一些系統能夠立馬知道，而且同時能將這些變更應用到具體的場景上。

三、怎樣管理與設計CMDB

在設計CMDB之前， 我首先會從運維的角度去考慮，怎麼去管理這個系統，讓系統更易於維護和管理，所以在設計之前必須先問一個問題：怎麼去管理？那首先就要知道需要去管理哪些信息，也就是說哪些信息應該放到CMDB裡面，這些信息的我們對它怎樣進行分類 。另外一個就是這些信息對我們後續的一些系統的建設能夠提供什麼樣的一個價值。

第二個就是怎樣去保障這個數據的準確性。要保證數據準確性有兩種：一個是我們在線上跟線下數據的同步，線下數據跟線上數據保持一致，前期要不停地盤點，到做CMDB的時候，這些數據才能用起來。第二個一定要避免人工干預，這個可以通過一些自動化的手段和中心化CMDB相結合達到這個目的 。

前面提到了在CMDB的信息管理裡面需要管理哪些信息。信息的分類，我的理解，大致可分為兩種，一種是可變信息，另外一種是固定信息。固定信息的，很多數據都可以通過一些程序，或者是自動化的手段進行自動的錄入，幾乎是不會變的，但需要有一個比較好的規範，比如像機房或者交換機這樣一些信息，自動化工具是抽取不出來的，所以我們採用了一個變通的方法，統一交換機的命名規範，統一採用機房+機櫃的命名規範，然後通過腳本抓包的方式把網路結構還原出來。如果主機也是基於這樣的規範命名的話，甚至還可以把機櫃還原出來。

可變信息是構成CMDB生命最重要的信息，有了這些信息才讓資源真正有了相應的歸屬。人員的信息，包括像聯繫方式的等信息，主要是為監控系統提供相應的數據，狀態信息包括資源上線狀況、下線狀況，主要是為自動化上線提供相應的信息，環境信息包括生產環境還是測試的環境，主要是為監控系統及自動化系統提供相應的信息，項目信息在跟一些業務系統做一對接時時非常重要的，比如說業務系統需要知道某一個項目有哪一些IP都需要從這裡面取數據，同時也是自動化系統的支撐，有了項目歸屬，伺服器才知道應該去做哪些部署。

CMDB在設計的過程中，我覺得是比較重要的是自動化的系統跟CMDB系統的結合。首先，在一個資源交付之後，可以通過一些裝機和初始化的腳本去調用CMDB的介面，這樣機器的IP信息就會同步到資產系統的資源池裡面去，後續在領用這些資源時，可變信息就發生了變化，這時候就有項目的屬性，在我們的CMDB系統裡面就知道了這個機器到底是屬於哪一個項目，知道了屬於哪個項目，然後才能明確後續需要進行哪些操作。

但是這個時候，我們的自動化系統是不知道項目信息的，所以需要通過CMDB API去拿到項目等相關的信息，我們使用的是Saltstack，簡單的說，就是將從CMDB獲取到的項目等信息來更新我們的grains，這樣自動化系統在後面進行業務部署的時候，才知道應該做什麼操作。同時這個時候，自動化系統還會將自己讀取到的固定信息，通過調用CMDB API，將這些信息刷入資產系統，完成整個信息的完善， 這樣就實現自動化系統和CMDB系統的聯動。

之前提到，很多時候我們其實都是面對的多套CMDB並存的情況，在我們運維平台開始設計時，由於像自動化系統、監控系統這些系統本身就是基於CMDB開發的，所以直接讀取相應的一些存儲數據就好，或者也可以通過CMDB的API進行聯動，但是由於其它系統的CMDB是獨立的，比如發代碼時要改發布系統的CMDB信息，這樣話可能在操作上面難免會有一些失誤。所以為了解決這樣的問題，我覺得一個比較好的辦法的話就是把CMDB的一些信息同步到配置服務裡面去，比如說像ZooKeeper，etcd裡面，同步進去之後，如果是其它系統要用的時候，再把的信息拿出來，對它進行處理。這樣的話基本就可以達到一次變更，所有生效的目的，實現了中心化CMDB，集中化信息管理的目標。

前面講的更多的是偏實現的一些東西，下面主要想聊下關於展示相關的一些東西，前面提到在做CMDB之前要首先考慮CMDB的價值在哪裡？一是支撐我們整個運維平台的建設，盡量做到自動化，中心化的管理，這個是介面層的價值。展示層的價值在哪裡呢，上面的這個截圖是我們一個子功能的截圖，通過這樣一個展示就很方便地知道我現在的物理伺服器，虛擬機等的比例是多少，亦或者可以知道我們每個機櫃的容量是多少，只要數據是準確的，有價值的，基於這些數據，我們就可以做出非常多的組合。

四、關於CMDB的構想

關於CMDB的一些構想，在很多時候，大家可能都會面臨過這樣的情況，就是一個同事可能有多個的賬號，比如說公司的電腦登錄賬號，公司郵箱賬號等，這些信息如果按CMDB的定義去看理解的話，可能不能稱它為CMDB，但是我認為也可按CMDB中心化方式去管理，將存儲層打通起來。比如代碼倉庫，郵箱賬號，伺服器登錄等都可以通過openldap去做統一的數據存儲，這樣在發生人員變更的時候，就可以做到一處變更多處生效的目的，而不需要過多的人工干預。

但這個方案也有一個缺點，會存在一定安全隱患，因為如果數據層都打通的話，如果發生密碼泄漏，其它的項目自然會面臨同樣的風險，因為各個系統的密碼都一樣了，所以最好是能再加一層雙因子驗證，保證信息的安全性。

CMDB的價值

從我自己的理解，運維的工作很多時候都涵蓋在這三個領域裡面，穩定是最重要的，第二個是效率，然後是成本。CMDB在哪個地方可以體現它的價值呢？我個人認為在成本這一塊能力體現非常大的價值，上面提到的固定信息裡面，包括了硬體，系統等信息。而成本，我理解也是一個固定信息，比如說我們可以根據CPU和內存去推算我的這個月這台伺服器支出是多少，有了這些數據就可以得到每個月的機房支出 。

有了這些信息後，比如說我們的伺服器資源通過監控系統查看這個月已經跑得非常滿了，下個月找老闆我要買伺服器，但沒有數據支撐的話，直接給老闆說買50台機器是沒有任何說服力的，實際上用CMDB也可以做這個事情 。伺服器價都是可以推算的，甚至還可以通過爬蟲去爬取網上的一些報價信息，在當月資源不夠用時，需要增加時，可以提取出來告訴老闆，就知道需要多少成本預算了。

第二的話是效率，如果是在開始設計CMDB之前，我們就按照之前中心化的思路去做CMDB話，有很多信息就不需要多處去變更了，從這個維度來說，也就提高了我們的效率，提高效率的同時也就保證整個系統的穩定，因為人工操作難免都會出現一些問題的。

最後引用小米提出來的這個概念，NOOPS，我們可以通過把所有的系統打通起來，去幫助研發提高他們的效率，比如說他們涉及資源使用時可以通過工單系統去申請資源，經過審批之後，自動交付資源，發布代碼，上線後可以通過業務監控獲知業務的狀態，達到一個自主上線的狀態，當然這中間還是需要人工做干預，不過這個干預更多的就是流程上的審批，目前這也是我們努力的方向。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！