如何做好一名穩定性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，心态&态度

1.1，誰适合做穩定性？

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

• 必須選擇負責任的人，負責任是第一要素，主動承擔，對報警、工單、線上問題、風險主動響應，不怕吃苦；一個不負責任的人，遇到問題與我無關的人，邊界感太強的人，難以做好穩定性的工作；
• 原則上不要選擇新人，對于團隊leader而言，“用新人做别人不願意做的工作”，這個決定比較容易做出，但是這也相當于是把團隊的穩定性放在了一定程度的風險上，用新人做穩定性，其實隻是用新人占了穩定性的一個坑而已。新人不熟悉業務，不了解上下遊，最多隻能憑借一腔熱血，對業務和系統感覺不足，容易導緻線上風險無法被快速發現、故障應急無法迅速組織。
• 不要用過于"老實"的人，這裡的“老實”的定義是不去主動想優化的辦法，不主動出頭解決問題，但是很能吃苦，任勞任怨，也很能忍耐系統的腐爛和低效；這樣的人平時很踏實，用起來也順手，但是卻無法主動提高系統穩定性，有的時候反而會給系統穩定性造成傷害（穩定性就像大堤，不主動更新，就早晚會腐爛）。

1.2，業務團隊如何支援穩定性SRE人員

• 給資源，穩定性從來不隻是穩定性負責人的事情，而是全團隊的事情，穩定性負責人要做的是建立機制，主動承擔，但是穩定性意識，要深入到團隊所有人腦子裡，穩定性的事情，要能夠調動團隊一切資源參與。
• 給空間，做穩定性的人，往往面臨一個尴尬場景：晉升困難，主要是因為在技術深度和業務價值兩個方面，很容易被挑戰，對于業務團隊，一定要留給做穩定性的人足夠的思考和上升空間，将穩定性與團隊的技術架構更新、業務項目結合起來，共同推動。經過集團安全生産團隊的推動，目前在阿裡，SRE已經有了自己專門的晉升體系。
• 區分責任，當出現故障時，區厘清楚責任，到底是穩定性工作沒有做到位，還是做到位了，但是團隊同學疏忽了，還是說隻是單純的業務變化；

1.3，開發和SRE的差別

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

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

• 開發：了解業務 -> 定位問題 -> 排查問題 -> 解決問題

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

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

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

1.4，SRE心态上的一些釋疑

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

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

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

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

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

1. 及時、快速的響應

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

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

回報也是有技巧的，不僅僅是告知這麼簡單，你需要快速的說明以下幾個資訊：

• 盡快告知目前告警已經有人接手，是誰接手的，表明問題有人在處理了。（這一步叫“響應”）
• 組織人員，快速定位問題，告知問題初步定位原因（這一步叫“定位”）。
• 初步影響範圍是什麼？給出大緻資料（這一步友善後面做決策）
• 有哪些需要老闆、産品、業務方決策的？你的建議是什麼？（這一步很關鍵，很多時候是：兩害相權取其輕，你的評估和建議，直接影響老闆的決策）
• 目前進展如何，是否已經止血？（這一步是“恢複”，要給出“進展”，讓決策者和業務方了解情況）

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

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

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

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

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

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

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

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

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

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

3. 主動走到最前線

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

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

1.4.2，疑惑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，【資料化】

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

1. 資料驅動：包括日志标準化和錯誤碼标準化，能夠對日志和錯誤碼回報的情況進行量化；
2. 資料對賬：包括上下遊對賬、業務對賬，能夠通過對賬，保障域内資料校準；
3. 軌迹跟蹤：包括變更軌迹和資料軌迹，目标是實作資料的可跟蹤，和變更的可回溯、可復原；

4. 資料化營運：主要是将穩定性的名額量化，比如工單解決時間、工單數、報警數、報警響應時間、故障風險數、代碼CR量，變更灰階時長等，通過量化名額，驅動團隊同學建立量化意識，并且能給老闆一份量化資料。

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

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

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

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

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

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

1，對于穩定性新人，一定要優先考慮如何響應問題，而不是如何解決問題

2，穩定性從來都不是簡單的，他的關鍵，是要做細，這需要細心和耐心

