On-Call 是維持可靠度的必要工作，但組織不當會反過來燒掉團隊。SRE 的解法是用工程手段解決運維問題，並同時管住 On-Call 的「數量」與「品質」——別讓值班變成無止境的救火。
🧠 Intuition
TIP
反應時間是被可用度目標反推出來的：99.99% 季度可用 → 一季只能宕約 13 分鐘 → 工程師必須分鐘級到位。時效需求越高，值班紀律就得越嚴。
- SRE ≠ 純運維：關鍵差別是用工程解決運維問題。Google 對 SRE 設「至少 50% 時間做工程」的硬約束，把運維壓在一半以下。
- 兩條約束：數量（工程師花多少時間 On-Call）與品質（每輪處理幾件事件）。從「工程時間 ≥ 50%」推出「On-Call ≤ 25%」。
- 主／副輪值：多數團隊有主、副兩線；副值可當主值漏接的 fallback，或主接 page、副處理工單與審查。
- 升級路徑要清楚：開發團隊也參與 24/7，必要時可往上升級——這是讓值班「不再可怕」的三根支柱之一（另兩根：正式事件管理流程、無究責事後檢討）。
⚖️ Tradeoffs
數量平衡 — 用「25% 規則」反推最小團隊規模
- 至少 50% 工程時間 → 至多 25% On-Call → 剩 25% 處理其他運維。
- 假設隨時有主／副 2 人、以週為單位輪：單地點最少 8 人（每人每月值 1 週）；雙地點各最少 6 人（兼顧規則與最小臨界量）。
- 團隊夠大時優先做多地點 follow the sun：避開有害健康的夜班、限制單地點值班密度;代價是跨地點協調成本。
- 反面陷阱是負載不足——太久不碰生產會讓自信與知識斷層只在事故時才暴露。對策：每人每季至少值 1–2 次，配合 Wheel of Misfortune 與年度 DiRT 災難演練。
品質平衡 — page 頻率的分佈要「平」，中位數最好是 0
- 一次事件（根因 + 修復 + 事後檢討）平均耗 6 小時 → 一輪 12 小時值班最多吃得下 2 件。
- 所以 page 頻率分佈要平：某元件天天 page，遲早會疊上別的事件而爆掉。超標時就本季暫停部分工作、調外援、或改善告警。
- 運維過載多半源於監控誤配：每個 page 都要對應 SLO 威脅且可採取行動、一個事件只該觸發一個 page（其餘由監控聚合）。
- 最後的平衡閥是把 pager「還給」開發團隊，讓他們自己值到系統達標——很少動用，但這個選項的存在維持了「可靠性 vs. 速度」的健康張力。
🔑 Takeaways
- On-Call 的反應時效由可用度目標反推；SRE 靠「工程 ≥ 50%」把運維壓在半數以下。
- 同時管數量（用 25% 規則反推團隊最小規模、優先 follow the sun）與品質（page 分佈要平、一事一 page）。
- 值班要有清晰升級路徑 + 正式事件流程 + 無究責文化當心理安全網；太吵要調告警、太靜要靠演練補手感。
No notes yet — jot your takeaways or Q&A here.