半夜的告警該叫醒誰？值班疲勞的三層緩解

很多團隊的告警系統不是沒有告警，而是告警太多。值班同學第一天還精神繃緊，第三週就開始訓練自己「掃一眼就知道要不要起來」。這不是紀律問題，是人性的必然。今天要聊的，是怎麼從機制上緩解值班疲勞，讓真正重要的告警依然能穿透睡眠。

第一層：把「響」和「叫」分開

多數告警疲勞來自一個混淆：通知（notify）和呼叫（page）是兩回事。通知可以堆積、可以延遲、可以在早上批量消化；呼叫必須付出代價——把人從床上拽起來。工程上應該給每條告警顯式宣告它的升級路徑：notify → page → escalate。一個常用的判定標準是「這個告警如果兩小時不處理，使用者會不會受損」。不會，就只配通知；會，才允許呼叫。很多團隊最大的收益，往往來自把 60% 的 page 降級為 notify，動作簡單，效果立竿見影。

第二層：給呼叫加上「值得」的刻度

值班疲勞的另一個來源是「反正叫了也不是我的錯，但也得起來看一眼」。解法是給呼叫附帶上下文與歸屬：告警訊息裡直接帶上最近的部署紀錄、受影響的介面、以及值班 Runbook 的連結。更進一步，可以給每個服務算一個「呼叫性價比」：過去 30 天這個服務觸發了多少次 page，其中多少次真的需要人工介入？比例低於某個閾值的，預設降級並把「找回可靠性」變成該服務 owner 的待辦，而不是值班人的半夜驚跳。這個指標公開透明之後，各團隊自然會收斂自己亂配的告警規則——沒人願意自己的服務掛著「狼來了」的標籤。

第三層：讓休息本身成為系統的一部分

值班排班的科學性常被忽視。連續值班超過一週、輪換間隔不足 24 小時、或者新人還沒有副值班就獨立上岗，都會顯著放大誤判率。可行的做法包括：主副值班配對，副值班消化夜間灰色告警；每次值班後強制留一段「無呼叫緩衝」，用來償還告警債而不是馬上切回開發；每週複盤一次「最差叫醒獎」，把上週最不值得的那次呼叫的根因修掉。修掉一次壞告警，比買一套新告警平台更值錢。

寫在最後

值班系統的目標不是「永遠有人醒著」，而是「只有該醒的時候才有人醒」。三層緩解的共同點是：把人的注意力當成稀缺資源來調度，而不是當成預設無限的耗材。半夜該叫醒誰，本質上是一條需要持續校準的工程參數——參數調好了，值班人才會在真正需要他的那個凌晨，保持敏銳。