前言
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，【數據化】
穩定性工作，如果要拿到結果，做到可量化，可度量，就一定要在數據化上下功夫，這個數據化，包括如下幾個方面：
- 數據驅動：包括日誌標準化和錯誤碼標準化，能夠對日誌和錯誤碼反饋的情況進行量化；
- 數據對賬：包括上下游對賬、業務對賬，能夠通過對賬，保障域內數據校準；
- 軌跡跟蹤：包括變更軌跡和數據軌跡，目標是實現數據的可跟蹤，和變更的可回溯、可回滾；
- 數據化運營：主要是將穩定性的指標量化，比如工單解決時間、工單數、報警數、報警響應時間、故障風險數、代碼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應該是“直觀簡潔、指標核心、集中聚焦”。在大盤上，我認為要包括以下要素：
- 最核心業務入口的qps、rt、錯誤數、成功率，從這個維度可以看到入口流量的大小和相應時間，成功率。這一點，是在知道入口的健康情況；
- 錯誤碼top N，這個維度可以看到系統運行過程中最核心的錯誤，快速直觀定位問題原因（這個需要打通上下游錯誤碼透傳）。這一點，是在快速知曉問題出在哪裡；
- 按業務維度（業務身份、行業、倉儲、地區等，根據實際需要決定）分類統計計算的單量、或分鐘級下單數量，用於確定核心業務的單量趨勢。這一點，只在知道自身業務的健康情況；
- 核心下游依賴接口、tair、db的qps、rt、錯誤數、成功率，需要注意的是，這個一般比較多，建議只放最核心、量最大的幾個。這一點，是在知道下游依賴的健康情況；
- 其他影響系統穩定性的核心指標，如限單量，核心計數器等，根據各個團隊的核心來決定。這一點，是在個性化定義關鍵影響點的監控情況；
2.3，避免監控信息爆炸
在SRE的實踐過程中，為了保證監控的全面，往往會增加很多報警項，報警多了之後，就會像洪水一樣，漸漸的SRE對於監控就不再敏感了，讓SRE比較煩惱的一個問題，就是如何做監控報警瘦身？
目前一般來說，我們的監控報警至少包括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個小時要有一次）刷一下報警群，如果報警群裡的新增條數在20條以內，問題一般不大，刷一刷就行；
- 如果突然一段時間內報警陡增，就要看一下具體是什麼問題了，小問題直接處理，大問題分工組織協調；
- 消防群中的問題，要及時同步到團隊中；
- 值班群中的工單，需要關注，並有一個初步的判斷：是否是大面積出現的業務反饋；是否有擴大的隱患；
要做到“有效”兩個字，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同學，不管大的政策怎麼樣，還是要關注團隊內部的場景本身：
- 對於系統性故障注入（load、cpu、fullGC、線程池等），直接套用集團的mk注入即可；
- 對於服務型故障注入（下游異常、超時，接口超時、限流），mk也有比較好的支持；
- 對於訂單異常型故障注入，要自主開發較好的錯誤訂單生成工具，注入異常訂單，觸發故障報警；
- 對於調度、積壓型故障注入，要關注schedulex、異步消息的故障注入方式，同時防止積壓阻塞正常訂單影響真正的線上業務；
同時，在演練前後，要注意跟老闆的溝通，要讓老闆理解到你組織的演練的目標和效果，不然就不是演習，而是演戲了。要和老闆的目標契合，在演練過程中，通過演練提高大家對業務場景的理解深度和對問題的應對速度，增加大家的穩定性意識，達到“因事修人”的目的。
3.4，故障應急過程
如果不幸真的產生了故障，作為SRE，要記得如下信息：
- 冷靜。作為SRE，首先不能慌，沒有什麼比儘快定位和止損更重要的事情
- 拉電話會議同步給大家信息。記住，在出現故障時，沒什麼比電話會議更加高效的溝通方式了；
- 參考前面1.4.1節中的SRE人員快速響應流程，在電話會議中同步給大家：
• 儘快告知當前告警已經有人接手，是誰接手的，表明問題有人在處理了。（這一步叫“響應”）
• 組織人員，快速定位問題，告知問題初步定位原因（這一步叫“定位”）。
• 初步影響範圍是什麼？給出大致數據（這一步方便後面做決策）
• 有哪些需要老闆、產品、業務方決策的？你的建議是什麼？（這一步很關鍵，很多時候是：兩害相權取其輕，你的評估和建議，直接影響老闆的決策）
• 當前進展如何，是否已經止血？（這一步是“恢復”，要給出“進展”，讓決策者和業務方瞭解情況）
- 組織大家按照故障場景梳理的應對方案進行應對，如果沒有在故障場景列表中，一定要組織最熟練的人員進行定位和恢復。
- 故障過程中，對外通信要跟團隊和老闆統一評估過再說；
- 處理故障過程中，要隨時組織同學們進行影響數據撈取和評估，撈出來的數據，要優先跟老闆、業務熟練的同學一起評估是否有錯漏。
- 在處理完故障後，要及時組織覆盤（不管GOC是不是統一組織覆盤，內部都要更加深刻的覆盤），覆盤流程至少包括：詳細的時間線，詳細的原因，詳細的定位和解決方案，後續action和改進措施，本次故障的處理結果。
我個人其實不太贊同預案自動化和強運營的故障應急方案，這一點也是給安全生產同學的建議，比如預案自動化，有很強的侷限性，只有在明確預案的執行肯定不會有問題、或者明顯有優化作用的情況下，才能自動執行。否則都應該有人為判斷。
強運營類的工作，會導致人走茶涼，比如GOC上自動推送的預案，故障場景關聯的監控這種，一方面應該儘量減少強運營的工作，另一方面應該定期組織維護一些必要預案。
3.5，與兄弟團隊的關係
如果兄弟團隊發生故障，一定注意：
- 不能嘲笑別人，看笑話；
- 不能當沒事人，高高掛起，要檢查自身；
- 不能話說的太滿，比如說我肯定沒故障。
尤其是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，業務團隊大促保障的一般流程
一個完善的大促保障包括如下步驟（可參考下面的作戰地圖）：
- 明確本次大促的作戰地圖，明確時間節點和步驟；
- 輸入活動玩法和節點，明確關鍵時間點和GMV目標、單量峰值；
- SRE產出備戰報告，其中包括保障目標，大促保障時間節奏，作戰地圖，流量地圖（如果已經繪製出來的話），資源規劃地圖，業務新的變化和技術的挑戰，上下游鏈路依賴圖，核心風險和專項分工（精確到人和完成時間），同時SRE要指定監控、壓測、演練、預案專項負責人（leader要為SRE放權和背書）。
- SRE繪製流量地圖，明確接口流量，模塊鏈路，關鍵風險。
- SRE和開發同學共同梳理上下游接口依賴流量和峰值，給出限流閾值並溝通上下游；
- 開始鏈路梳理，一般由熟悉業務和系統的開發同學梳理，然後拉上上下游、梳理同學、測試同學、SRE、leader一起review，review時，SRE要產出5個點：強弱依賴、風險點、限流、降級預案、新業務特徵；
- 根據梳理出來的風險點展開集中治理，大的風險點要開專項治理，這一階段要全員聽調，風險點要各自去做，SRE只負責把控全局、跟蹤進度、驗收結果。
- 治理完成後，開展監控走查，更新監控大盤，建議由SRE指定監控專人負責；
- 壓測開始前配置限流，壓測過程中還要不斷根據情況調節限流值；
- 開始壓測，分為專項重點壓測（一般單接口、單機），上下游壓測，全鏈路壓測，建議由SRE指定壓測責任人；
- 錄入預案，並對預案進行測試和驗證，拉上業務、產品、測試一起，組織預案演練，驗證預案可行性，要求業務方知曉預案執行後的影響。建議由SRE指定預案和演練責任人。
- 上述過程中都要記錄未完成點和check點，在大促前，要對checklist 逐項check；
- 產出作戰手冊，包括值班表，工具清單，大促期間作戰流程（精確到分鐘級的操作時間點和人員），再次通知業務側相關預案的影響。
- 大促開始前一天，SRE要進行戰前宣講，一般包括大促期間發佈流程、審批流程、白名單人員名單，工單彙報方法，大促交流群，大促期間的紅線和注意事項。
- 大促結束後，要進行復盤，覆盤內容包括：目標是否達到，大促期間達到系統指標、單量，系統、業務的能力亮點，大促保障期間大家做的工作彙總，保障期間的產出亮點，後續action項，未來保障的思考和計劃。
5.2，作戰地圖
下面一張圖，比較詳細的介紹了整個雙十一作戰的過程：一次大促保障，大致分為前期的容量評估和準備階段，中間的系統健壯性提升階段，後面的壓測摸底、預案演練階段，最後的戰前check和值班階段。其中前2個階段才是核心。
在這張作戰地圖中：
- 容量準備階段，重在根據業務活動節點，輸入流量和單量，梳理上下游流量壓力，繪製流量地圖，統計上下游接口壓力，評估限流閾值和資源缺口，同時準備資源。這個階段是關鍵階段
- 系統健壯性提升階段，重在鏈路梳理和風險發現，對發現的風險進行專項治理。這個階段是最核心階段
- 在壓測階段，不能只被動的參加全鏈路壓測，還要優先在自己域內進行單點壓測和上下游鏈路壓測，這樣在全鏈路壓測的時候才不會掉鏈子。同時，壓測要關注幾個事情：1，有沒有達到流量預期；2，有哪些點是瓶頸點；3，對瓶頸點如何解決，如何降級或限流？4，上下游在壓測過程中有沒有可能與自己域相互影響的地方；
- 在預案&演練階段，要注重實效，不要走形式化，演練的目的是驗證預案的可行性和可操作性，不是為了證明“我演練過了”，如果預案不進行演練，在大促時就有可能出現：1，不敢執行預案，因為不知道會發生什麼；2，執行了預案之後發現有坑；3，執行了預案之後發現無效；
- 在戰前準備階段，重在檢查和宣講，檢查要查缺補漏，要有checklist，一項項check；宣講要有作戰手冊和紅線，作戰手冊要精確到時間點和人，每個時間點由誰做什麼要明確；紅線一定要宣講清楚，大促是一場戰役，如何報備，如何響應工單，各自分工是什麼，哪些紅線不能踩，要明確到位，避免低級騷操作帶來的風險。
下面重點介紹容量準備階段（流量地圖和評估）和系統健壯性提升階段（梳理和治理）；
5.3，流量地圖&流量評估
繪製流量地圖的目的，是讓SRE人員對於域內和上下游流量有明確的瞭解，在心中有一張全局流量的“圖”。流量地圖應該包括幾個要素：
- 系統核心模塊和模塊間的依賴關係；（用方塊和連線標識）
- 核心功能流量流向；（用不同顏色的連線區分）
- 核心接口/功能的單量或qps；（在接口上方標註）
- 鏈路上的主要風險點；（用紅色方塊標註）
在進行流量評估時，關鍵在於要明白上下游依賴、是否有緩存、平時單量和大促單量：
本域應用名
對方域
對方應用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
限流
降級預案
強弱依賴
新業務
功能描述，根據功能進行劃分
將場景細粒度細分，列表化
可能存在的風險點
當前場景的限流評估
當前場景可能存在的降級預案
上下游間的強弱依賴，強依賴的要關聯預案、限流、降級等
當前場景從上次大促到現在的增量變更
梳理的目的不是僅僅評估風險，更重要的是治理，治理不一定是代碼層面的升級，可能有如下方式：
- 對可能有流量尖峰、造成系統衝擊的接口，加特殊限流，如全侷限流、線程數限流；
- 對流量尖峰，加dts等異步任務，進行削峰填谷；
- 對需要做降級的地方加降級預案；
- 對需要兜底容災的地方加自動兜底；
- 對強依賴的下游接口，加本地緩存或tair緩存（慎之又慎，同時下游絕對不能期待上游加緩存來降低訪問量）；
- 治理的時候，要注意幾個最容易出問題的地方：緩存、異步消息、異步任務、數據庫量級、數據庫關聯查詢量或批量更新量（比如1主單關聯N子單的情況）、接口超時時間、重試次數、冪等、sql limit和查詢上限；
- 需要提前禁寫的，要產出禁寫預案
- 對大促期間可能隨時調整的業務參數，要留出口子，方便調整，做好審批流程報備流程、check流程；
在鏈路治理時，建議可以建立一個aone項目空間或者lark表格，將所有要做的事情，列成工作項，每完成一項勾掉一項，當所有工作項都完成時，項目就結束了，治理也達到了一個水平。
5.5，壓測
在大促保障過程中，提到壓測，有同學可能習慣性的將其歸結到“全鏈路壓測”中，這個是不全面的，壓測應該貫穿整個大促保障的過程。
壓測分為3種，分別是單點壓測（如：單機壓測和單接口壓測），單鏈路壓測，全鏈路壓測。
• 單點壓測的目標就是考察單點性能，主要用於發現單機或者單接口的性能水位和性能熱點，為了後面計算限流閾值，評估集群規模做準備；應該在大促前就開始，隨時可以進行，不一定要在正式環境。如果只是發現性能熱點，可以使用火焰圖分析；如果是評估性能水位，就要進行摸高，一般對於4核8g的機器，至少要摸到load 到5，cpu利用率到75%，內存到70%，線程數超過800個，這4個指標至少要達到1個才能算。
• 單鏈路壓測的目標是考慮單鏈路多個應用間多級調用的性能，用於評估某個功能點的水位，為的是應對活動過程中某個業務的量級，評估的目標是整個鏈路中至少一個節點達到性能瓶頸為止。整個鏈路的性能水位，是由最低的那個節點接口/應用 決定的。在壓測過程中，建議摸高，一直摸到其中一個節點達到瓶頸。單鏈路壓測建議在業務給出活動目標後，就要梳理出核心鏈路有那幾條，這幾條核心鏈路是一定要壓測的。需要注意的是，如果有非核心鏈路影響了核心鏈路，那麼大促時這個非核心鏈路要麼做降級預案，要麼改為核心鏈路死保。
• 全鏈路壓測的目標是預演，而不是壓測，這一點跟前面的壓測是完全不同的，需要特別注意，雖然全鏈路壓測本身也會摸高，但是它摸高是預設目標的，比如本次大促50wqps創建，預計摸高也就是120%，不會一直摸高。全鏈路壓測其實是在將各個團隊壓測的結果進行彙總並驗證，所以現在全鏈路壓測一般要去一次通過。這就要求各個團隊要提前調通內部各條單鏈路。
另外，如果鏈路有涉及外部partner，建議一定要在壓測中走通，不要輕易相信外部partner自己的壓測結果，也不能認為“他們承諾了，他們要做到”，這種想法，在大促的時候，partner的承諾無法做到的比比皆是，不要最後坑了自己的業務，導致業務單子積壓。
6，日常穩定性機制
對於SRE來說，在日常穩定性保障過程中，建立一個行之有效的機制體系，比事必躬親更加重要。一般來說，SRE在日常穩定性保障過程中，要建立的機制如下：
- 黃金鍊路識別治理機制
- 值班機制
- 覆盤機制
- 日常資源（機器、中間件）管控和記賬機制
- 日常風險和問題報備機制
- 團隊權限管控機制
- 日常演練機制
下面重點說一下黃金鍊路和值班：
6.1，黃金鍊路治理
黃金鍊路，就是核心鏈路，或者說，是團隊的生命線鏈路，由最核心的應用，最關鍵的DB，最需要死保的接口，支撐的最核心業務。所以黃金鍊路的治理就一個目標：不要讓非核心的東西，影響了核心的；這裡的“東西”，包括業務、系統、db；
黃金鍊路治理機制，是要在日常工作中，做如下工作：
- 每隔一段時間（半個月左右），要統計一次線上訂單各業務單量，有條件的團隊，建議分配專門負責數據驅動的人員，建立fbi報表，或者建立數據分析系統。這些數據產出的目標，是統計業務的量級和趨勢，報告最核心單量最大的業務、最容易出問題的業務、和發展最快的業務；
- 對業務和應用鏈路，按重要性進行劃分。把重要的挑出來，把不重要的，不死人的，可以降級的摘出去；
- 開始治理，要求核心鏈路上的系統，不能依賴非核心的接口，不能依賴非核心的db。非核心鏈路上的任何降級措施，不能影響核心鏈路的功能；
- 核心鏈路和非核心鏈路，也不能依賴共同的基礎組件，注意，核心鏈路不等同於核心應用，現在很多核心應用裡的非核心功能太多了。導致每次改非核心功能，要發佈核心應用，甚至兩者共用底層組件，導致底層發佈影響上層。比如，非核心功能要改一個消息發送接口，正好核心功能也依賴了這個接口，非核心功能改動裡的bug，可能導致核心功能掛掉；
- 核心鏈路和非核心鏈路，要有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之路的人才。
【有什麼要求】
- 只要你有工作熱情，希望體驗新零售、精細化零售業務模式下的新鮮刺激；
- 只要你想探索除2C模式電商以外的其他零售商業可行性，瞭解彈外零售業務的特點；
- 只要你有系統隔離、領域設計、高可用、提效降本、業務產品化經驗或者對上述這些感興趣；
- 或者對面向商家的商業化、新零售業務、標準制定感興趣。
- 僅面向研發技術同學或SRE同學，要求有3年以上Java開發經驗，有SaaS企業開發經驗或國內大型互聯網開發經驗者優先；
【工作地點】
阿里巴巴杭州西溪園區；
【如何聯繫】
郵件您的簡歷至：[email protected]。