3，穩定性不是一個人的事情，要團結團隊内的同學，上下遊的同學

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

3張圖：

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

3張表:

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

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

2，監控

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

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

發現問題的需求描述

監控的實作

減少人力發現成本

自動監控、多種報警手段

及時、準确

實時監控、同比、環比、對賬

防止出錯

減少誤報、同比環比、削峰

不遺漏

減少漏報，多元監控

直覺評估影響面

對賬&統計

2.1，監控的5個次元

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

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

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

• 在資料上沒有出錯（我把訂單逾時等體驗，也認為是資料出現了偏差）

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

是以監控一個系統是否具有健壯性（即：彈性(Resilient)，這一點在後面【彈性建設】中詳細論述），就要從這3個最終目标去實作，為了達到這3個目标，我們可以從 系統自身、服務接口、業務特征、資料、資金對賬 5個次元保障監控的準确性。

下圖詳細解釋了這5個次元：

2.2，監控大盤

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

1. 最核心業務入口的qps、rt、錯誤數、成功率，從這個次元可以看到入口流量的大小和相應時間，成功率。這一點，是在知道入口的健康情況；
2. 錯誤碼top N，這個次元可以看到系統運作過程中最核心的錯誤，快速直覺定位問題原因（這個需要打通上下遊錯誤碼透傳）。這一點，是在快速知曉問題出在哪裡；
3. 按業務次元（業務身份、行業、倉儲、地區等，根據實際需要決定）分類統計計算的單量、或分鐘級下單數量，用于确定核心業務的單量趨勢。這一點，隻在知道自身業務的健康情況；
4. 核心下遊依賴接口、tair、db的qps、rt、錯誤數、成功率，需要注意的是，這個一般比較多，建議隻放最核心、量最大的幾個。這一點，是在知道下遊依賴的健康情況；

5. 其他影響系統穩定性的核心名額，如限單量，核心計數器等，根據各個團隊的核心來決定。這一點，是在個性化定義關鍵影響點的監控情況；

   2.3，避免監控資訊爆炸

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

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

1. 推送到手機的報警，如電話、短信報警；

2. 推送到釘釘的報警，如報警小助手、報警；

   我個人的建議是：

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

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

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

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

• 對于系統監控報警，采用範圍報警，比如load，設定叢集内超過N %且機器數大于M的機器load都升高了才報警。畢竟對于一個叢集而言，偶爾一台機器的load抖動，是不需要響應的。
• 對于業務報警，一定要做好同比，不但要同比昨天，還要同比上周，通過對比确認，對于一些流量不是很大的業務來說，這一點尤其重要，有些時候錯誤高，純粹是ERROR級别日志過度列印，是以隻要相對于昨天和上周沒有明顯增加，就不用報警；
• 對于qps、rt等服務報警，要注意持續性，一般來說，要考慮持續N分鐘，才需要報警，偶爾的抖動，是不用報警的。當然，對于成功率下跌，異常數增加，一般要立即報出來；
• 複合報警，比如一方面要持續N分鐘，一方面要同比昨天和上周，這樣來減少一些無需報警的情況；

• 根據需要設定報警的門檻值，避免設定>0就報警這種，這種報警沒有意義，一般來說，如果一個報警，連續重複報10條以上，都沒有處理，一般是這個報警的通知級别不夠，但是如果一個報警，重複10條以上，經過處理人判斷，不需要處理，那就肯定是這個報警的門檻值有問題；

  5，【報警要能夠互補】我們經常提到監控的覆寫率，但是覆寫還是不夠的，因為監控可能出現多種可能性的缺失（丢日志、通信異常等），是以要能夠從多個次元覆寫，比如，除了要直接用名額覆寫qps，還需要通過日志來覆寫一遍，除了要用日志覆寫一些訂單趨勢，還要從db統計上覆寫一遍，這樣一個報警丢失，還至少有另外一個報警可以backup；

2.4，有效發現監控問題

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

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

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

1. 首先當然是要監控治理，做到監控準确，全面，然後按照前面說的，控制報警數量，集中報警群，做到可控、合理；
2. 然後像刷抖音一樣，隔三差五（一般至少1個小時要有一次）刷一下報警群，如果報警群裡的新增條數在20條以内，問題一般不大，刷一刷就行；
3. 如果突然一段時間内報警陡增，就要看一下具體是什麼問題了，小問題直接處理，大問題分工組織協調；
4. 消防群中的問題，要及時同步到團隊中；

