On-Call 輪值

On-Call 是維持服務可靠性的必要工作，但組織不當會反過來摧毀團隊。本章說明 Google SRE 多年累積的 On-Call 原則：用工程方法解決運維問題、控制數量也控制品質、保留心理安全感。

On-Call 工程師的日常#

SRE 與純運維團隊的關鍵差別在於：用工程手段解決運維問題。Google 對 SRE 設下「最少 50% 時間做工程」的硬約束。

當值工程師職責：

反應時間直接受可用度目標約束：
99.99% 季度可用度 → 季度可宕約 13 分鐘 → 工程師必須分鐘級到位。

SRE 對 On-Call 有兩條約束：數量（工程師多少時間花在 On-Call）與品質（每輪事件數）。

至少 50% 工程時間 → 至多 25% On-Call → 剩下 25% 處理其他運維
用「25% 規則」推導最少團隊規模：
- 假設始終有主／副 2 人 On-Call、每週為單位
- 單地點團隊最少 8 人：每人每月當值 1 週
- 雙地點團隊各最少 6 人：兼顧 25% 規則與最小臨界量

服務工作量足以擴張團隊時，優先做多地點「follow the sun」：
避免夜班（夜班有害健康）
限制單地點輪值人數，避免每人對生產系統失聯
代價是跨地點的溝通與協調成本。

一次事件（root cause、修復、事後檢討）平均耗 6 小時 → 一輪 12 小時的 On-Call 最多 2 件事件。
為了不超過此上限，page 頻率的分佈應該很平——中位數最好是 0。某元件天天 page 表示遲早會疊加其他事件而爆掉。

超過上限時的對策：本季暫停部分工作、調來外援、改善告警。

合理的補償很重要。Google 提供補休或加薪，但設有上限：

SRE 揹的是公司最關鍵的營收與基建系統，壓力極大。研究顯示人類面對挑戰時有兩種思維：

壓力荷爾蒙會把人推向第一種模式——快速、習慣性、不思考——容易陷入確認偏誤。
例：同一告警本週發生第 4 次，前 3 次都是上游系統，直覺會自動把第 4 次歸給同一原因——但這次可能是不同的問題。

事件管理工具自動化角色交接、狀態紀錄等繁瑣動作，讓事件指揮官能專注在處理事件本身，而非格式化郵件或更新數個通訊管道。

當運維工作超過 50%，SRE 與主管應在季度規劃中設定可量化目標把它拉回（如「每日工單 < 5」「每輪 page < 2」）。

常見原因：監控誤配。

「歸還 pager」很少發生，但這個選項的存在維持了 SRE 與開發團隊的權力平衡——也是「可靠性 vs. 速度」這個健康張力的具體體現。

太安靜也不好。長期不接觸生產 → 自信心問題（過度自信或不足）、知識斷層只在事件發生時才被發現。

對策：

Google 的 On-Call 模式讓我們能用「工程」作為規模化生產責任的手段，在系統數量與複雜度增加的同時保持高可用度。即便不能照搬到所有情境，這套模式仍是組織可參考的穩固模板。