????穩定性目前不再局限于大促時的保障和平時的穩定性輪值，越來越體系化。本文基于作者在業務團隊工作過程中的沉淀，以及在盒馬兩年SRE的實戰經驗，從穩定性心態、監控體系、故障應急體系、資源體系、大促保障機制、日常保障機制等幾個層面，就如何做好SRE的工作進行了分享。

前言

2013年，當我第一次接觸穩定性的時候，我是有些懵的，當時完全不知道穩定性是什么，也不清楚要做什么。在接下來的8年里，我先后在菜鳥、天貓、盒馬從事中間件、業務系統、架構等方面的工作，期間一直穿插著負責穩定性和大促的保障工作。我的心態，大致經歷過以下幾個階段：

• low：完全不懂，覺得穩定性就是做別人安排好的一些表格和梳理，不知道自己該做啥，穩定性好low。
• 煩：各種重復的會議，做好了是應該的，做不好就是責任，很煩很焦慮。
• 知道該做什么，但是累：各種報警和風險，每天需要擔心，想要不管又過不了自己心里那關;大促時候天天熬夜，各種壓測，最終自己累得夠嗆。
• 發現結合點：發現在采用系統化思維之后，穩定性與系統自身的結合變得緊密，穩定性成為一種基線，找到了穩定性中的關鍵點和重點。
• 主動驅動：發現線上業務和線下業務的穩定性差別，理解并主動調整在不同業務團隊采取的穩定性策略，探究在穩定性中的自動化、工具化，系統化建立穩定性機制。
• 形成體系：形成穩定性體系化思考，明確穩定性每一個點在業務團隊大圖中的位置，探究系統彈性建設。

近兩年來，穩定性不再僅僅局限于之前的大促保障和平時的穩定性輪值，越來越體系化，在保障體系、監控體系、資源體系、質量保障、變更管控等多個方面，越來越系統。阿里的各個事業部，也紛紛成立專職的SRE安全生產團隊。然而仍有很多人和業務團隊，對于穩定性的理解和認知未形成一個體系化的機制，下面就結合我在業務團隊系統穩定性上的認識，以及最近2年在盒馬的一些思考，做一個分享。

什么是SRE

SRE(Site Reliability Engineering，站點可靠性/穩定性工程師)，與普通的開發工程師(Dev)不同，也與傳統的運維工程師(Ops)不同，SRE更接近是兩者的結合，也就是2008年末提出的一個概念：DevOps，這個概念最近也越來越流行起來。SRE模型是Google對Dev+Ops模型的一種實踐和拓展(可以參考《Google運維解密》一書)，SRE這個概念我比較喜歡，因為這個詞不簡單是兩個概念的疊加，而是一種對系統穩定性、高可用、團隊持續迭代和持續建設的體系化解決方案。

那么要如何做好一個SRE呢，這是本文要探討的話題。

一 心態&態度

1 誰適合做穩定性?

就像前言里我做穩定性前期的心態一樣，穩定性最初上手，是提心吊膽、不得其門而入的，所以想要做好穩定性，心態最重要，業務團隊想要找到合適做穩定性的人，態度也很重要。對于業務團隊，要如何挑選和培養團隊中最合適做穩定性的人呢?

必須選擇負責任的人

負責任是第一要素，主動承擔，對報警、工單、線上問題、風險主動響應，不怕吃苦;一個不負責任的人，遇到問題與我無關的人，邊界感太強的人，難以做好穩定性的工作。

原則上不要選擇新人

對于團隊leader而言，“用新人做別人不愿意做的工作”，這個決定比較容易做出，但是這也相當于是把團隊的穩定性放在了一定程度的風險上，用新人做穩定性，其實只是用新人占了穩定性的一個坑而已。新人不熟悉業務，不了解上下游，最多只能憑借一腔熱血，對業務和系統感知不足，容易導致線上風險無法被快速發現、故障應急無法迅速組織。

不要用過于"老實"的人

這里的“老實”的定義是不去主動想優化的辦法，不主動出頭解決問題，但是很能吃苦，任勞任怨，也很能忍耐系統的腐爛和低效;這樣的人平時很踏實，用起來也順手，但是卻無法主動提高系統穩定性，有的時候反而會給系統穩定性造成傷害(穩定性就像大堤，不主動升級，就早晚會腐爛)。

2 業務團隊如何支持穩定性SRE人員

給資源