5. 值班群中的工單，需要關注，并有一個初步的判斷：是否是大面積出現的業務回報；是否有擴大的隐患；

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

3，故障應急

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

3.1，系統可用性的定義

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

可見，影響系統可用性的名額包括2個方面：MTTF（不出故障的時間）和MTTR（出故障後的恢複時間），是以，要提高系統可用性，要從2個方面入手：1，盡量增加無故障時間，2，盡量縮短出故障後的恢複時間；

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

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

3.2，場景梳理

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

業務域

關鍵場景

問題表現

問題定位

止血措施

預案執行

業務影響

上遊影響

下遊影響

資料影響（操作人）

服務側、業務側應對政策

産品端應對政策

相關域，要分别梳理上遊和下遊

服務場景，每行列出一個場景，要列出所有可能的場景

逐條列出目前場景的所有可能表現

對應前面的問題表現，列出每一個表現的定位方法和名額

對每個定位的原因，給出快速止血的措施

逐條列出可以執行的預案

逐條列出可能導緻的業務影響和嚴重程度、範圍

逐條列出在上遊的影響

逐條列出對下遊的影響

逐條列出資料的影響（qps、rt、單量），以及撈取資料的方法、訂正資料的方法

列出服務端、業務側的應對話術和退款、賠付、補償方案；

列出産品側對業務側的溝通方案、客服話術、産品降級方案；

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

3.3，故障演練

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

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

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

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

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

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

1. 對于系統性故障注入（load、cpu、fullGC、線程池等），直接套用集團的mk注入即可；
2. 對于服務型故障注入（下遊異常、逾時，接口逾時、限流），mk也有比較好的支援；
3. 對于訂單異常型故障注入，要自主開發較好的錯誤訂單生成工具，注入異常訂單，觸發故障報警；

4. 對于排程、積壓型故障注入，要關注schedulex、異步消息的故障注入方式，同時防止積壓阻塞正常訂單影響真正的線上業務；

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

3.4，故障應急過程

如果不幸真的産生了故障，作為SRE，要記得如下資訊：

1. 冷靜。作為SRE，首先不能慌，沒有什麼比盡快定位和止損更重要的事情
2. 拉電話會議同步給大家資訊。記住，在出現故障時，沒什麼比電話會議更加高效的溝通方式了；

3. 參考前面1.4.1節中的SRE人員快速響應流程，在電話會議中同步給大家：

   • 盡快告知目前告警已經有人接手，是誰接手的，表明問題有人在處理了。（這一步叫“響應”）

• 組織人員，快速定位問題，告知問題初步定位原因（這一步叫“定位”）。

• 初步影響範圍是什麼？給出大緻資料（這一步友善後面做決策）

• 有哪些需要老闆、産品、業務方決策的？你的建議是什麼？（這一步很關鍵，很多時候是：兩害相權取其輕，你的評估和建議，直接影響老闆的決策）

• 目前進展如何，是否已經止血？（這一步是“恢複”，要給出“進展”，讓決策者和業務方了解情況）

1. 組織大家按照故障場景梳理的應對方案進行應對，如果沒有在故障場景清單中，一定要組織最熟練的人員進行定位和恢複。
2. 故障過程中，對外通信要跟團隊和老闆統一評估過再說；
3. 處理故障過程中，要随時組織同學們進行影響資料撈取和評估，撈出來的資料，要優先跟老闆、業務熟練的同學一起評估是否有錯漏。

4. 在處理完故障後，要及時組織複盤（不管GOC是不是統一組織複盤，内部都要更加深刻的複盤），複盤流程至少包括：詳細的時間線，詳細的原因，詳細的定位和解決方案，後續action和改進措施，本次故障的處理結果。

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

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

3.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多少次，這一點很關鍵）：

5，大促保障機制

對于SRE來說，大促、尤其是雙十一，是一年一度的沉澱系統、防止腐爛、摸清水位、剔除風險的最佳時機，是以一定要加以利用。對于團隊的其他開發，大促是一次活動而已，對于SRE來說，大促是系統穩定性提升的過程，與其說是保障大促穩定，不如說是“借大促，修系統”。

