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

前言

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

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

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

什么是SRE

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

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

一 心態(tài)&態(tài)度

1 誰適合做穩(wěn)定性?

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

必須選擇負責任的人

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

原則上不要選擇新人

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

不要用過于"老實"的人

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

2 業(yè)務團隊如何支持穩(wěn)定性SRE人員

給資源

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

給空間

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

區(qū)分責任

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

3 開發(fā)和SRE的區(qū)別

都是做技術的，很多開發(fā)剛剛轉向負責穩(wěn)定性時，有些彎轉不過來。

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

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

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

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

4 SRE心態(tài)上的一些釋疑

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

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

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

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

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

(1)及時、快速的響應

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(3)主動走到最前線

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

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

疑惑2：穩(wěn)定性總是做擦屁股的工作

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

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

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

暖曰：“ 王獨不聞魏文王之問扁鵲耶?曰：‘子昆弟三人其孰最善為醫(yī)?’扁鵲曰：‘長兄最善，中兄次之，扁鵲最為下?！何暮钤唬骸傻寐勑?’扁鵲曰：‘長兄于病視神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于閭。若扁鵲者，镵血脈，投毒藥，副肌膚，閑而名出聞于諸侯?！何暮钤唬骸?。使管子行醫(yī)術以扁鵲之道，曰桓公幾能成其霸乎!’凡此者不病病，治之無名，使之無形，至功之成，其下謂之自然。故良醫(yī)化之，拙醫(yī)敗之，雖幸不死，創(chuàng)伸股維?！?/p>

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

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

1. 做扁鵲大哥：在系統(tǒng)健康時發(fā)現(xiàn)問題
2. 做扁鵲二哥：在系統(tǒng)有隱患時發(fā)現(xiàn)問題
3. 做扁鵲：在系統(tǒng)發(fā)生問題時快速解決問題

(2)自動化、系統(tǒng)化、數(shù)據(jù)化

SRE不是在做一種收尾型、擦屁股的工作，而是在做一種探索性、前瞻性的工作，但SRE不可避免的，會面對很多重復性的工作，所以除了要在組織和機制上做好分工，讓恰當?shù)娜俗銮‘數(shù)氖轮?，SRE人員要經(jīng)常思考產(chǎn)品的系統(tǒng)化和彈性化，要常常思考下面幾個問題：

• 常常思考產(chǎn)品和系統(tǒng)哪里有問題，如何優(yōu)化，如何體系化?
• 常常思考有沒有更好的辦法，有沒有提高效率的辦法?
• 常常思考如何讓穩(wěn)定性本身更加有價值，有意義?

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

(1)自動化

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

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

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

(2)系統(tǒng)化

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

監(jiān)控、鏈路治理和演練的系統(tǒng)化，將在后面的章節(jié)中詳細探討。

(3)數(shù)據(jù)化

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

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

疑惑3：穩(wěn)定性似乎總是新人的垃圾場

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

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

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

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

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

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

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

(1)3張圖

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

(2)3張表

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

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

二 監(jiān)控

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

從運維意義上講，“發(fā)現(xiàn)問題”的描述 和 “監(jiān)控”的實現(xiàn)之間的對應關系如下：

1 監(jiān)控的5個維度

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

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

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

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

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

??

image

2 監(jiān)控大盤

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

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

3 避免監(jiān)控信息爆炸

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

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

1. 推送到手機的報警，如電話、短信報警。
2. 推送到釘釘?shù)膱缶?，如報警小助手、報警?/li>

我個人的建議是：

謹慎使用電話報警

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

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

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

報警留底

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

日常報警數(shù)量限制

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

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

報警要能夠互補

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

4 有效發(fā)現(xiàn)監(jiān)控問題

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

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

我的經(jīng)驗是按下面的步驟：

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

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

三 故障應急

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

1 系統(tǒng)可用性的定義

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

??

image

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

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

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

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

2 場景梳理

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

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

3 故障演練

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

不要進行無場景演練

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

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

不要無意義的提速演練

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

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

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

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

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

4 故障應急過程

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

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

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

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

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

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

5 與兄弟團隊的關系

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

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

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

4 資源管控

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

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

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

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

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

??

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

??

【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】

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