半夜的告警该叫醒谁？值班疲劳的三层缓解

很多团队的告警系统不是没有告警，而是告警太多。值班同学第一天还精神紧绷，第三周就开始训练自己"扫一眼就知道要不要起来"。这不是纪律问题，是人性的必然。今天要聊的，是怎么从机制上缓解值班疲劳，让真正重要的告警依然能穿透睡眠。

第一层：把"响"和"叫"分开

多数告警疲劳来自一个混淆：通知（notify）和呼叫（page）是两回事。通知可以堆积、可以延迟、可以在早上批量消化；呼叫必须付出代价——把人从床上拽起来。工程上应该给每条告警显式声明它的升级路径：notify → page → escalate。一个常用的判定标准是"这个告警如果两小时不处理，用户会不会受损"。不会，就只配通知；会，才允许呼叫。很多团队最大的收益，往往来自把 60% 的 page 降级为 notify，动作简单，效果立竿见影。

第二层：给呼叫加上"值得"的刻度

值班疲劳的另一个来源是"反正叫了也不是我的错，但也得起来看一眼"。解决办法是给呼叫附带上下文和归属：告警消息里直接带上最近的部署记录、受影响的接口、以及值班 Runbook 的链接。更进一步，可以给每个服务算一个"呼叫性价比"：过去 30 天这个服务触发了多少次 page，其中多少次真的需要人工介入？比例低于某个阈值的，默认降级并把"找回可靠性"变成该服务 owner 的待办，而不是值班人的半夜惊跳。这个指标公开透明之后，各团队自然会收敛自己乱配的告警规则——没人愿意自己的服务挂着"狼来了"的标签。

第三层：让休息本身成为系统的一部分

值班排班的科学性常被忽视。连续值班超过一周、轮换间隔不足 24 小时、或者新人还没有副值班就独立上岗，都会显著放大误判率。可行的做法包括：主副值班配对，副值班消化夜间灰色告警；每次值班后强制留一段"无呼叫缓冲"，用来偿还告警债而不是马上切回开发；每周复盘一次"最差叫醒奖"，把上周最不值得的那次呼叫的根因修掉。修掉一次坏告警，比买一套新告警平台更值钱。

写在最后

值班系统的目标不是"永远有人醒着"，而是"只有该醒的时候才有人醒"。三层缓解的共同点是：把人的注意力当成稀缺资源来调度，而不是当成默认无限的耗材。半夜该叫醒谁，本质上是一条需要持续校准的工程参数——参数调好了，值班人才会在真正需要他的那个凌晨，保持敏锐。