62% 的待命工程師在 12 個月內出現倦怠（PagerDuty 2026）。 這不是人為問題，而是工程設計問題。 每個倦怠輪值都具備三個根本原因： 1. 針對症狀而非原因發出警報 CPU 飆升、佇列深度、請求速率——這些都不是事件，但它們都會在凌晨 3 點叫醒人員。 2. 過時的應急手冊 接到警報。手冊指向的服務已更名。工程師在腎上腺素激增且無睡眠的情況下，逆向推導系統。 3. 對不對稱負載使用對稱輪值 週末是超級盃，平日是短跑。相同的輪值卻對待兩者完全一樣。 頂尖團隊實施的四項改進： 1. 錯誤預算 將非計劃內的待命工作限制在每周的 25% 以內。超過此限，功能開發即停止。Google SRE 已制定標準流程。 2. 警報與 SLO 關聯 若未對應到使用者可觀察的 SLO 違規，則屬於噪音。23% 的待命時間來自誤報（Blameless 2026）。 3. 手冊或刪除 每個生產環境警報必須附帶最新手冊，否則就刪除該警報。你會失去一半的警報——這正是目的。 4. 負載感知輪值 高峰時段需加強覆蓋或縮短班次。一刀切的模式只會懲罰抽到高峰的人。 如果你是工程負責人，待命設計就是你的職責，不是 HR，也不是你的經理——就是你。 這週：打開儀表板，統計警報次數，問問有多少本應由平台處理，而非人工介入。 #EngineeringLeadership #OnCall #SRE