穩定性從來不只是穩定性負責人的事情，而是全團隊的事情，穩定性負責人要做的是建立機制，主動承擔，但是穩定性意識，要深入到團隊所有人腦子里，穩定性的事情，要能夠調動團隊一切資源參與。

給空間

做穩定性的人，往往面臨一個尷尬場景：晉升困難，主要是因為在技術深度和業務價值兩個方面，很容易被挑戰，對于業務團隊，一定要留給做穩定性的人足夠的思考和上升空間，將穩定性與團隊的技術架構升級、業務項目結合起來，共同推動。經過集團安全生產團隊的推動，目前在阿里，SRE已經有了自己專門的晉升體系。

區分責任

當出現故障時，區分清楚責任，到底是穩定性工作沒有做到位，還是做到位了，但是團隊同學疏忽了，還是說只是單純的業務變化。

3 開發和SRE的區別

都是做技術的，很多開發剛剛轉向負責穩定性時，有些彎轉不過來。

舉個例子：對于“問題”，傳統的開發人員更多的傾向于是“bug/錯誤”，而SRE傾向于是一種“風險/故障”，所以，兩者對“問題”的處理方法是不一樣的：

• 開發：了解業務 -> 定位問題 -> 排查問題 -> 解決問題
• SRE：了解業務歸屬 -> 快速定位問題范圍 -> 協調相關人投入排查 -> 評估影響面 -> 決策恢復手段

可見，開發人員面對問題，會首先嘗試去探究根因，研究解決方案;而SRE人員首先是評估影響，快速定位，快速止損恢復。目標和側重點的不同，造成了SRE思考問題的特殊性。

所以，成為一名SRE，就一定要從態度和方式上進行轉變，切換到一個“團隊穩定性負責人”的角度上去思考問題。

4 SRE心態上的一些釋疑

下面這些疑惑，有很多是我最初做穩定性的時候面臨的問題，這里給大家分享和解釋一下我的解決方法：

疑惑1：做好了是應該的，出了問題就要負責任

不出問題，就是穩定性的基線，也是SRE的基本目標，所以這個話雖然殘酷，但是也不能說錯，關鍵在于：你要如何去做。

如果抱著一個“背鍋” / “打雜”的思想去做穩定性，那么“做好沒好處、做不好背鍋”這句話就會成為擊垮心理防線的最重的稻草。

應對這種心態的最關鍵一點，在于“做好”不出問題這條基線，要從下面3個方面去做：

(1)及時、快速的響應

這是最關鍵的一點，作為一個SRE，能夠及時、快速的響應是第一要務，遇到報警、工單、線上問題，能夠第一時間沖上去，不要去問是不是自己的，而是要問這個事情的影響是什么，有沒有坑，有沒有需要優化的風險?這是對自己負責;

同時，快速的響應，還需要讓你的老板第一時間知悉，這個不是在老板面前愛表現拍馬屁，而是要讓你的老板第一時間了解風險的發生，一個好的團隊leader，一定是對質量、穩定性和風險非常敏感的leader，所以，你要將風險第一時間反饋。這是對老板負責。

反饋也是有技巧的，不僅僅是告知這么簡單，你需要快速的說明以下幾個信息：

• 盡快告知當前告警已經有人接手，是誰接手的，表明問題有人在處理了(這一步叫“響應”)。
• 組織人員，快速定位問題，告知問題初步定位原因。(這一步叫“定位”)
• 初步影響范圍是什么?給出大致數據。(這一步方便后面做決策)
• 有哪些需要老板、產品、業務方決策的?你的建議是什么?(這一步很關鍵，很多時候是：兩害相權取其輕，你的評估和建議，直接影響老板的決策)
• 當前進展如何，是否已經止血?(這一步是“恢復”，要給出“進展”，讓決策者和業務方了解情況)

需要注意的是：如果你響應了，但是沒有及時的同步出來，等于沒響應，默默把事情做了，是開發者(Dev)的思維，作為SRE，風險和進展的及時組織和通報，才是你應該做的。

當然，你的通報要注意控制范圍，最好優先同步給你的主管和產品進行評估，避免范圍過大引起恐慌，要根據事情的嚴重程度來共同決定，這是對團隊負責。

及時、快速的響應，是保證不出問題的關鍵，也是SRE人員贏得領導、業務方、產品和其他合作方信任的關鍵，贏得信任，是解決“做好沒好處、做不好背鍋”的基石。

(2)把機制建立好，切實落地

前面已經說過，“穩定性從來不只是穩定性負責人的事情”，這一點，要深入到團隊每個人的心里，更要深入到SRE自己心里，一人抗下所有，不是英雄的行為，在SRE工作中，也不值得贊許，很多時候一人抗下所有只會讓事情變得更糟糕。

