什麼是 SRE#

SRE（Site Reliability Engineering，網站可靠性工程）是一套將軟體工程原則套用到 IT 基礎設施與運維上的實踐方法，目標是打造高度可靠且可擴充（scalable）的軟體系統。雖然各家組織因應自身專案性質與規模而對 SRE 有不同詮釋，但所有定義最終都指向同一個目的：高擴充性與高可靠性。

起源與發展#

• 2003 年由 Google 首創，最初只用來解決自家大規模服務的營運挑戰
• 早期外界因尚未碰上同樣的規模問題、加上原則尚未明確，採用率有限
• 隨著雲端與大型 SaaS 應用興起，運維壓力上升，SRE 角色被 Google 正式制度化
• 今日幾乎每家 IT 組織都設有 SRE 部門，負責確保大型系統的可靠性與擴充性

SRE 與 DevOps 的關係#

• SRE 是開發（Development）與運維（Operations）之間的橋樑
• DevOps 與 SRE 共享部分原則，但屬於兩套不同的實踐
• 在某些組織中 SRE 與 DevOps 為獨立團隊，在另一些組織則由同一群人兼任
• 兩者的詳細差異會在第 2 章深入比較

SRE 的工作內涵#

SRE 是一套確保軟體 24/7 可靠、可用、有韌性的實踐方法。它強調用工程手段在問題進入正式（production）環境前先行發現並修復；若問題仍流入 production，也要能快速定位並排除。

Google 提出的經典時間配比是 SRE 工程師將 50% 時間投入運維、50% 時間投入工程任務，目標永遠是讓系統「持續上線、持續運行」。

SRE 與傳統運維的分工模式#

• 部分組織同時保留 SRE 與生產支援（production support）團隊，後者擔任 L1/L2、SRE 擔任 L3
• 另一些組織則整合為單一 SRE 團隊，包辦支援、排查與解決方案開發
• 無論架構如何，SRE 都不會只是「值班人員」，而是兼具程式開發與系統運維能力的工程角色

SRE 的核心原則#

以下是 SRE 普遍奉行的基本原則：

• 可觀測性（Observability）：監控是 SRE 最關鍵的功能之一；若不能觀測系統，就無法找出待補的缺口
• 自動化（Automation）：消除手動與重複性工作，讓工程師把精力放在新功能、新工具與系統強化上
• 服務等級指標（Service Level Objective, SLO 與 Service Level Agreement, SLA）：為系統表現設立合理期待，讓終端使用者與利害關係人對系統行為有共同認知
• 可量測（Measure）：每一項服務都必須定義量測指標——「無法量測就無法解決失敗」
• 風險管理（Risk management）：沒有任何系統能 100% 可用；要做的是辨識潛在故障並降低衝擊
• 事件管理（Incident management）：制訂清楚的標準與流程，確保事故能即時回應與修復
• 變更管理（Change management）：明文規範開發與測試人員如何在開發與正式環境發布變更

以上原則沒有先後輕重，但缺一不可。組織導入 SRE 時可由最迫切的痛點切入，再逐步補齊其他面向。