是以，一定要轉變思想，我們做大促保障，不僅是要“保持系統穩定性”的，更是要“提升系統穩定性”的。保持重在壓測、摸排水位、限流、預案，而提升重在鍊路排查、風險治理、流量提升、兜底容災。

一般的A級大促，或間隔較小的S級大促，應以“保持”穩定為主，但對于雙十一、618，這種S級大促，應當以“提升”穩定為主；下面，我們重點就要介紹如何借助大促的機會，來提升系統穩定性。

5.1，業務團隊大促保障的一般流程

一個完善的大促保障包括如下步驟（可參考下面的作戰地圖）：

1. 明确本次大促的作戰地圖，明确時間節點和步驟；
2. 輸入活動玩法和節點，明确關鍵時間點和GMV目标、單量峰值；
3. SRE産出備戰報告，其中包括保障目标，大促保障時間節奏，作戰地圖，流量地圖（如果已經繪制出來的話），資源規劃地圖，業務新的變化和技術的挑戰，上下遊鍊路依賴圖，核心風險和專項分工（精确到人和完成時間），同時SRE要指定監控、壓測、演練、預案專項負責人（leader要為SRE放權和背書）。
4. SRE繪制流量地圖，明确接口流量，子產品鍊路，關鍵風險。
5. SRE和開發同學共同梳理上下遊接口依賴流量和峰值，給出限流門檻值并溝通上下遊；
6. 開始鍊路梳理，一般由熟悉業務和系統的開發同學梳理，然後拉上上下遊、梳理同學、測試同學、SRE、leader一起review，review時，SRE要産出5個點：強弱依賴、風險點、限流、降級預案、新業務特征；
7. 根據梳理出來的風險點展開集中治理，大的風險點要開專項治理，這一階段要全員聽調，風險點要各自去做，SRE隻負責把控全局、跟蹤進度、驗收結果。
8. 治理完成後，開展監控走查，更新監控大盤，建議由SRE指定監控專人負責；
9. 壓測開始前配置限流，壓測過程中還要不斷根據情況調節限流值；
10. 開始壓測，分為專項重點壓測（一般單接口、單機），上下遊壓測，全鍊路壓測，建議由SRE指定壓測責任人；
11. 錄入預案，并對預案進行測試和驗證，拉上業務、産品、測試一起，組織預案演練，驗證預案可行性，要求業務方知曉預案執行後的影響。建議由SRE指定預案和演練責任人。
12. 上述過程中都要記錄未完成點和check點，在大促前，要對checklist 逐項check；
13. 産出作戰手冊，包括值班表，工具清單，大促期間作戰流程（精确到分鐘級的操作時間點和人員），再次通知業務側相關預案的影響。
14. 大促開始前一天，SRE要進行戰前宣講，一般包括大促期間釋出流程、審批流程、白名單人員名單，工單彙報方法，大促交流群，大促期間的紅線和注意事項。

15. 大促結束後，要進行複盤，複盤内容包括：目标是否達到，大促期間達到系統名額、單量，系統、業務的能力亮點，大促保障期間大家做的工作彙總，保障期間的産出亮點，後續action項，未來保障的思考和計劃。

    5.2，作戰地圖

下面一張圖，比較詳細的介紹了整個雙十一作戰的過程：一次大促保障，大緻分為前期的容量評估和準備階段，中間的系統健壯性提升階段，後面的壓測摸底、預案演練階段，最後的戰前check和值班階段。其中前2個階段才是核心。

在這張作戰地圖中：