作為一個SRE，想做到“不出問題”這個基線，關鍵還是要靠大家，如何靠大家呢?就是要落地一套穩定性的機制體系，用機制的嚴格執行來約束大家，這套機制也必須得到團隊leader的全力支持，不然無法展開，這套機制包括：

• 穩定性意識
• 日常值班機制
• 報警響應機制
• 復盤機制
• 故障演練機制
• 故障獎懲機制
• 大促保障機制

比如，如果總是SRE人員去響應報警和值班，就會非常疲憊勞累，人不可能永遠關注報警，那怎么辦呢?可以從報警機制、自動化、值班機制3個方面入手：

一方面，讓報警更加準確和完善，減少誤報和漏報，防止大家不必要的介入，另一方面產出自動化機器人，自動進行一些機器重啟，工單查詢，問題簡單排查之類的工作，還有就是建立值班輪班，讓每個人都參與進來，既能讓大家熟悉業務，又能提高每個人的穩定性意識。

對于SRE來說，指定機制并且嚴格落地，比事必躬親更加重要。上面這些機制，將在后面的章節中詳細論述。

(3)主動走到最前線

SRE工作，容易給人一種錯覺：“是做后勤保障的”，如果有這種思想，是一定做不好的，也會把“做好沒好處、做不好背鍋”這個疑惑無限放大。作為SRE人員，一定要主動走到最前線，把責任擔起來，主動做以下幾個事情：

• 梳理。主動梳理團隊的業務時序、核心鏈路流程、流量地圖、依賴風險，通過這個過程明確鏈路風險，流量水位，時序冗余;
• 治理。主動組織風險治理，將梳理出來的風險，以專項的形式治理掉，防患于未然。
• 演練。把風險化成攻擊，在沒有故障時制造一些可控的故障點，通過演練來提高大家響應的能力和對風險點的認知。這一點將在后面詳述。
• 值班。不能僅僅為了值班而值班，值班不止是解決問題，還要能夠發現風險，發現問題之后，推動上下游解決，減少值班中的重復問題，才是目標。
• 報警。除了前面說過的主動響應之外，還要經常做報警保險和機制調整，保證報警的準確度和大家對報警的敏感度。同時也要做到不疏忽任何一個點，因為疏忽的點，就可能導致問題。

疑惑2：穩定性總是做擦屁股的工作

這么想，是因為沒有看到穩定性的前瞻性和價值，如果你走在系統的后面，你能看到的就只有系統的屁股，也只能做擦屁股的工作，如果你走到了系統的前面，你就能看到系統的方向，做的也就是探索性的工作。

所以，要讓穩定性變成不“擦屁股”的工作，建議從下面2個方面思考：

(1)不能只做當下，要看到未來的風險，善于總結

暖曰：“ 王獨不聞魏文王之問扁鵲耶?曰：‘子昆弟三人其孰最善為醫?’扁鵲曰：‘長兄最善，中兄次之，扁鵲最為下。’魏文侯曰：‘可得聞邪?’扁鵲曰：‘長兄于病視神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于閭。若扁鵲者，镵血脈，投毒藥，副肌膚，閑而名出聞于諸侯。’魏文侯曰：‘善。使管子行醫術以扁鵲之道，曰桓公幾能成其霸乎!’凡此者不病病，治之無名，使之無形，至功之成，其下謂之自然。故良醫化之，拙醫敗之，雖幸不死，創伸股維。”

——《鶡冠子·卷下·世賢第十六》

與扁鵲三兄弟一樣，如果想要讓穩定性有價值，SRE同學一定不能站到系統的屁股后面等著擦屁股，必須走到前面，看到未來的風險。既要在發生問題時快速解決問題(做扁鵲)，也要把風險歸納總結，推動解決(做二哥)，還要在系統健康的時候評估鏈路，發現隱藏的問題(做大哥)。

1. 做扁鵲大哥：在系統健康時發現問題
2. 做扁鵲二哥：在系統有隱患時發現問題
3. 做扁鵲：在系統發生問題時快速解決問題

(2)自動化、系統化、數據化

SRE不是在做一種收尾型、擦屁股的工作，而是在做一種探索性、前瞻性的工作，但SRE不可避免的，會面對很多重復性的工作，所以除了要在組織和機制上做好分工，讓恰當的人做恰當的事之外，SRE人員要經常思考產品的系統化和彈性化，要常常思考下面幾個問題：

