為何 SRE 與運維分工要清楚#
兩者常被互換使用，造成認知混亂：
- 有些組織獨立兩支團隊
- 有些組織把運維責任直接丟給 SRE
- 客服、L1、L2、L3 多由運維承擔，但 SRE 有時也得做 L2/L3
沒有清楚的角色定義，SRE 必然過勞。24/7 應用更是放大這個風險。
案例：旅遊軟體的更新#
某旅遊公司想把舊軟體現代化，已累積大量全球客戶。
規劃階段#
- 業務與技術整理需求、預算、時程
- 工程 SME 設計架構與資料流
- 工具與技術棧拍板，採用公有雲
- 部分服務沿用，部分重寫
- 各團隊組建：開發、QA、分析、SRE、DevOps；其中部分是舊團隊延續
實作階段#
- DevOps 建 CI/CD 管線
- 開發團隊接手後展開實作
- SRE 配置儀表板、告警與量測指標，並建立事件與缺陷流程
測試與發布階段#
- QA 進行回歸、遞增測試
- SRE 補上混沌與效能測試
- 缺陷回開發者修補
- 通過後打包部署 production
維運階段#
- 上線 3 個月後，SRE 與運維陷入持續救火，SRE 開始燃燒
問題分析#
SRE 容量足夠，但團隊仍然過勞——根因是 SRE 沿用舊運維流程，沒有清楚的職責定義。
- SRE 名稱換了，責任沒重新切：從 L1 到 L3 全做
- 大量自動化任務積在 backlog 沒人推
解法：分工與分流#
- 補充具備 SRE 技能的工程師
- 把團隊內部拆成「運維」與「SRE」兩個職能
- 運維（沿用原 ops 同仁）：
- 處理 L1/L2 工單
- 監控系統、依 runbook 解決低階問題
- 改善告警與儀表板
- 開發小型自動化降低 toil
- 需要技術深度時轉給 SRE
- SRE：
- L3 支援與運維備援
- 寫工具與能力
- 修補非功能缺陷
- 參與系統設計審查
- 從根本解決問題（自我修復、預防式設計建議）
一旦角色清楚，協作模式自然調整：SRE 不再被低階問題拉走，能投入結構性改善；運維因 runbook 與工具被增能，自信解決更多問題。
教訓#
- 「SRE 包山包海」短期省事，長期讓人才耗盡
- 運維是系統的第一線，他們的工作品質直接影響使用者印象
- 自動化是把 SRE 與運維分工放大效能的關鍵
角色定義應該寫進工作職責文件，並讓兩個團隊的 KPI 互相對齊。沒有對齊的 KPI 會讓分工流於形式。