1. 容量準備階段，重在根據業務活動節點，輸入流量和單量，梳理上下遊流量壓力，繪制流量地圖，統計上下遊接口壓力，評估限流門檻值和資源缺口，同時準備資源。這個階段是關鍵階段
2. 系統健壯性提升階段，重在鍊路梳理和風險發現，對發現的風險進行專項治理。這個階段是最核心階段
3. 在壓測階段，不能隻被動的參加全鍊路壓測，還要優先在自己域内進行單點壓測和上下遊鍊路壓測，這樣在全鍊路壓測的時候才不會掉鍊子。同時，壓測要關注幾個事情：1，有沒有達到流量預期；2，有哪些點是瓶頸點；3，對瓶頸點如何解決，如何降級或限流？4，上下遊在壓測過程中有沒有可能與自己域互相影響的地方；
4. 在預案&演練階段，要注重實效，不要走形式化，演練的目的是驗證預案的可行性和可操作性，不是為了證明“我演練過了”，如果預案不進行演練，在大促時就有可能出現：1，不敢執行預案，因為不知道會發生什麼；2，執行了預案之後發現有坑；3，執行了預案之後發現無效；

5. 在戰前準備階段，重在檢查和宣講，檢查要查缺補漏，要有checklist，一項項check；宣講要有作戰手冊和紅線，作戰手冊要精确到時間點和人，每個時間點由誰做什麼要明确；紅線一定要宣講清楚，大促是一場戰役，如何報備，如何響應工單，各自分工是什麼，哪些紅線不能踩，要明确到位，避免低級騷操作帶來的風險。

   下面重點介紹容量準備階段（流量地圖和評估）和系統健壯性提升階段（梳理和治理）；

5.3，流量地圖&流量評估

繪制流量地圖的目的，是讓SRE人員對于域内和上下遊流量有明确的了解，在心中有一張全局流量的“圖”。流量地圖應該包括幾個要素：

1. 系統核心子產品和子產品間的依賴關系；（用方塊和連線辨別）
2. 核心功能流量流向；（用不同顔色的連線區分）
3. 核心接口/功能的單量或qps；（在接口上方标注）

4. 鍊路上的主要風險點；（用紅色方塊标注）

   在進行流量評估時，關鍵在于要明白上下遊依賴、是否有緩存、平時單量和大促單量：

本域應用名

對方域

對方應用host

業務場景

服務接口

對方owner

依賴方式、強弱

日常峰值

大促預估峰值

緩存擊穿情況下的悲觀峰值

appname

商品域

xxx-itemhost，精确到host

時間片商品查詢

service.method~params

某某

hsf、強，有緩存

1000

2000

5000

e.g.

流量評估除了要跟域内對齊外，更加重要的是上下遊的溝通，這一點非常重要，要互相明确各自域的瓶頸、限流、承諾；在對上做出流量承諾的時候，一定要優先考慮保護自己域；在對下提出流量要求的時候，要同時提出有保護措施（如緩存）情況下的正常流量和無保護措施下最糟糕流量。

5.4，鍊路梳理&治理

這個是SRE能夠借雙十一提升系統性能的重中之重，一般，我建議遵循下面的方法：

大促保障準備時間有限，是以不能等全都梳理完了之後才開始治理。一般來說是先根據經驗和日常的發現，治理一波，同時進行梳理，然後對梳理進行review時，發現新的風險點，并進行治理。

一般由熟悉業務和系統的開發同學梳理，然後拉上上下遊、梳理同學、測試同學、SRE、團隊leader一起review，review時，SRE要重點關注5個點：

• 強弱依賴

• 風險點

• 限流

• 降級預案

• 新業務特征

功能

細粒度場景

風險點action

限流

降級預案

強弱依賴

新業務

功能描述，根據功能進行劃分

将場景細粒度細分，清單化

可能存在的風險點

目前場景的限流評估

目前場景可能存在的降級預案

上下遊間的強弱依賴，強依賴的要關聯預案、限流、降級等

目前場景從上次大促到現在的增量變更

梳理的目的不是僅僅評估風險，更重要的是治理，治理不一定是代碼層面的更新，可能有如下方式：

1. 對可能有流量尖峰、造成系統沖擊的接口，加特殊限流，如全局限流、線程數限流；
2. 對流量尖峰，加dts等異步任務，進行削峰填谷；
3. 對需要做降級的地方加降級預案；
4. 對需要兜底容災的地方加自動兜底；
5. 對強依賴的下遊接口，加本地緩存或tair緩存（慎之又慎，同時下遊絕對不能期待上遊加緩存來降低通路量）；
6. 治理的時候，要注意幾個最容易出問題的地方：緩存、異步消息、異步任務、資料庫量級、資料庫關聯查詢量或批量更新量（比如1主單關聯N子單的情況）、接口逾時時間、重試次數、幂等、sql limit和查詢上限；
7. 需要提前禁寫的，要産出禁寫預案