• 常常思考產品和系統哪里有問題，如何優化，如何體系化?
• 常常思考有沒有更好的辦法，有沒有提高效率的辦法?
• 常常思考如何讓穩定性本身更加有價值，有意義?

這3個問題，我覺得可以從3個方面著手：

(1)自動化

這里自動化，包括自動和自助2個部分。自動是指能夠系統能夠對一些異常自動恢復、自動運維，這部分，也可以叫做“彈性”，它一方面包括兜底、容災，另一方面也包括智能化、機器人和規則判斷。比如，對一些可能導致問題的服務失敗，能夠自動走兜底處理邏輯，能夠建立一個調度任務，自動對這部分數據進行調度處理;對一些機器的load飚高、服務抖動等，能自動重啟，自動置換機器。

自助是讓你的客戶自己動手，通過提供機器人，自動識別訂單類型，自動排查訂單狀態和節點，自動告知服務規則特征，自動匹配問題類型給出排查結果或排查過程等。

Google SRE設置了一個50%的上限值，要求SRE人員最多只在手工處理上花費50%的時間，其他時間都用來編碼或者自動化處理。這個可以供我們參考。

(2)系統化

系統化，可以體現在SRE工作的方方面面，我覺得，可以主要在“監控、鏈路治理、演練” 3方面入手。這3個方面也正好對應著“發現問題、解決風險、因事修人” 3個核心。通過系統化，目的是讓我們SRE的工作形成體系，不再是一個個“點”的工作，而是能夠連成“面”，讓SRE工作不再局限于“后期保障/兜底保障”，而是能夠通過監控體系、鏈路風險、演練體系發現問題。

監控、鏈路治理和演練的系統化，將在后面的章節中詳細探討。

(3)數據化

穩定性工作，如果要拿到結果，做到可量化，可度量，就一定要在數據化上下功夫，這個數據化，包括如下幾個方面：

• 數據驅動：包括日志標準化和錯誤碼標準化，能夠對日志和錯誤碼反饋的情況進行量化。
• 數據對賬：包括上下游對賬、業務對賬，能夠通過對賬，保障域內數據校準。
• 軌跡跟蹤：包括變更軌跡和數據軌跡，目標是實現數據的可跟蹤，和變更的可回溯、可回滾。
• 數據化運營：主要是將穩定性的指標量化，比如工單解決時間、工單數、報警數、報警響應時間、故障風險數、代碼CR量，變更灰度時長等，通過量化指標，驅動團隊同學建立量化意識，并且能給老板一份量化數據。

疑惑3：穩定性似乎總是新人的垃圾場

雖然前文中說過，對于團隊而言，最好不要讓新人從事穩定性工作，但是穩定性畢竟是很多希望“專注工作”的開發人員不愿意做的，這個時候，團隊leader很容易做出讓一個剛進入團隊的人從事穩定性工作，畢竟其他核心開發崗位的人似乎對團隊更加重要，也不能調開去從事這種“重要不緊急”的工作，不是嗎?

所以這個時候，新人被安排了穩定性工作，也是敢怒不敢言，充滿抱怨的做已經約定好的工作，或者渾渾噩噩的劃劃水，只在需要“應急”的時候出現一下。

這個現狀要解決，就要涉及到一個人的“被認可度”，也是我們經常說一個人的價值(在個人自我感知上，我們認為這是“成就感”)，很多人可能覺得一個人是因為有價值，才會被認可。而我認為，一個人是因為被認可，才會覺得自己有價值，這樣才會產生做一件事情的成就感。

畢竟，能一開始就找到自己喜歡并且愿意去創造價值的事情，是很少的。大多數人是在不情不愿的去做自己并不知道方向也無所謂成敗的事情。這個時候，是做的事情被認可，讓自己感覺有價值，產生興趣，而不是反過來，愛一行做一行是幸運的，做一行愛一行是勇敢的。

那么對于穩定性的新人，如果你“被安排”從事了穩定性，那么首先要注意下面3個點：

• 對于穩定性新人，一定要優先考慮如何響應問題，而不是如何解決問題。
• 穩定性從來都不是簡單的，他的關鍵，是要做細，這需要細心和耐心。
• 穩定性不是一個人的事情，要團結團隊內的同學，上下游的同學。

在有了上面3點心理建設之后，要開始在自己的心里，構建3張圖，3張表：

(1)3張圖

