1、SRE體系工作流

　（1）故障預防階段：主動構建系統韌性

　　從技術規範和架構設計層面，推動系統具備抗風險能力。

• 向開發團隊傳遞“面向失敗編程“理念，明確RPC異常處理、分佈式事務一致性等編碼要求。
• 主導或參與框架治理能力建設，包括設計熔斷限流策略、配置失敗重試機制、定義數據中間態規則等，從架構層降低故障概率。

（2）故障發現階段

• 監控策略設計：規劃全鏈路監控方案，明確需埋點的關鍵鏈路（如RPC調用、核心業務事件）及日誌格式。
• 告警規則制定：基於業務SLA（服務等級協議），在監控系統中配置告警閾值與規則，確保異常（如錯誤率突增、延遲超標）能觸發精準告警。

（3）故障處理階段

• 告警響應：接收告警後，第一時間通過監控看板（如Grafana）定位故障根源（如服務節點異常、依賴組件故障）。
• 應急操作：通過治理平台執行緊急操作（如流量切換、服務重啓），或協調開發團隊進行代碼熱修復，快速恢復服務。
• 經驗固化：將高頻問題的排查步驟（如“數據庫連接池耗盡排查流程”）整理為標準化文檔或看板模板，提升團隊協作效率。

（4）故障覆盤

• 覆盤組織與輸出：主導故障覆盤會議，梳理故障根因（如“配置錯誤”“容量不足”），輸出包含改進方案的覆盤報告。
• 流程與工具迭代：將覆盤結論轉化為可落地的行動，如優化監控指標、更新治理平台功能（如新增“一鍵擴容”按鈕），避免同類故障重複發生。

2、SRE面臨的挑戰

（1）如何衡量服務可用性

　　第一種是考慮時長。

• MTTF（平均無故障時間）：指系統無故障運行的平均時間
• MTTR（平均修復時間）：系統從發生故障到維修結束之間的時間段的平均值
• MTBF（平均失效間隔）：兩次故障發生時間之間的時間段平均值

　　MTBF = MTTF + MTTR。衡量穩定性：AO = MTBF / (MTBF + MTTF)

　　第二種是從服務質量來看：請求維度：成功率 = 成功請求數/總請求數

　　這裏不能統計單個請求，而是看一段時間的概率分佈，如5xx佔比。計算一段時間的5xx佔比達到5%，持續10min。這一塊一般用幾個9來衡量。

　　在定目標前要想清楚3件事：1）花多少錢；2）業務能接受多少“小意外”（比如視頻網站和支付系統的容忍度就不同）；3）系統現在的“底子”如何（若系統本身遺留的技術債務過多，強行定太高目標可能不現實，得先修復基礎問題）。

　　3個9：指系統全年可用時間達到99.9%，這個目標比較容易實現，成本也低。

　　4個9：指全年可用時間達到99.99%，全年最多隻能“崩8.76小時”，這個目標對技術、人力、硬件的要求極高，投入成本會成倍增加）。

　　選擇穩定性目標涉及了測量方法和判斷方法，包含三個要素：

• 衡量指標：如5xx比例
• 衡量目標：總訪問量（QOM）code=200佔比小於95%
• 影響時長：QPM是一個聚合指標，也是應該在一個時間跨度上去計算次數。

　　這裏的衡量指標就是SLI，目標是SLO，如果針對服務質量還有SLA。

（2）如何選擇合適的SLI，設置合理的SLO

　　Google提出的五大“黃金指標”：容量、可用性、時延、錯誤率、人工介入。

（3）如何及時發現問題

　　若選擇好了指標，接下來要採集數據提煉出想要的指標。

　　SRE工具及主要從數據源採集，分析生成監控指標，判定這些指標閾值觸發告警後，及時響應。包括以下幾個部分：

• 數據採集：將收集的數據發佈到Kafka。
• 數據分析：流式分析和離線分析。比如有鏈路分析，分析鏈路的依賴拓撲關係，找出循環調用、慢接口、慢SQL、雙向依賴等常見的風險點。
• 數據存儲：監控常用Prometheus，但它原生不支持分佈式存儲，我們可以採用其他工具進行遠程存儲。針對存儲時間長的會採用稀疏存儲模式，大量採用物化視圖聚合數據。
• 監控畫像：日誌查看主要基於EKL體系，Grafana用於分析後的指標聚合展示。
• 告警通知：可以接入企業羣聊等，讓整個處理流程移動化。
• 告警響應

3、SRE切入點：推進技術債務改造

　　技術債務分為三類：不良代碼積累；業務建模；業務架構設計。

• 不良代碼積累：隨着服務迭代，需求變更、爛代碼的引入、建模的不合理，就會帶來一些技術債務。這樣就會使得服務穩定性越差，積累更多技術債務，從而形成惡性循環。
  • 原因：1）工程師以完成當前項目功能為導向，但大部分情況下，項目結束後就沒有下文了。2）沒有保持最小依賴的原則，有些組件可能只需要其中的某個功能，但直接引入了整個組件，這個組件又依賴其他的組件，後續可能沒人負責迭代，從而變成不定時炸彈。
• 業務建模 & 業務架構設計
  • 未理解SOLID設計原則：單一職責、開閉原則、里氏替換、接口隔離、依賴反轉
  • 過早的引入不需要的設計：雖然微服務是當前主流，新項目一開始就拆分成不同的服務，為了適應這個複雜的服務調用流程不得不付出很多人力成本。好的架構是支持漸進式的，沉澱出特定領域邏輯，等到合適的時候再拆分，或者隨業務的發展變化還能支持聚合。
  • 邊界劃分不合理：
  • 依賴不合理：高層策略依賴底層組件。

4、基於鏈路分析找出潛在風險

（1）慢接口：這會嚴重影響服務的吞吐量，最終反饋到用户體驗上，造成客户流失。這裏不採用平均耗時，因為接口延遲滿足長尾效應，延遲越大危害越大，所以優先優化延遲高的接口。一般蔡康永接口的延遲百分位第99位來衡量（如後端服務P99<100ms，即99%的服務響應時間都是小於100ms的）

（2）異常接口：接口錯誤率，實時反映服務可用性。根據業務哦讓人都可用性可以設置成3個9或4個9.

（3）慢sql：隨業務迭代，未經優化的SLQ可能會產生雪崩。

（4）穩定依賴：能不依賴就不依賴，能少依賴就少依賴，儘量依賴穩定的方向。

參考：

https://www.infoq.cn/article/vbufppurg9lfelrogx3t

設置穩定性目標一般需要考慮：成本，業務容忍度，當前業務的現狀。大部分時候 4 個 9 目標比 3 個 9 目標投入成本要高很多。有些底層的服務，穩定性要求就比一般配套服務的高。比如 doctor 醫生服務的穩定性就需要 99.99，它一旦有問題很可能就是波及全站的範圍。由於很多歷史原因，“大泥球”的服務積累的技術債務會很多。這時候針對這個服務定一個合理的指標，比定一個標準的指標要好很多。