8. 對大促期間可能随時調整的業務參數，要留出口子，友善調整，做好審批流程報備流程、check流程；

   在鍊路治理時，建議可以建立一個aone項目空間或者lark表格，将所有要做的事情，列成工作項，每完成一項勾掉一項，當所有工作項都完成時，項目就結束了，治理也達到了一個水準。

5.5，壓測

在大促保障過程中，提到壓測，有同學可能習慣性的将其歸結到“全鍊路壓測”中，這個是不全面的，壓測應該貫穿整個大促保障的過程。

壓測分為3種，分别是單點壓測（如：單機壓測和單接口壓測），單鍊路壓測，全鍊路壓測。

• 單點壓測的目标就是考察單點性能，主要用于發現單機或者單接口的性能水位和性能熱點，為了後面計算限流門檻值，評估叢集規模做準備；應該在大促前就開始，随時可以進行，不一定要在正式環境。如果隻是發現性能熱點，可以使用火焰圖分析；如果是評估性能水位，就要進行摸高，一般對于4核8g的機器，至少要摸到load 到5，cpu使用率到75%，記憶體到70%，線程數超過800個，這4個名額至少要達到1個才能算。

• 單鍊路壓測的目标是考慮單鍊路多個應用間多級調用的性能，用于評估某個功能點的水位，為的是應對活動過程中某個業務的量級，評估的目标是整個鍊路中至少一個節點達到性能瓶頸為止。整個鍊路的性能水位，是由最低的那個節點接口/應用 決定的。在壓測過程中，建議摸高，一直摸到其中一個節點達到瓶頸。單鍊路壓測建議在業務給出活動目标後，就要梳理出核心鍊路有那幾條，這幾條核心鍊路是一定要壓測的。需要注意的是，如果有非核心鍊路影響了核心鍊路，那麼大促時這個非核心鍊路要麼做降級預案，要麼改為核心鍊路死保。

• 全鍊路壓測的目标是預演，而不是壓測，這一點跟前面的壓測是完全不同的，需要特别注意，雖然全鍊路壓測本身也會摸高，但是它摸高是預設目标的，比如本次大促50wqps建立，預計摸高也就是120%，不會一直摸高。全鍊路壓測其實是在将各個團隊壓測的結果進行彙總并驗證，是以現在全鍊路壓測一般要去一次通過。這就要求各個團隊要提前調通内部各條單鍊路。

另外，如果鍊路有涉及外部partner，建議一定要在壓測中走通，不要輕易相信外部partner自己的壓測結果，也不能認為“他們承諾了，他們要做到”，這種想法，在大促的時候，partner的承諾無法做到的比比皆是，不要最後坑了自己的業務，導緻業務單子積壓。

6，日常穩定性機制

對于SRE來說，在日常穩定性保障過程中，建立一個行之有效的機制體系，比事必躬親更加重要。一般來說，SRE在日常穩定性保障過程中，要建立的機制如下：

1. 黃金鍊路識别治理機制
2. 值班機制
4. 日常資源（機器、中間件）管控和記賬機制
5. 日常風險和問題報備機制
6. 團隊權限管控機制

7. 日常演練機制

   下面重點說一下黃金鍊路和值班：

6.1，黃金鍊路治理

黃金鍊路，就是核心鍊路，或者說，是團隊的生命線鍊路，由最核心的應用，最關鍵的DB，最需要死保的接口，支撐的最核心業務。是以黃金鍊路的治理就一個目标：不要讓非核心的東西，影響了核心的；這裡的“東西”，包括業務、系統、db；

黃金鍊路治理機制，是要在日常工作中，做如下工作：