• 系統間依賴圖(也包括業務時序，熟悉業務流程)，參考5.4節系統依賴梳理方法。
• 流量地圖(知道上下游系統，團隊內系統的流量關系和流量水位，也同時把控系統架構)，參考5.3節流量地圖。
• 系統保障圖(知道穩定性保障的步驟和打法)，參考5.2節作戰地圖。

(2)3張表

• 機器資源表(做到占用多少資源，了然于胸，團隊需要時能拿得出來)，參考第4章資源管控。
• 異常場景應急表(出現問題時知道怎么應對，演練知道哪里容易出問題)，參考3.2節故障場景梳理。
• 業務近30日單量表(知道哪些業務影響大，哪些業務是重點)，參考6.1節黃金鏈路治理。

心中3張圖，3張表，可以讓自己心中有數，不會抓瞎，這就像林彪在《怎樣當好一個師長》一文中寫的那樣，心里要有個“活地圖”。這樣，一個新人才能快速熟悉起團隊的業務和系統，明白風險在哪里，要往哪里打。才能讓自己的工作變得被認可，直擊痛點，有價值。

二 監控

再牛的SRE，也不可能對整個復雜系統了如指掌，也不可能做到對每次變更和發布，都在掌控之內，所以對于SRE人員來說，就必須要有一雙敏銳的“眼睛”，這雙“眼睛”，無論是要快速響應，還是要發現風險，都能快速發現問題，這就是“監控”。

從運維意義上講，“發現問題”的描述 和 “監控”的實現之間的對應關系如下：

1 監控的5個維度

監控的核心目標，是快速發現“異常”。那如何定位異常呢?是不是低于我們設置的閾值的，都是異常?如果要是這么定義的話，你會發現，報警非常多，應接不暇。

要定義異常，就要考慮一個問題：兼容系統的彈性，也就是系統要有一定的容錯能力和自愈能力，不然就會非常脆弱和敏感。因此，我對“異常”的定義，是：在服務(體驗)、數據、資金3個方面中至少1個方面出現了損失 或 錯誤。我認為，一個系統，如果在下面3個方面沒有出現問題，那么即使中間過程出現了偏差，或者沒有按既定路徑達到最終結果，我也認為沒有出現“異常”(這也是一種彈性)：

• 在服務方面沒有異常(我把服務錯誤造成的用戶體驗，也認為是服務異常)。
• 在數據上沒有出錯(我把訂單超時等體驗，也認為是數據出現了偏差)。
• 在資金上沒有資損(走了兜底邏輯，且按照業務可接受的預定范圍兜底造成的損失，不算資損，如兜底運費)。

所以監控一個系統是否具有健壯性(即：彈性(Resilient)，這一點在后面【彈性建設】中詳細論述)，就要從這3個最終目標去實現，為了達到這3個目標，我們可以從 系統自身、服務接口、業務特征、數據、資金對賬 5個維度保障監控的準確性。

下圖詳細解釋了這5個維度：

??

image

2 監控大盤

建立監控大盤的目的，是在大促等關鍵時期，在一張圖上能夠看到所有的關鍵指標。所以大盤的key point應該是“直觀簡潔、指標核心、集中聚焦”。在大盤上，我認為要包括以下要素：

• 最核心業務入口的qps、rt、錯誤數、成功率，從這個維度可以看到入口流量的大小和相應時間，成功率。這一點，是在知道入口的健康情況。
• 錯誤碼top N，這個維度可以看到系統運行過程中最核心的錯誤，快速直觀定位問題原因(這個需要打通上下游錯誤碼透傳)。這一點，是在快速知曉問題出在哪里。
• 按業務維度(業務身份、行業、倉儲、地區等，根據實際需要決定)分類統計計算的單量、或分鐘級下單數量，用于確定核心業務的單量趨勢。這一點，只在知道自身業務的健康情況。
• 核心下游依賴接口、tair、db的qps、rt、錯誤數、成功率，需要注意的是，這個一般比較多，建議只放最核心、量最大的幾個。這一點，是在知道下游依賴的健康情況。
• 其他影響系統穩定性的核心指標，如限單量，核心計數器等，根據各個團隊的核心來決定。這一點，是在個性化定義關鍵影響點的監控情況。

3 避免監控信息爆炸

在SRE的實踐過程中，為了保證監控的全面，往往會增加很多報警項，報警多了之后，就會像洪水一樣，漸漸的SRE對于監控就不再敏感了，讓SRE比較煩惱的一個問題，就是如何做監控報警瘦身?

目前一般來說，我們的監控報警至少包括2種方式：

