大家好，我是Edison。
五一假期，沒出遠門，帶娃露營玩水玩沙騎平衡車，累的不亦樂乎。同時，也刷了一門極客時間的課程《SRE實戰總結》，給我帶來了一些新的認知，我將這些認知整理了以下，特此總結分享與你，強烈建議已經實踐了DevOps的童鞋瞭解一下SRE。
什麼是SRE？
SRE全稱Site Reliability Enginering，站點穩定性工程。站在不同角色人員的角度會有不同的認知和解讀，但從中立和全局角度來看，SRE其實和PMBOK（項目管理PMP認證的教材）一樣提供的是一套體系化的方法，這套方法可以幫助我們保障我們的IT系統的穩定性，進而交付更大的用戶價值。
既然是體系化，就得有一系列的規劃和措施，下面這張圖可能是課程中最大的亮點：
對，這張圖就像是PMBOK中的五大過程組和49個子過程一樣的存在，用於標準化的指導我們的保障工作全旅程。可以看到，這個所謂的框架圖，裏面很多的事情其實我們已經在做了，還有些沒有做，不過他們也都還比較常見。但是，一旦它們結合起來形成一套穩定的體系，這套體系發揮出的力量就大了，也會告別只發揮某項技術的能力。因此，可以看出：SRE的建設需要高效的跨團隊組織協作，而不是依賴單一崗位解決所有穩定性問題。
做SRE的目的是什麼？
做SRE的目的，從本質上來看，其實就是 減少系統故障時間，增加系統正常運行時間。換句話說，就是“減少故障，提升MTBF；同時，提升故障處理效率，降低MTTR”。SRE要做的所有事兒，其實都是圍繞這兩個目標來服務的。
NOTE：從業界穩定性通用的衡量標準看，有兩個非常關鍵的指標：
-
MTBF，Mean Time Between Failure，平均故障時間間隔。
-
MTTR，Mean Time To Repair， 故障平均修復時間。
通俗地說，MTBF 指示了系統正常運行的階段，而 MTTR 則意味着系統故障狀態的階段。
SRE和DevOps有什麼區別？
DevOps 核心是做全棧交付，SRE 的核心是穩定性保障，關注業務所有活動，兩者的共性是都使用軟件工程解決問題。
DevOps 的誕生是由於互聯網商業市場競爭加劇，企業爲減少試錯成本，往往僅推出最小可行產品，產品需要不斷且高頻地迭代來滿足市場需求，搶佔市場（產品的迭代是關乎一整條交付鏈的事），高頻的迭代則會促使研發團隊使用敏捷模式，敏捷模式下對運維的全棧交付能力要求更嚴格，運維必須開啓 DevOps 來實現全棧交付。因爲不斷的迭代交付（也就是俗稱的變更）是觸發故障、非穩定性的根源，而對於互聯網產品來說，服務穩定性缺失會造成用戶流失，甚至流到競爭對手那裏， 因此關注業務穩定性也變得十分重要，SRE 由此誕生。
DevOps 的出發點是“更加高效地交付用戶價值”，而 SRE 的出發點是“保障和提升系統穩定性”，兩者要做的事情其實本質上差別不大，但是角度不同，那麼在執行的時候，要解決的問題也就會有所差異。
實踐SRE的切入點是什麼？
SRE涉及的範圍很大，我們應該從哪裏入手呢？
首先，要明確 SRE 關注的穩定性是系統的整體運行狀態，而不僅僅只關注故障狀態下的穩定性，在系統運行過程中的任何異常，都會被納入穩定性的評估範疇中。因此，SRE 會更多地採用請求維度的統計方式，即 Availability = Successful request / Total request，而我們常見的系統可用性的幾個9就是基於這個維度的一個可量化的實現：
其次，要切入SRE，推薦的做法就是“選擇合適的SLI，設定對應的SLO”。例如，“狀態碼爲非 5xx 的比例”就是 SLI，“大於等於 99.95%”就是 SLO。換句話說，SLO 是 SLI 要達成的目標。
NOTE：SLI 就是我們要監控的指標，SLO 就是這個指標對應的目標。
常見的SLI即系統監控指標如下圖所示：
常見的SLO的計算方式如下：
-
第一種：直接根據成功的定義來計算
-
比如：Successful = （狀態碼非 5xx） & （時延 <= 80ms）
-
第二種：複合定義來計算
-
SLO1：99.95% 狀態碼成功率
-
SLO2：90% Latency <= 80ms
-
SLO3：99% Latency <= 200ms
-
Availability = SLO1 & SLO2 & SLO3 => 即只有當這3個SLO同時達標，整個系統的穩定性纔算達標。
當設計定好了這些指標，在實踐SRE時最重要的方法就是“以賽代練”，即通過事先考慮自己的業務系統的極端場景到底是什麼，然後基於這些場景去設計和規劃。而這些“以賽帶練”的事情，會有一部分轉化爲例行工作，同時還會增加一些週期性的工作。
如何處理故障的發現、處理 和 覆盤？
對於線上故障的處理實踐中，耗時最多的就是故障的發現階段。要提高故障發現的效率，就得建設好On-Call機制。老師在課程中分享了一個On-Call關鍵5步法：
- 確保關鍵角色在線；
- 組織 War Room 應急組織；
- 建立合理的呼叫方式；
- 確保資源投入的升級機制；
- 與雲的聯合 On-Call。
而對於故障的處理，只有一條基本原則：“一切處理活動皆以恢復業務爲最高優先級”。故障處理過程中效率如何，其實取決於三個因素：
- 技術層面的故障隔離手段是否完備；
- 故障處理過程中的指揮體系是否完善，角色分工是否明確；
- 故障處理機制保障是否經過足夠的演練。
可以看到，想要真正高效處理故障，並不是在技術層面做到完備就可以了，這的確是一個需要體系化建設和反覆磨鍊才能達成的目標。
如果只處理故障，不對故障覆盤也是不行的。而要做好覆盤，我們可以通過黃金三問 和 故障判定三原則。
故障覆盤黃金三問：
- 第一問：故障原因有哪些？
- 第二問：我們做什麼，怎麼做才能確保下次不會再出現類似故障？
- 第三問：當時如果我們做了什麼，可以用更短的時間恢復業務？
具體開復盤會時，我們應該圍繞這三個問題來進行，不允許出現互相指責和埋怨的情況，如果出現，會議主持者需要及時控制和打斷！
故障判定三原則：
- 健壯性原則
- 業務應用需要提高快速恢復能力
- 第三方默認無責任原則
- 比如雲廠商的各類CDN、OSS等服務
- 分段判定性原則
- 將一次故障分段判斷，各自完善改進措施
來自《Google SRE運維解密》的經典名句：“故障是系統運行的常態，正常纔是特俗狀態”。對於我們而言，無論什麼角色，都要以一顆平常心來對待故障，鼓勵改進，並持續改進。
實踐SRE也是在革新生產協作關係
高效的故障應對和管理工作，其實是需要整個技術團隊共同參與和投入的。那麼這也就必然涉及到生產協作關係的革新，換據說說就是組織架構的調整，這是因爲：
-
組織架構需要和技術架構相匹配
-
SRE是微服務和分佈式架構的產物
如果我們去梳理一下整個軟件架構發展的歷程，就可以得到下面這張圖。我們會發現不僅僅是 SRE 和 DevOps，就連容器相關的技術，持續交付相關的方法和理念，也是在微服務架構不斷流行的趨勢下所產生的，它們的產生就是爲了解決在這種架構下運維複雜度過高的問題。
總的來說，如果我們的技術架構朝着微服務和分佈式的方向演進，那我們可以考慮落地 SRE，這時候，我們的組織架構就要匹配我們的技術架構，也就是說，要想在組織內引入並落地 SRE 這套體系，原有技術團隊的組織架構，或者至少是協作模式必須要做出一些變革纔可以。
蘑菇街的SRE組織架構實踐
老師在課程中分享了蘑菇街的SRE組織架構實踐，如下圖所示。可以看到，SRE 並不是一個單純的崗位定義，它是由多個不同角色組合而成的一個團隊。
參考資料
極客時間，趙成，《SRE實戰總結》
推薦學習
Microsoft Learn，《制定站點可靠性工程（SRE）策略》
