四大黃金支柱#
要深入理解 SRE，必須先掌握它的四大支柱。SRE 沒有一體適用的解法，但無論用什麼方法，最終結果是否能滿足使用者與業務目標，才是衡量成功的標準。
四大支柱為：
- 服務等級目標（Service Level Objective, SLO）與服務等級指標（Service Level Indicator, SLI）
- 監控（Monitoring）
- 緊急應變（Emergency response）
- 變更管理（Change management）
SLO、SLI 與 SLA#
這三個指標是組織衡量服務品質的核心語彙：
- SLA（Service Level Agreement）：組織對外承諾的服務水準，例如「99.9% 可用率」
- SLO（Service Level Objective）：組織對內訂的更高目標，例如「99.999% 可用率」，當 SLO 略有滑落時仍能守住 SLA
- SLI（Service Level Indicator）：實際量測指標，例如延遲（latency）、吞吐量（throughput）、正確率（correctness）
範例：可用率指標的層次#
假設某月 SLA = 99.9% 可用率、SLO = 99.999% 可用率、SLI 以「上線時間百分比」與「吞吐量百分比」量測。當服務出現間歇性失敗時，自動修復把流量轉移到其他伺服器，僅少數客戶受到輕微影響。此時 SLO 與 SLI 會被影響、但 SLA 仍能守住。
制訂指標的關鍵心法#
- 產品團隊應以淺顯可懂的語言定義 SLA 與 SLO，工程師才能落地成 SLI
- 越清晰、越可達成的 SLA/SLO，越能轉化為實際可量測的 SLI
- 不要追求 100% SLA：總會有某個環節出問題，過度承諾就是埋下失敗
監控#
監控是 SRE 的日常核心。系統的可靠性與 SRE 對故障的反應速度息息相關，因此越能主動監控（proactive monitoring）越好。
常見監控指標#
- 上線時間（uptime）：系統可用且運作正常的時間百分比
- 錯誤率（error rate）：失敗請求佔比
- 回應時間（response time）：完成一筆請求所需時間
- MTTR（Mean Time To Recovery，平均修復時間）
- MTBF（Mean Time Between Failures，平均故障間隔）
- 延遲（latency）：請求被處理所需時間
- 資源使用率：CPU、記憶體等
工具與運用#
- 配置儀表板與告警系統量測上述指標
- 告警系統用於即時通知工程師處理失敗或服務中斷
- 儀表板則用於主動觀察系統行為
- 建構自動化以實現自動修復（auto-heal）或自動回復（auto-recover）
不同系統需要不同指標，但每項服務都應配備至少基本監控；指標愈完整，愈能端到端追蹤系統狀態。SRE 的角色正是依據 SLA 排序指標優先級，並設計易讀易理解的儀表板。
常見監控工具：ELK、Prometheus、Grafana、Splunk、Google Analytics、Azure Insights。
緊急應變#
緊急應變即事件管理（incident management），是事故發生時降低客戶衝擊的一整套流程。
五個階段#
- 事件辨識（incident identification）
- 事件登記（incident logging）
- 事件分類（incident categorization）
- 事件優先排序（incident prioritization）
- 事件回應（incident response）
事件分類與優先級會直接決定該事件的 SLA。SLA 是該事件可被接受的回應與解決時間。
工具支援#
- 即時通知團隊有新事件
- 追蹤事件時間軸與工作流
- 自動回覆需求方目前進度
- 與 SDLC 設計階段一同決定要採用哪些工具（程式撰寫、測試、文件、版控、事件管理、監控等）
變更管理#
變更管理是規劃、測試、部署程式碼或設定變更的流程，目的在確保品質、降低風險。
SRE 與 DevOps 圈的名言：「production 沒有任何變更，就什麼都不會壞。」但莫非定律告訴我們，變更不可避免，且越多變更越容易出錯。這正是變更管理被列為 SRE 支柱的原因。
SRE 在變更管理中的角色#
- 在變更規劃初期就介入，提供 production 經驗與風險評估
- 變更部署測試階段同步參與
- 擔任正式環境的守門員（gate keeper），控管變更流向
- 出現問題時，可回溯追蹤是哪一次變更引入故障
案例：電商「貨到付款」功能上線#
一個電商平台要新增「貨到付款」功能。流程如下：
- 業務分析師、產品經理收集需求
- 設計師、SRE、軟體架構師共同決定流程、所需基礎設施與工具
- 開發者撰寫程式並透過變更管理部署到下層環境
- QA 測試後產生報告，SRE 進行效能與混沌測試
- SRE 審查發現「COD 畫面兩次失敗、需手動重啟才正常」的隱性風險——表面看似測試環境的小問題，但 1000+ 同時上線使用者下會造成嚴重失敗
- SRE 退回程式、開發修補、QA 重測，SRE 審核通過後才透過 CI/CD 上線
這段案例完整呈現了變更管理在「品質與可靠性」之間的把關機制，也清楚說明 SRE 為何被視為變更生命週期中不可或缺的角色。
