解構魅族CMDB運維自動化演進歷程
一、運維自動化發展歷程
隨著移動網際網路的發展，運維平臺的架構也在不斷演進和優化，給運維人員帶來了諸多挑戰：
-
首先從質量上看，不管是硬體還是架構，由於監控體系不完善，導致覆蓋率低，監控易出現漏報、誤報；
-
從專案上看，業務的快速發展，導致對資源的需求量高，但由於未能將流程和自動化結合起來，人工參與較多，效率相對低下；
-
從成本上看，平臺不能記錄交付資源及回收資源等，使流程不完善，工作變得不透明。
運維一直處在填坑、救火、背鍋階段。固此，今天我將從質量、成本、安全、效率四個維度來衡量運維人員的價值。
以價值為導向，我們建設了：
-
資源管理平臺： 這其中包括CMDB、KVM雲平臺以及容器平臺。
-
配置管理平臺： 我們建設了DNS、LVS、CDN管理平臺，提高配置操作的高效率。
-
自動化平臺： 這其中包括髮布平臺、工單平臺以及巡檢平臺。釋出平臺主要應對產品迭代釋出的需求，提高效率；工單流程平臺，主要是把生命週期所有的流程實現自動化；巡檢平臺，主要是做伺服器初始化資源交付的巡檢。
-
監控容量平臺： 我們做了基礎監控、業務監控、容量系統。容量系統主要資料來源是從監控取的，在年度預算或者季度預算時，把容量系統的資料拉出來，針對不同的業務判斷資源利用率是否符合標準。
-
安全平臺： 包括堡壘機、漏洞系統、自研WAF系統。
我們通過以上管理平臺和自動化運維平臺，來對我們線上的業務進行管控，提高業務可用性，提高工作效率，確保業務的安全。
二、CMDB與運維繫統的關係
下圖是CMDB與運維繫統的關係圖：
從圖中我們可以看出，CMDB是周邊所有運維繫統的場景互動資料來源，所以確保CMDB元資料的準確率至關重要。
三、CMDB運維的痛點
1、許可權管理混亂
運維人員以前都是超級管理員，他們對CMDB平臺所有的資源屬性有許可權進行修改，自然會有資料不準確的風險。
2、生命週期沒有流程化、自動化
這體現在早期所有流程的運轉，包括CMDB資料的變更，因多數是使用郵件完成，沒有流程把控，也沒有實現自動化，效率比較低。
3、資料不準確，資料質量沒辦法保證
CMDB元資料早期錄入不太完善且資料沒有校驗完整。
4、變更資訊維護效率低，資產變更需要更多人為操作
主要表現在當伺服器遷移的時候，需要刪除CMDB資料再重新錄入，主要帶來的人工操作較多，效率低下。
5、異常資料的發現和修復
不論是手工錄入還是自動化採集，資料肯定均會有不準確的情況發生。早期業務運維或者基礎職能部門使用過程中都是自己發現異常資料，在進行修復，資料的準確性沒法確保。
針對這些痛點我們總結出了三個維度：平臺運維效率低、平臺數據質量低、流程未標準化。
四、CMDB運維自動化實踐
基於上文的痛點，CMDB做了如下事宜：
1、CMDB模型和標準
自動化的前提必然是標準，我們先看看定義的相關標準：
-
裝置分類： 伺服器、虛擬子機、路由器、交換機等；
-
裝置屬性： 型號、廠商、序列號等；
-
業務標準： 業務樹模型：城市-機房-業務-容器-模組；產品樹形態；
-
裝置操作： 狀態變更、業務變更、裝置回收、裝置下架等操作。
2、CMDB資料管理
資料管理分兩個維度，裝置的固定資訊和裝置的可變資訊。
固定資訊正常情況下不會改變，比如裝置位置不變更，裝置系統不進行重灌等等；上圖右側為固定資訊，包括裝置硬體資訊、網路資訊、物理位置資訊、系統資訊等。上圖中左側是裝置的可變資訊，包括使用者資訊、狀態資訊、業務資訊。
那麼裝置的固定資訊和可變資訊是怎樣採集和維護的呢？
CMDB的資料管理，主要是通過自動化和流程化來實現資料的變更和維護操作。
例如硬體資訊，可以使用自動採集識別；業務的狀態變更，業務上線，可以通過流程進行實現，不用人為操作資料；人工協助操作進行資料的維護操作，這主要體現在初始化錄入時，比如機房資訊。
3、CMDB實現的目標
有了CMDB的相關標準和資料管理的腦圖，我們看看我們CMDB需要實現的目標是怎樣的？
CMDB要實現的目標，也是基於痛點寫的目標：
-
減少使用者人工操作，提高工作效率；
-
提高元資料質量，確保資料準確率；
-
流程逐步標準化，操作儘可能流程化。
基於我們要實現的目標我們需要做哪些事情呢？
1）使用者許可權收斂
早期使用者許可權就針對功能模組進行授權，這樣使用者可針對此模組的資料進行變更操作，例如，伺服器管理授權使用者後，伺服器管理模組就可以對所有資源狀態和資源屬性進行修改，那麼就存在資料不準確的風險。
後續我們做了許可權收斂，收斂後包括功能模組授權、子功能模組授權、屬性操作明細授權等等，這樣就可以把許可權限制到最小，資料異常的風險降低到最小。
使用者許可權收斂後，那麼使用者怎麼去變更資料呢？通過流程化更新或者維護CMDB的配置資訊，便可以確保資料的準確性。
2）生命週期流程管理
這其中包括：
-
資產需求和採購。 包括需求的收集、需求的評估、需求的比對以及需求採購清單。
-
資產部署和排程以及業務上線。 例如，資產驗收、系統安裝、領用、業務上下線以及回收、備件調撥等。
-
伺服器生命週期流程末端。 包括資產退役、資產報廢。
生命週期流程管理所有的資料操作無論是查詢還是更改，必須都覆蓋CMDB。
3）流程管理自動化
上圖是簡單列舉的七個基於生命週期管理的流程，從需求的收集一直到伺服器退役，包括伺服器採購流程、領用流程、業務日常申請、業務資源調撥、搬遷、回收、報廢流程，包含了生命週期各個階段。
黑色字型是對CMDB查詢的操作，紅色字型是對CMDB既查詢又做更新配置的操作。
下面列舉一個例子：
列舉業務日常申請流程：
從業務日常申請流程發起時，會填寫業務所屬的部門、機房、機型、數量、業務樹等，CMDB會自動判斷所在部門在某機房的某個機型是否有更多資源可用：
-
如果資源池不滿足，就需要領用流程，到公共資源池領用，領用到相應部門資源池下。資源池的定義指某一個業務樹下，狀態是待運營或是待上線狀態，都算作資源池。
-
當資源池的數量滿足後，便進入審批階段，審批需要判斷是否有季度預算，及容量池裡的資源利用率是否都是平均或者達到某一個百分比。如果容量系統裡資源利用率很長段時間都保持在30%以下，那這個資源也不能申請。
審批通過後，下一個節點是劃撥資源交給開發，在這個稽核節點裡做了一些操作：
首先是查詢，主要查詢的是機房、機型、產品資源池數量、狀態、IP地址；把資源劃撥出去後，CMDB有些配置要更改掉，比如業務樹，會自動修改為在需求提交階段填寫的業務樹，狀態會自動修改為由待運營或者待上線修改為運營中，產品資源池數量會減少。
通過上述圖中的流程管理與自動化方法，我們做了十幾個標準流程，實現了對CMDB多個欄位的查詢和配置更新操作。但這個流程後期也會根據業務需求，迭代、優化或新增。
4）資料自動採集
通過自動化配置平臺，把提前寫好的自動採集Agent推送到每一臺伺服器，同對伺服器是否有部署這個Agent進行巡檢，定時推送和拉取，確保所有上線資源都有資料採集的操作。最後上傳到CMDB中，進行配置比對。
每個廠商伺服器的採集工具都不一樣，針對伺服器採集，魅族主要用了以下工具：
我們採集的資料較詳細，比如記憶體插槽、SN號、配置主頻等等；採集這塊遇到較多的坑就是raid卡和磁碟的資料採集了，要判斷cpu架構、raid卡、直連卡、品牌等等，根據條件使用不同的採集工具；通過自動採集，我們提高了資料準確率及工作效率。
目前魅族已經實現了30多個數據的自動採集，採集Agent端的自動巡檢以及資料採集資訊定時監測操作。
5）資料異常巡檢-規則
人工錄入或者流程化管理、自動採集，並不代表資料的準確率都很高，所以我們繼續做了一個數據的異常巡檢。
6）資料異常巡檢-進階之路
早期資料異常通過人工發現，人工修復；然後做了資料異常巡檢自動化，自動發現異常，人工修復；此時我們發現人工修復的效率太低，陸續做了異常資料的自動修復。
現階段我們做了13種異常巡檢規則，5種資料異常修復，後續還會持續的定義巡檢標準和修復方案；另外還做了元資料錄入CMDB規則化，這個作為資料初始化錄入關口，一定要標準化，如果這裡沒有標準化，沒有強制性，後續資料必然就不準確。
最終我們要實現的目標就是實現異常資料巡檢更全面，異常修復更自動化。
7）資源池管理-資源入池流程
資源入池的流程，首先是需求申請階段，需要填寫部門資訊、機房、機型、數量、業務樹等，然後是需求評估階段，此時就需要評估預算是否合理，資源利用率是否正常等，評估通過後就是採購和交付階段了。
在資源交付完成後，此時資源就會根據需求申請階段的部門資訊，自動的寫入到相應部門的資源池中，此時對應的業務和開發就可以進行業務的上線操作了。
在資源入池的過程中，公共資源池的數量會減少，產品資源池的數量會增加。
8）資源池管理-策略
公共資源池即某個業務樹下，狀態為某幾種的資源的總和；部門資源池即是通過上述的“資源入池流程”，根據入池後打的tag來自動統計；虛擬機器資源池的資料跟雲平臺API實現，主要是確保資料的一致性。
資源池認領率，主要是通過申請階段填寫的資料和最後認領的資料的比對，得出資源認領率。假如認領率較低，那麼下次預算申請時，此業務的信用度會降低，需求稽核嚴格一些。
9）維保管理-策略
我們預設伺服器採購完畢後3年維保，當伺服器上線使用3年後，伺服器進入待續保狀態，此時的續保策略可以按兩個維度來評估，首先按部件維度，這個維度需要考慮部件的故障率，比如磁碟故障率高，記憶體故障率低，那麼在做續保的時候，考慮磁碟的備件多采購，記憶體的部件少採購一些。
另外一個維度就是整機續保維度，這個維度的成本預算可能會稍高一些，當然還需要考慮伺服器的使用價值等等，比如採購時候針對A業務，3年後A業務的效能要求高，此機型滿足不A業務了，那麼就需要考慮給測試環境或者其他效能要求不高的業務使用了，測試環境則就不需要續保了。
當伺服器使用4年後，伺服器為待換代狀態，則會推送郵件清單至業務運維側，讓業務運維提前規劃，後續做預算的時候考慮換代的這批伺服器；當伺服器使用5年後，其實也是伺服器換代完成後，則走伺服器下線報廢流程即可。
五、後續發展和演進
-
許可權進一步優化，提高資料準確率
-
資料採集方案更完整和智慧
-
流程化管理資料，效率提高的同時資料更準確
-
元資料異常巡檢的規則更詳細和完整
-
元資料異常修復更自動化