運維平臺信用分——滴滴內部的數據驅動實踐

出品 | 滴滴技術

做者 | 張健

在你們的印象中，運維人員更多的是從屬業務的角色。在傳統的企業IT中，沒有快速的產品迭代，沒有天天成百上千次的服務發佈和伸縮容，這樣的角色看似沒有問題。但在現在的 DevOps 時代，平常的運維工做中天天要應對成百上千次的服務發佈與線上操做。若是運維人員（即SRE）仍然只是被動的去應對這種變化，所形成的結果，必然是疲於應付，最終會對全平臺的業務穩定性形成很大隱患。

那麼，在這種量變引發質變的挑戰中，運維人員應該發揮怎樣的做用，才能適應新業務的挑戰呢？筆者以前曾就任於IBM Cloud部門，如今就任於滴滴運維部，長期從事自動化運維方面的工做，下面就結合本身以前的經驗和目前的工做，談談本身的一些看法。

一. 來自業務的挑戰

不管是在滴滴仍是在以前的部門，在業務發展的初期階段，都不可避免的經歷了粗獷型的擴張階段，好比業務量指數級上升，用戶量急劇增長，每時每刻都有服務模塊的迭代。

在業務優先的前提下，運維人員承擔着巨大的運維壓力。以監控爲例，用戶添加監控不規範，會形成報警頻發，報警有效性不足，致使的後果就是容易讓真正有價值的報警湮沒在海量數據中，同時，也會形成對報警資源的浪費，好比，研發同窗不區分測試、線上環境，隨意的添加報警採集指標，會對監控系統的存儲，查詢帶來極大的挑戰。再好比部署系統，不按照規範，在高峯期更新服務，一旦出問題，會形成整個應用的服務不可用。這樣的例子有不少。

二. 如何應對

若是上述的問題一直延續下去，運維工做必然帶來巨大的挑戰，而且會嚴重影響線上服務的穩定性。面對這些問題，滴滴運維團隊的同窗也在一塊兒思考，運維應該不只僅去被動的適應業務，而是要從平臺穩定性出發，去指導研發同窗，如何規範的執行變動，如何合理的使用監控資源以及其它公司IT基礎設施。

咱們想到的解決方法就是「數聽說話」，儘量的去量化監控、部署及基礎組件（MySQL, Codis, ZK）的使用。而後用數字去指導研發的同窗，儘量的去匹配咱們給出的「最佳實踐」，從而減小形成線上業務不穩定的隱患。

因此，滴滴運維部推出了「風險量化平臺」，包含「變動信用分」（用來度量服務的變動操做，好比服務部署上線，配置變動等）、「監控健康分」（用來度量用戶對報警監控的使用），從而打造一個「看得見的手」，驅動業務同窗來一塊兒提升線上穩定性。

| 數據驅動的難點有三個方面

首先是如何獲取數據？這是「風險量化平臺」的基礎。使用監控系統，部署一個服務，執行一次配置變動，都是一個個用戶操做，很難用數字去表達。爲此咱們結合運維經驗，基於對操做每一個步驟的詳盡輸出，近可能的去用數字維度來衡量用戶操做。好比以部署爲例，會以灰度發佈中間的暫停時間是否知足必定時長，是否有在上線高峯期操做記錄，部署過程當中是否執行了double-check，在哪一個階段執行了回滾等等，來造成一個個的打分項。

其次是如何去制定風險量化的標準，也就是如何用各個指標去構造一個最佳實踐。這更像是一個數學建模，裏面涉及到大量的運維經驗積累，以咱們新推出的監控健康分爲例，咱們遵循着「有服務必有監控，有報警必須處理」的原則，對於每一個服務，要求衡量的標準包括，是否有存活指標監控（進程、端口等）；是否有基礎指標監控（如cpu.idle，mem.used, disk.used）；是否添加了上下游監控，報警是否有效，即報警接收人是否過多（由於你們都收到報警，最終的結果，每每意味着你們都不會處理報警），報警是否被及時處理（運維領域也有MTTA， MTTR，即報警平均響應時間，和報警及時處理時間這樣的概念）；是否配置了監控大盤，方便咱們平常巡檢。

各個量化項目佔據不一樣的權重（以下方的監控健康分剖析圖）， 好比咱們根據滴滴目前的服務特色，存活指標占比40%， 報警有效性佔比30%，推進業務去收斂報警，和完善監控。監控健康分以80分爲及格線，尋找出監控漏洞，並指導用戶加以改進。 用這樣的方法，可讓研發同窗儘量的減小漏配監控的事情發生，提升線上服務的穩定性。

最後的難點是如何驅動？這是咱們如今着力想的一個點。風險量化實際上就是總結前人踩過的坑，趟過的雷，去告訴後面的同窗，提早來規避風險，這是運維部門對公司業務穩定性的一大貢獻。

如今已有的作法是以下圖（各部門變動信用分排名圖）所示，經過計算、打分、全公司各個業務線排名，將風險量化數據和反應出的問題推送給各個業務線的leader。以競賽方式去推進各個業務線重視風險量化。咱們還計劃以監控健康分去驅動報警有效性的建設，完善報警值班制度，避免羣發報警又無人處理，報警配置不合理這種現象的發生。

                  

三. 效果如何

目前的風險量化體系包含「變動信用分」，「監控健康分」，其中變動信用分已經上線一年多了，在2018年，從下圖能明顯看到信用分在穩步上升。

帶來結果是什麼呢？ 下面是本年度故障case統計圖，能明顯的看到這種趨勢，故障case數量隨着變動信用分的提升在穩步降低。考慮到同時期的變動數量也在一直增長，這種降低趨勢就更加明顯了。

咱們指望其它的信用分機制，也能給業務穩定性帶來這樣積極的結果。

4、將來展望

對於將來的展望，首先但願能對儘量多的涉及線上操做的內容進行風險量化，好比業務使用的中間件／基礎組件，業務中涉及安全的服務是否遵循了相應的規範，是否有密碼／數據泄漏風險。

其次，咱們仍然須要對已有的運維經驗進行總結，結合經驗，利用量化分數去構建「最佳實踐」，指導你們去遵照。

最後是如何去驅動，將總結的數據價值，最大化的發揮出來。

• 張健，IBM Cloud 系統架構師，2018年加入滴滴，負責滴滴運維部devops平臺開發工做