SRE 為何要在規劃階段現身#

SRE 對 production 有「鳥瞰」級的視野：從使用者請求、基礎設施健康到底層程式碼，無一不知。把這層知識帶到設計初期，可以讓系統一出生就具備：

• 擴充能力
• 自動恢復
• 高負載處理
• 完善的錯誤處理

延續旅遊軟體案例：在指標與守門都到位後，新需求又帶來新缺陷。

三個典型缺陷#

缺陷 1：搜尋與比價服務逾時#

• 服務 1（搜尋）呼叫服務 2（外部競品平台），等 5 秒沒回應就 timeout
• QA 測試時用假回應，無法重現真實 timeout

SRE 建議：服務 1 加入重試（retry）。第一次 5 秒沒回應，再試第二次。雖然無法控制服務 2，但可以提升自家系統韌性。

缺陷 2：資料庫整個叢集中斷時付款服務失敗#

• 設計只支援節點層 health check，沒考慮整個叢集中斷
• SRE 建議：服務取得 400 回應時自動 failover 到另一區域
• 客戶體驗無感

缺陷 3：獎勵服務間歇失敗#

• 獎勵服務仍在舊平台、卻呼叫新平台資料庫
• 因為舊框架無法擴充而 timeout
• SRE 建議：要嘛盡早把獎勵服務也搬到新平台，要嘛建一支夜間同步服務把資料推到 cache 提供給獎勵服務查詢
• 這不是根治，但能立刻提升可靠性

SRE 在 SDLC 各階段的價值#

• 規劃：在架構討論時提供 production 視角，挑出設計上的隱患
• 實作：早一步準備新功能的告警與監控
• 測試：在混沌測試中加入新場景
• 部署：依照規劃時的觀察執行健全性檢查
• 維運：與設計階段的決策一致地監控與調整

規劃階段的 1 小時 SRE 投入，可能省下後期數十小時的修補。SRE 不是開發的後段品管，而是設計的全程夥伴。

SRE 作為混沌與效能工程師#

傳統 SDLC 把效能測試交給專責團隊；混沌測試甚至常被略過。SRE 接手這兩件事，是因為他們對 production 最了解。

案例：飯店搜尋服務失靈#

• 客戶連兩次搜尋飯店都看到「頁面無法載入」
• SRE 看到 HTTP 400
• 調查發現：某資料庫叢集整個不可用，負載平衡器嘗試切到另一個實例也失敗
• 真正的原因是「資料庫不可用且 LB 無法回傳合適錯誤」

為什麼 QA 沒抓到#

• 測試案例只模擬「單一實例下線」
• 沒覆蓋「整個叢集下線」這個極端情境

SRE 的解法#

• 把「整個資料庫不可用」加進混沌測試
• 開發為服務加入錯誤處理：把資料儲存於記憶體 cache，必要時顯示「應用維護中」訊息
• 用快取提供結果，給客戶可預期的提示

混沌測試的場景設計就是 SRE 對 production 認知的最佳體現。把 SRE 的視野化為混沌劇本，是設計與運維間最有價值的橋樑。

教訓#

• SRE 早期介入會把整個 SDLC 的可靠性同步抬高
• 混沌與效能測試是 SRE 把「production 視野」帶回設計的具體載具
• 跨階段的協作不能只靠制度——要靠習慣，而習慣靠領導者持續推動