解構魅族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年後,其實也是伺服器換代完成後,則走伺服器下線報廢流程即可。
五、後續發展和演進
-
許可權進一步優化,提高資料準確率
-
資料採集方案更完整和智慧
-
流程化管理資料,效率提高的同時資料更準確
-
元資料異常巡檢的規則更詳細和完整
-
元資料異常修復更自動化