摘要：所以，滴滴運維部推出了風險量化平臺，包含變更信用分用來度量服務的變更操作，比如服務部署上線，配置變更等監控健康分用來度量用戶對報警監控的使用，從而打造一個看得見的手，驅動業務同學來一起提高線上穩定性。

出品 | 滴滴技術
作者 | 張健

在大家的印象中，運維人員更多的是從屬業務的角色。在傳統的企業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數量隨著變更信用分的提高在穩步下降。考慮到同時期的變更數量也在一直增加，這種下降趨勢就更加明顯了。

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

四、未來展望

對于未來的展望，首先希望能對盡可能多的涉及線上操作的內容進行風險量化，比如業務使用的中間件／基礎組件，業務中涉及安全的服務是否遵循了相應的規范，是否有密碼／數據泄漏風險。

其次，我們仍然需要對已有的運維經驗進行總結，結合經驗，利用量化分數去構建“最佳實踐”，指導大家去遵守。

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