在數位化的時代，軟體系統不僅要能快速迭代，更必須維持高度的可靠性。這也是 SRE（Site Reliability Engineering，網站可靠性工程） 出現的原因。它源自 Google，將軟體工程的思維應用在系統運維中，以程式碼和自動化的方式來提升可用性與穩定性。

什麼是 SRE？

SRE 的精神在於：以工程化方法來解決傳統運維的問題。過去，系統維護往往依賴人工操作，容易發生錯誤且難以擴展。而 SRE 主張把這些任務轉換為程式碼，例如：自動化部署、自動監控、故障回復機制，讓大規模系統的管理更高效、更具一致性。

簡單來說，SRE 是在 快速變動（新功能上線） 與 系統可靠（穩定運行） 之間找到平衡的一門學問。

為什麼 SRE 重要？

1. 可靠性是競爭力

   系統穩定才能贏得使用者信任，否則再多功能也無法挽回糟糕的體驗。

2. 支撐大規模應用

   在流量瞬間暴增時，自動化的 SRE 機制能快速擴展，避免網站宕機。

3. 降低維運成本

   透過程式碼取代重複性人工操作，減少錯誤率，同時釋放人力去專注在更有價值的工作上。

SRE 的主要原則

1. 服務水準管理（SLA / SLO / SLI）

   在 SRE 的框架裡，可靠性通常透過三個核心元素來量化：

   • SLA（Service Level Agreement，服務水準協議）

     指組織與客戶之間的正式承諾，通常寫入合約。例如保證網站 99.9% 正常運行時間，若未達標，可能需要退款或提供補償。

   • SLO（Service Level Objective，服務水準目標）

     是內部設定的具體可靠性目標，幫助團隊追蹤服務品質。例如設定 API 平均回應時間低於 200 毫秒。

   • SLI（Service Level Indicator，服務水準指標）

     是用來衡量服務表現的實際數據，例如：錯誤率（Error Rate）、延遲（Latency）、可用性（Availability）。SLI 的數值會與 SLO 比較，用來判斷是否達成目標。

   這三者之間的關係可以這樣理解：

   -SLI 提供事實數據，

   -SLO 訂出內部的努力目標，

   -SLA 則是對客戶的外部承諾。

2. 錯誤預算（Error Budget）

   SRE 不追求 100% 完美，而是允許一定比例的失敗。這樣能在「快速上線」與「保持穩定」之間取得彈性。

3. 自動化

   從監控、警示、部署到修復，盡可能用程式實現，降低人力操作帶來的風險。

4. 持續改進與學習

   發生故障後，SRE 會進行 Blameless Postmortem（無責檢討），聚焦在改善流程，而不是責怪個人。

如何衡量 SRE 成效？

常見的可靠性指標包括：

• 延遲（Latency）：系統回應速度。
• 流量（Traffic）：同時處理的使用者或請求數。
• 錯誤率（Errors）：失敗請求或異常比例。
• 飽和度（Saturation）：資源使用情況，例如 CPU、記憶體是否逼近上限。

這些數據透過可觀察性工具收集，例如指標、日誌、追蹤，讓團隊能定位問題。

SRE 與 DevOps 的差異

雖然 SRE 與 DevOps 都致力於縮短交付時間、提升系統品質，但兩者有不同的側重點：

• DevOps 是一種文化與方法論，強調開發與運維之間的合作與自動化。
• SRE 則是 DevOps 的具體實踐之一，用工程化方式將可靠性量化，並以 SLA、SLO、SLI、Error Budget 作為管理依據。

總結來說，DevOps 是「理念」，SRE 是「實踐」。

SRE 不只是技術，更是一種可靠性思維。隨著系統越來越龐大與複雜，它讓團隊在創新速度與系統穩定之間取得平衡，確保用戶能獲得一致、穩定的體驗。