Alert 設計的 Checkpoint
Alert 的根本問題：大多數系統的 alert 是「這個 metric 超過閾值了」，而不是「用戶正在遭遇問題」。結果是大量的 alert，大多數都是誤報或低優先級，on-call 工程師習慣了就開始 ignore。
好的 Alert：
- Alert = 用戶影響，不是 metric 閾值。「訂單 API 錯誤率 > 1% 持續 5 分鐘」好過「CPU > 80%」
- 每個 alert 有 severity：P1（用戶看到錯誤）、P2（性能降級但功能可用）、P3（內部問題但無用戶影響）
- P1 才叫醒人：P2/P3 白天處理就好，不要凌晨三點叫人起床看 CPU spike
- Alert 有 runbook 連結：點進 alert 就能看到「這代表什麼、要做什麼」
- 定期 review false positive 率：>5% 的 alert 是雜訊就要調整閾值
Runbook 成熟度的 Checkpoint
Runbook 是 alert 的配套文件：「這個 alert 觸發了，要怎麼處理」。
Level 1（存在）：
- 每個 P1/P2 alert 有對應的 runbook
- Runbook 說明這個 alert 代表什麼
Level 2（可操作）：
- 包含「如何確認問題範圍」的步驟
- 包含「常見的修復方式」
- 包含「escalation 條件：什麼情況要找誰」
- 最近 6 個月有被更新過
Level 3（自動化）：
- 部分診斷步驟已自動化（runbook 裡的 query 可以直接跑）
- 已知問題有自動修復腳本（restart pod、清空 queue 等）
不健康的訊號：on-call 工程師說「這個 alert 我從來不知道要怎麼處理」；runbook 最後更新是兩年前。
Escalation Path 的 Checkpoint
- 每個服務有明確的 escalation path：on-call 工程師 → service owner → engineering manager → CTO
- Escalation 有時間條件：「處理 30 分鐘無進展就升級」
- 每個人的聯絡方式在 on-call 文件裡（不是靠記憶找人）
- 有 war room 機制（重大 incident 時怎麼集合相關人員）
Rotation 設計的 Checkpoint
好的 Rotation：
- 輪值表至少排 2-3 個月，每人提前知道自己什麼時候值班
- 每次值班最長 1 週（超過就累積倦怠）
- 新人有 shadowing 期：先跟著有經驗的人值班，不是第一天就獨立值班
- 值班負荷要追蹤：每週 incident 數、半夜被叫醒次數——持續高負荷要修系統，不是要工程師扛
- 有補償機制（半夜 page 的換休、值班費）
Incident 後的 Postmortem Checkpoint
好的 on-call 系統不只是「能處理問題」，也要「從問題裡學習」。
- P1 incident 24-48 小時內寫 postmortem
- Postmortem 有 blameless 文化：focus 在系統問題，不是個人失誤
- 有 action item 和 owner，不是只有「要注意」
- Postmortem 存放在可搜尋的地方，方便下次遇到類似問題查閱
- Follow-up：4 週後確認 action item 有沒有被完成
好的 on-call 系統的核心思想是：on-call 工程師不應該靠個人英雄主義撐住系統，而是靠成熟的系統、清楚的文件、和合理的流程。高頻的 page 和低品質的 runbook 是系統成熟度不夠的症狀，不是 on-call 工程師的問題。