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

那麼在這種量變引起質變的挑戰中，運維人員應該發揮怎樣的作用，才能適應新業務的挑戰呢？

筆者之前曾就職於 IBM Cloud 部門，現在就職於滴滴運維部，長期從事自動化運維方面的工作，下面就結合自己之前的經驗和目前的工作，談一下自己的一些見解。

一、來自業務的挑戰

無論是在滴滴還是在之前的部門，在業務發展的初期階段，都不可避免的經歷了粗獷型的擴張階段，比如業務量指數級上升，使用者量急劇增加，每時每刻都有服務模組的迭代。

在業務優先的前提下，運維人員承擔著巨大的運維壓力。

以監控為例，使用者新增監控不規範，會造成報警頻發，報警有效性不足，導致的後果就是容易讓真正有價值的報警湮沒在海量資料中，同時也會造成對報警資源的浪費。

比如，研發同學不區分測試和線上環境，隨意的新增報警採集指標，會對監控系統的儲存和查詢帶來極大的挑戰。

再比如，部署系統，不按照規範在高峰期更新服務，一旦出問題，會造成整個應用的服務不可用。這樣的例子有很多。

二、如何應對

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

我們想到的解決方法就是“資料說話”，儘可能的去量化監控、部署及基礎元件（MySQL, Codis, ZK）的使用。然後用數字去指導研發的同學，儘可能的去匹配我們給出的“最佳實踐”，從而減少造成線上業務不穩定的隱患。

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

“資料驅動”的難點有三個方面：

1. 首先是如何獲取資料？這是“風險量化平臺”的基礎。使用監控系統，部署一個服務，執行一次配置變更，都是一個個使用者操作，很難用數字去表達。為此我們結合運維經驗，基於對操作每個步驟的詳盡輸出，儘可能的去用數字來衡量使用者操作。比如以部署為例，會以灰度釋出中間的暫停時間是否滿足一定時長，是否有在上線高峰期操作記錄，部署過程中是否執行了 double-check，在哪個階段執行了回滾等等，來形成一個個的打分項。

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

3. 各個量化專案佔據不同的權重（如下方的監控健康分剖析圖）， 比如我們根據滴滴目前的服務特點，存活指標占比 40%， 報警有效性佔比 30%，推動業務去收斂報警，和完善監控。我們監控健康分以 80 分為及格線，尋找出監控漏洞，並指導使用者加以改進。 用這樣的方法，我們可以讓研發同學儘可能的減少漏配監控的事情發生，提高線上服務的穩定性。

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

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

三、效果如何

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

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

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

四、未來展望

對於未來的展望，首先希望能對儘可能多的涉及線上操作的內容進行風險量化，比如業務使用的中介軟體／基礎元件，業務中涉及安全的服務是否遵循了相應的規範，是否有密碼／資料洩漏風險。

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

最後是如何去驅動，將我們總結的資料價值，最大化的發揮出來。

本文作者：張健