**導讀：**穩定性目前不再侷限於大促時的保障和平時的穩定性輪值，越來越體系化。本文基於作者在業務團隊工作過程中的沉澱，以及在盒馬兩年 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 人員來說，就必須要有一雙敏銳的 “眼睛”，這雙 “眼睛”，無論是要快速響應，還是要發現風險，都能快速發現問題，這就是 “監控”。

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

QkCvE5

1  監控的 5 個維度

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

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

• 在服務方面沒有異常（我把服務錯誤造成的用戶體驗，也認爲是服務異常）。

• 在數據上沒有出錯（我把訂單超時等體驗，也認爲是數據出現了偏差）。

• 在資金上沒有資損（走了兜底邏輯，且按照業務可接受的預定範圍兜底造成的損失，不算資損，如兜底運費）。

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

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

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》中，對系統可用性的定義如下：

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

1. 儘量增加無故障時間

2. 儘量縮短出故障後的恢復時間

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

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

2  場景梳理

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

s7Yqu3

通過這種程度的梳理，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 多少次，這一點很關鍵）。

限於篇幅，以上是本文的上半部分，下半部分作者將分享大促保障機制、日常穩定性機制、彈性建設及價值建設方面的內容，同學們可點擊 “閱讀原文” 繼續閱讀~

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/jouVDaK8UuQwDMbrxizD5A