1. 推送到手機的報警，如電話、短信報警。
2. 推送到釘釘的報警，如報警小助手、報警。

我個人的建議是：

謹慎使用電話報警

因為這會讓人非常疲憊，尤其是夜間，而且容易導致接收者將電話加入騷擾攔截，當真正需要電話報警的時候，就會通知不到位;因此電話報警，一定要設置在不處理要死人的大面積/關鍵問題上;

設置專門的唯一的釘釘報警群

一定一定要建設專門釘釘報警群，而且1個團隊只能建1個群，中間可以用多個報警機器人進行區分。報警群的目的只有1個：讓所有的報警能夠在這個群里通知出來。只建一個群，是為了報警集中，且利于值班同學在報警群中集中響應。

報警留底

所有報警，一定要能留底，也就是有地方可以查到歷史報警，所以建議所有報警，不管最終用什么方式通知，都要在釘釘報警群里同時通知一份，這樣大家只看這個群，也能查到歷史報警。在進行復盤的時候，歷史報警作用非常關鍵，可以看到問題發現時間，監控遺漏，問題恢復時間。

日常報警數量限制

一般來說，如果一段時間內，報警短信的數量超過99條，顯示了99+，大家就會失去查看報警的興趣，因此，一定要不斷調整報警的閾值，使其在業務正常的情況下，不會頻繁報警。在盒馬履約，我們基本可以做到24小時內，報警群內的報警總數，在不出故障/風險的情況下小于100條;這樣的好處是明顯的，因為我們基本上可以做到1個小時以上才查看報警群，只要看到報警群的新增條數不多(比如只有10條左右)，就能大致判斷過去的一個小時內，沒有嚴重的報警發生;減少報警的方法，可以采用如下手段：

• 對于系統監控報警，采用范圍報警，比如load，設置集群內超過N %且機器數大于M的機器load都升高了才報警。畢竟對于一個集群而言，偶爾一臺機器的load抖動，是不需要響應的。
• 對于業務報警，一定要做好同比，不但要同比昨天，還要同比上周，通過對比確認，對于一些流量不是很大的業務來說，這一點尤其重要，有些時候錯誤高，純粹是ERROR級別日志過度打印，所以只要相對于昨天和上周沒有明顯增加，就不用報警。
• 對于qps、rt等服務報警，要注意持續性，一般來說，要考慮持續N分鐘，才需要報警，偶爾的抖動，是不用報警的。當然，對于成功率下跌，異常數增加，一般要立即報出來。
• 復合報警，比如一方面要持續N分鐘，一方面要同比昨天和上周，這樣來減少一些無需報警的情況。
• 根據需要設置報警的閾值，避免設置>0就報警這種，這種報警沒有意義，一般來說，如果一個報警，連續重復報10條以上，都沒有處理，一般是這個報警的通知級別不夠，但是如果一個報警，重復10條以上，經過處理人判斷，不需要處理，那就肯定是這個報警的閾值有問題。

報警要能夠互補

我們經常提到監控的覆蓋率，但是覆蓋還是不夠的，因為監控可能出現多種可能性的缺失(丟日志、通信異常等)，因此要能夠從多個維度覆蓋，比如，除了要直接用指標覆蓋qps，還需要通過日志來覆蓋一遍，除了要用日志覆蓋一些訂單趨勢，還要從db統計上覆蓋一遍，這樣一個報警丟失，還至少有另外一個報警可以backup。

4 有效發現監控問題

作為一個SRE人員，很容易發現一個點，如果有幾次線上問題或報警響應不及時，就會被老板和同事質疑。同樣的，如果每次線上問題都能先于同事們發現和響應，就會贏得大家信任，那要如何做到先于大家發現呢?我的建議是：像刷抖音一樣刷監控群和值班群。

一般來說，一個團隊的穩定性問題在3類群里發現：BU級消防群、團隊的監控報警群、業務值班群;所以沒有必要紅著眼睛盯著監控大盤，也沒必要對每個報警都做的好像驚弓之鳥，這樣很快自己就會疲憊厭煩。

我的經驗是按下面的步驟：

• 首先當然是要監控治理，做到監控準確，全面，然后按照前面說的，控制報警數量，集中報警群，做到可控、合理。
• 然后像刷抖音一樣，隔三差五(一般至少1個小時要有一次)刷一下報警群，如果報警群里的新增條數在20條以內，問題一般不大，刷一刷就行。
• 如果突然一段時間內報警陡增，就要看一下具體是什么問題了，小問題直接處理，大問題分工組織協調。
• 消防群中的問題，要及時同步到團隊中。
• 值班群中的工單，需要關注，并有一個初步的判斷：是否是大面積出現的業務反饋，是否有擴大的隱患。