1. 每隔一段時間（半個月左右），要統計一次線上訂單各業務單量，有條件的團隊，建議配置設定專門負責資料驅動的人員，建立fbi報表，或者建立資料分析系統。這些資料産出的目标，是統計業務的量級和趨勢，報告最核心單量最大的業務、最容易出問題的業務、和發展最快的業務；
2. 對業務和應用鍊路，按重要性進行劃分。把重要的挑出來，把不重要的，不死人的，可以降級的摘出去；
3. 開始治理，要求核心鍊路上的系統，不能依賴非核心的接口，不能依賴非核心的db。非核心鍊路上的任何降級措施，不能影響核心鍊路的功能；
4. 核心鍊路和非核心鍊路，也不能依賴共同的基礎元件，注意，核心鍊路不等同于核心應用，現在很多核心應用裡的非核心功能太多了。導緻每次改非核心功能，要釋出核心應用，甚至兩者共用底層元件，導緻底層釋出影響上層。比如，非核心功能要改一個消息發送接口，正好核心功能也依賴了這個接口，非核心功能改動裡的bug，可能導緻核心功能挂掉；

5. 核心鍊路和非核心鍊路，要有2套釋出等級，2種監控等級。防止互相影響。

   黃金鍊路治理做好了，團隊出現高等級（P1/P2）故障的可能性會大大降低。

6.2，值班機制建設

值班，既能讓大家熟悉業務，又能讓SRE不那麼勞累，是以，值班人員一方面要響應報警，另一方面要響應工單。SRE要做的事情，是安排好值班表和值班機制，明确值班人員的職責。一般來說，可以如下建設：

• 事前：

• 值班人員必須參與故障演練（包括故障止血方法）以及熟練使用各種故障排查工具。

• 值班人員需要明确值班的範圍，包括預警群、工單群、線上問題回報群、答疑群等；

• 值班人員在值班周期内，應該減少業務工作安排；

• 值班人員的值班周期不宜過長或者過短，以一周為宜；

• SRE應該盡可能的多值班，隻有對業務熟悉的人，才能更加敏銳的發現系統的問題；

• 新進入團隊的同學，應該先值幾個月的輪班，通過值班熟悉業務，是最快的方式；

• 事中：不管是工單問題還是報警，如果短時間無法定位原因的情況，立即把相關人員拉入電話會議，如果遇到卡點，需要把接力棒明确交接給下一位，事後再回顧卡點的原因。對于會影響上下遊的問題（事故），需要立刻通知上下遊，可能引起故障的，需要GOC報備。

• 值班人員自己發現問題後，應該第一時間在群裡回報說進行中，簽到通知其他人已經在處理

• 關閉目前報警的通知（關閉方法集中沉澱到常見問題處理手冊），防止電話打爆掩蓋其他更重要的報警，事後再重開報警（由目前值班人員保證）

• 事後：值班人員和SRE一起組織問題Review，并把涉及到穩定性的操作内容記錄在穩定性流程中。對于常見問題的排查沉澱到一處，後續工具化和演練。

值得注意的是，值班不應該是簡單的人力消耗，應該花費時間開發工具平台，包括問題智能排查、訂單詳情查詢，業務日志軌迹、資料變更軌迹查詢，并且開發問題自動排查、問題解決方案自動推薦機器人，做到自動答疑、自助答疑，減少工單數量，提高問題排查效率。

7，彈性建設

系統的健壯不是沒有報警，也不是不出故障，服務、資料、體驗都不受影響，我們才認為系統是健壯的。一個系統想要健壯，應該具有一定的彈性，系統的彈性展現在系統是：容災的、可自愈的、一定程度上容錯的、可營運的。

這裡，有ufried 在2017年的彈性設計PPT：《Resilient software design in a nutshell》，這個PPT非常清晰準确的闡述了“彈性軟體設計”的概念，下圖取自該PPT：

對于我個人的實踐而言，我自己傾向于重點做好其中的發現、恢複、預防、緩解4個部分。

8，價值建設

我想把“價值建設”這個事情，放到本文的最後，作為對SRE人員提升工作信心的鼓勵。

開發人員容易趨向于實作什麼，如何做到，Dev工作的目标，是電腦螢幕和系統功能；而SRE，很多都是電腦外的工作：上下遊溝通，流量評估，演練組織，資源排程，故障應急，系統治理。工作内容既有代碼裡的ifelse，也有Excel上的各種統計，還有PPT上的各種曲線。很多人覺得這樣的事情很boring，傾向于做一個專心寫代碼的美男子，但是一個開發人員，偶爾擡起頭看着窗外，心裡對那些橫跨多域，排程多個資源，影響力輻射多個團隊甚至BU的人，也有一絲羨慕和無力感。

