從目的看分工#
雖然 SRE 與 DevOps 共享許多原則，但它們最初被發明的目的不同：
- DevOps：管理開發流程、推動開發者與運維協作的方法論。以 CI/CD 管線自動化建置、部署與基礎設施配置，避免手動誤差、節省開發者時間
- SRE：設計並實作高度可擴充、可靠系統的方法論。SRE 工程師寫工具做自動化、自我修復、告警與系統強化，可視為傳統「L1 運維」的進階版
Google 對 SRE 的經典規範：每位 SRE 工程師應只把 50% 時間花在運維，剩下 50% 用來撰寫工具與解法。這份「跨腳」的時間配比，正是 SRE 與單純 DevOps 最大的本質差異。
案例：UPI 支付功能上線#
考慮一個有 SRE 與 DevOps 完整建制的電商專案，要新增 UPI 支付：
- 分析師收集需求 → 架構師、設計師、SRE 共同設計資料流
- 設計分享給包含 DevOps 在內的所有團隊
- DevOps 新增管線整合並部署、同時擴充基礎設施
- 開發者透過 CI/CD 持續開發部署，QA 持續測試
- AC（Agile Champion）發現缺陷時與 SRE 評估其在 production 載量下的潛在影響
- SRE 同步新增儀表板，上線後監控、依事件管理流程接收客服技術問題
- SRE 50% 時間在 production 監控與報告、50% 時間轉為與開發者一起寫解法
真實組織的混合模式#
有些組織還在轉型期，會調整 SRE 的時間配比。例如某大型金融科技組織：
- 設立獨立的 SRE 與 DevOps 團隊
- SRE 工作配比為 70% 運維、30% 工程
- SRE 工程師先做兩個月運維（支援應用、監控 production、處理誤報、新增儀表板、找出可自動化處的、記錄缺陷、提出系統設計改進）
- 接著轉為兩個月開發（自動化先前找到的手動任務、寫工具支援 SRE 與開發、修補部分缺陷、與開發共同重新設計系統）
- DevOps 則建構 CI/CD、與開發及 SRE 協作做變更與發布管理，扮演開發與 SRE 之間的橋樑
Google 規範是 50/50；其他組織常依成熟度與業務性質調整。重點是「同一位工程師同時握有 production 經驗與寫程式能力」這個核心精神不能丟。
對照表：DevOps 與 SRE 主要差異#
| 面向 | DevOps | SRE |
|---|---|---|
| 定義 | 管理軟體開發流程、串起開發與運維協作的方法 | 設計高度可靠、可擴充、有韌性系統的方法 |
| 重點 | 偏向開發端，定義如何加速開發、提升品質 | 偏向運維端，以自動化、標準與流程提升運維 |
| 方法 | 跨職能；以自動化工具打開協作通道 | 以儀表板與自動化建立可觀測性，賦能開發產出高品質程式 |
| 目標 | 改善開發團隊間溝通、打破穀倉 | 確保系統可擴充、可靠，以多種自動化與實踐降低客戶衝擊 |
| 常用工具 | Jenkins、Ansible、Chef、Terraform、Kubernetes、Git、Jira、Slack、Microsoft Teams、雲端 | ELK、Prometheus、Splunk、AppDynamics、Grafana、ServiceNow、Jira、PagerDuty、Shell、Python、Java、Jenkins、雲端 |
Figure 2.4: SRE and DevOps
何時需要哪一個#
- 小型組織預算有限：可由 DevOps 同時兼任 SRE 部分職能
- 大型應用：SRE 與 DevOps 分設，職責更清楚、人員也不會過勞
- 即使不採用兩者，只要組織能達成可靠性與交付速度，也是可行的選擇
兩種方法論不是互斥選項，而是依組織規模與成熟度的譜系。決策時應先問「我們最痛的是速度還是可靠性」，再決定先導入哪一邊。