要做到“有效”兩個字，SRE人員，需要有一個精確的判斷：當前報警是否需要處理?當前報警是否意味著問題?當前報警的影響范圍和涉及人員是誰?當前工單/問題是否可能進一步擴大，不同的判斷，采取的行動是不同的。

三 故障應急

前面1.4.1中，有提到如何及時、快速的響應，這一點是作為SRE人員在故障應急時的關鍵，也是平時處理線上問題的關鍵。除此之外，在應對故障方面，還有很多事情需要做。

1 系統可用性的定義

ufried 在2017年的經典彈性設計PPT：《Resilient software design in a nutshell》中，對系統可用性的定義如下：

??

image

可見，影響系統可用性的指標包括2個方面：MTTF(不出故障的時間)和MTTR(出故障后的恢復時間)，所以，要提高系統可用性，要從2個方面入手：

1. 盡量增加無故障時間
2. 盡量縮短出故障后的恢復時間

對故障應急來說，也要從這兩個方面入手，首先要增加無故障時間，包括日常的風險發現和風險治理，借大促機會進行的鏈路梳理和風險治理。只有不斷的發現風險，治理風險，才能防止系統穩定性腐爛，才能增加無故障時間。

其次，要縮短出故障之后的恢復時間，這一點上，首先要把功夫花在平時，防止出現故障時的慌張無助。平時的功夫，主要就是場景梳理和故障演練。

2 場景梳理

故障場景梳理，重點在于要把可能出現故障的核心場景、表現、定位方法、應對策略梳理清楚，做到應對人員爛熟于心，為演練、故障應急提供腳本。

通過這種程度的梳理，SRE以及其掌控的故障應對人員，能夠快速的明確發生問題的場景，以及場景下的影響、表現、定位方法、應對策略。當然，如果要把這些場景牢記，做到快速應對，就需要依靠：演練。

3 故障演練

演練對故障應急無比重要，但是，我個人十分反對把演練作為解決一切問題的手段。演練本身，應該是驗證可行性和增加成熟度的方式，只能錦上添花，而不能解決問題，真正解決問題的應該是方案本身。

不要進行無場景演練

有些演練，不設置場景，純粹考察大家的反應，這種演練，上有政策下有對策，表面上是在搞突然襲擊，其實已經預設了時間段，預設了參加的域，不太可能做到完全毫無準備，到了演練的時間點，大家可以通過死盯著報警群，調整各種報警閾值的方式，更快的發現問題;而且完全無場景的演練，一般只能演練如fullGC，線程池滿，機器load高，接口注入異常，對于一些數據錯誤，消息丟失，異步任務積壓等場景，很難演練。

針對性的，我建議多進行場景演練，各域要提前進行3.2節這種詳細的場景梳理，通過場景攻擊，提高大家的應對成熟度。事實上，現在橫向安全生產團隊不對各個業務團隊進行場景攻擊的原因，也是因為橫向安全生產團隊自己也不熟悉各個業務團隊的業務場景，這個就需要加強對業務場景攻擊方式的規范化，橫向安全生產團隊也要加強機制建設，讓縱向業務團隊能夠產出場景，而不是每次都在線程池、fullGC、磁盤空間這些方面進行攻擊。

不要無意義的提速演練

演練本身雖然確實有一個重要目的是提高應對熟練度，但是不同的業務是有區別的，有些業務的發現本身，就不止1分鐘(比如某些單據積壓場景，消息消費場景)，這些場景，如果不參加評比，或者流于形式了，就會讓攻擊本身沒有意義。

針對性的，我建議各個業務根據各自的特點，定制演練。如：普通電商業務，關注下單成功率，有大量的實時同步調用;新零售業務，關注單據履約效率，有大量的異步調度;每個業務，根據實際場景和業務需要，制定“有各自特色的要求”的演練標準，演練不一定要千篇一律，但是一定要達到業務的需求標準。這樣也更加有利于演練場景的落地，有利于藍軍針對性的制定攻擊策略。

各個SRE同學，不管大的政策怎么樣，還是要關注團隊內部的場景本身：