SRE恰恰給了這樣一個機會，它能讓一個級别不怎麼高的開發人員，排程域内盡可能多的資源，從事多種能夠輻射影響力的機會。

SRE最容易拿到資料，就要去考慮一個問題：價值導向，目前做的事情，有多少資料量，有哪些是無用的長尾的，有哪些可以下線掉。哪些是造成資損的，哪些是需要推動解決的異常訂單，哪些是有巨大價值的。哪些是客戶抱怨最多的，耗時耗人力最大的。

開發人員容易正向思維，而SRE人員，一定要去做反向思維，通過價值來考量，通過價值反推意義，提效降本。

絕大多數情況下，一個好的SRE，和一個差的SRE，差距就展現在3個方面：好的SRE會随時發現和響應問題，會建立體系化，會極其細緻的落地解決方案。 這其中，随時發現和響應，是第一态度，是要持之以恒的心态，而不是一個作秀和表現；落地是基礎，是保障穩定的生命線，細緻的落地，是決定你是走走過場，還是真的做深的根本；體系化是架構，是決定機制能否持久以及你自己累不累的原因。

另外，一個團隊（尤其是業務團隊）的SRE是極度需要老闆的鼎力支援和權力背書的，SRE往往沒有組織架構上的權力，這個時候，老闆真正意義上的支援就很重要，如果一個SRE，你的老闆總是口頭上跟你說穩定性不能松懈，但是幾乎從來不願意在穩定性上給你支援，一心隻想做業務，你就要考慮2個方面：1，是不是你做的不落地，沒有得到老闆信任；2，換個老闆。

但是，如果老闆願意給你時間和空間，也願意投入資源，給你權力，那你就要認真做好SRE這份工作，做出價值。一般來說，老闆願意給你權力的時候，就意味着老闆願意幫你背責任，是以不要怕出錯，要先把态度做出來，老闆會支援你的。但是注意：老闆給你的權力用好了，老闆才會給你背責任，用不好，責任就是你自己的。這一點無論在哪個團隊，無論在哪個層級，都是一樣。

9，團隊招聘

最後的最後，我的團隊招聘啦：

阿裡巴巴零售雲事業部全管道團隊誠招精英（層級不限，開發 or SRE），共同建設面向商家的零售解決方案；

【我們是誰】

我們是阿裡巴巴零售雲事業部-技術部-全管道團隊，主要承接零售雲的全管道線上線下一體化業務；目前是新零售建設的關鍵時期，也是國内2B業務蓬勃發展的重要時期，我們根植于阿裡雲，打造面向商家的全新業務模式，定制商家需要的新零售服務系統，面向彈外提供商業化零售解決方案；

【要做什麼】

我們目前承接新零售模式下多個商家的全管道業務，在系統打造上精耕細作，希望能為您提供在商家協調、服務定制、SaaS化、高可用架構、行業标準化等方面的工作空間，共同探索在商家長期陪伴、多版本、行業标準化和定制化、降本提效等方面的産品化方法；

我們作為一隻商業化技術團隊，也将提供更多的接觸商家的機會、深入了解各個行業特點的機會、以及彈外和阿裡電商體系完全不一樣的玩法機會。

同時，我們也在深耕SRE建設，同步招聘有志于SRE之路的人才。

【有什麼要求】

1. 隻要你有工作熱情，希望體驗新零售、精細化零售業務模式下的新鮮刺激；
2. 隻要你想探索除2C模式電商以外的其他零售商業可行性，了解彈外零售業務的特點；
3. 隻要你有系統隔離、領域設計、高可用、提效降本、業務産品化經驗或者對上述這些感興趣；
4. 或者對面向商家的商業化、新零售業務、标準制定感興趣。

5. 僅面向研發技術同學或SRE同學，要求有3年以上Java開發經驗，有SaaS企業開發經驗或國内大型網際網路開發經驗者優先；

   【工作地點】

阿裡巴巴杭州西溪園區；

【如何聯系】

郵件您的履歷至：[email protected]。