前聚美優品運維負責人：CMDB的那些事兒
講師介紹
張川，前聚美優品運維負責人。任職聚美優品四年間，負責運維自動化系統、監控系統及網站系統架構的優化與重構。主導設計並參與建設運維平臺，推動完成了整個運維團隊從工具化、人工化到平臺化的過渡。同時，在公司的多次大促活動中（瞬時併發達到平時幾十倍），保證各業務線系統的穩定。
分享大綱：
- 什麼是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，我們可以通過把所有的系統打通起來，去幫助研發提高他們的效率，比如說他們涉及資源使用時可以通過工單系統去申請資源，經過審批之後，自動交付資源，釋出程式碼，上線後可以通過業務監控獲知業務的狀態，達到一個自主上線的狀態，當然這中間還是需要人工做干預，不過這個干預更多的就是流程上的審批，目前這也是我們努力的方向。
文章來自微信公眾號：DBAplus社群