• 對于系統性故障注入(load、cpu、fullGC、線程池等)，直接套用集團的mk注入即可。
• 對于服務型故障注入(下游異常、超時，接口超時、限流)，mk也有比較好的支持。
• 對于訂單異常型故障注入，要自主開發較好的錯誤訂單生成工具，注入異常訂單，觸發故障報警。
• 對于調度、積壓型故障注入，要關注schedulex、異步消息的故障注入方式，同時防止積壓阻塞正常訂單影響真正的線上業務。

同時，在演練前后，要注意跟老板的溝通，要讓老板理解到你組織的演練的目標和效果，不然就不是演習，而是演戲了。要和老板的目標契合，在演練過程中，通過演練提高大家對業務場景的理解深度和對問題的應對速度，增加大家的穩定性意識，達到“因事修人”的目的。

4 故障應急過程

如果不幸真的產生了故障，作為SRE，要記得如下信息：

• 冷靜。作為SRE，首先不能慌，沒有什么比盡快定位和止損更重要的事情。
• 拉電話會議同步給大家信息。記住，在出現故障時，沒什么比電話會議更加高效的溝通方式了。
• 參考前面1.4.1節中的SRE人員快速響應流程，在電話會議中同步給大家：

• 盡快告知當前告警已經有人接手，是誰接手的，表明問題有人在處理了。(這一步叫“響應”)
• 組織人員，快速定位問題，告知問題初步定位原因(這一步叫“定位”)。
• 初步影響范圍是什么?給出大致數據(這一步方便后面做決策)
• 有哪些需要老板、產品、業務方決策的?你的建議是什么?(這一步很關鍵，很多時候是：兩害相權取其輕，你的評估和建議，直接影響老板的決策)
• 當前進展如何，是否已經止血?(這一步是“恢復”，要給出“進展”，讓決策者和業務方了解情況)

• 組織大家按照故障場景梳理的應對方案進行應對，如果沒有在故障場景列表中，一定要組織最熟練的人員進行定位和恢復。
• 故障過程中，對外通信要跟團隊和老板統一評估過再說;
• 處理故障過程中，要隨時組織同學們進行影響數據撈取和評估，撈出來的數據，要優先跟老板、業務熟練的同學一起評估是否有錯漏。
• 在處理完故障后，要及時組織復盤(不管GOC是不是統一組織復盤，內部都要更加深刻的復盤)，復盤流程至少包括：詳細的時間線，詳細的原因，詳細的定位和解決方案，后續action和改進措施，本次故障的處理結果。

我個人其實不太贊同預案自動化和強運營的故障應急方案，這一點也是給安全生產同學的建議，比如預案自動化，有很強的局限性，只有在明確預案的執行肯定不會有問題、或者明顯有優化作用的情況下，才能自動執行。否則都應該有人為判斷。

強運營類的工作，會導致人走茶涼，比如GOC上自動推送的預案，故障場景關聯的監控這種，一方面應該盡量減少強運營的工作，另一方面應該定期組織維護一些必要預案。

5 與兄弟團隊的關系

如果兄弟團隊發生故障，一定注意：

1. 不能嘲笑別人，看笑話。
2. 不能當沒事人，高高掛起，要檢查自身。
3. 不能話說的太滿，比如說我肯定沒故障。

尤其是1和3，非常邪性，嘲笑別人的團隊，或者覺得自己萬事大吉，很容易沾染故障。(其實本身是由科學依據的，嘲笑別人的，一般容易放松警惕)

4 資源管控

作為一個SRE，在資源管控領域，一定要保證自己域有足夠的機器，同時又不會浪費太多。我個人的建議是，核心應用，應該控制load在1-1.5左右(日常峰值或A級活動場景下)，控制核心應用在10個以內，非核心應用，應該控制load在1.5-2左右(日常峰值或A級活動場景下)。目前集團很多應用load不到1，甚至只有0.幾，其實很浪費的。

同時，一個團隊的SRE，至少隨時手上應該握有20%左右的空余額度buffer，方便隨時擴容，或者應對新業務增長。這些額度，目前按照集團的預算策略，只要不真的擴容上去，都是不收費的，所以應當持有。

除了機器以外，tair、db、消息、精衛等，也要如上操作，除了年初準備好一年的預算，還要額外準備20%左右的buffer。

SRE要自己梳理一份資源表，表中一方面要明確有哪些資源，余量多少，另一方面要明確資源的當前水位、壓力。

比如機器資源，要關注當前機器數、額度、load，如：

??

再比如對數據庫資源，要關注數據庫的配置、空間、日常和峰值qps、單均訪問量(創建一個訂單，要讀和寫DB多少次，這一點很關鍵)。

??

【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】

??戳這里，看該作者更多好文??