on-call 到底是在"背锅"还是在"学习"？聊聊值班文化与告警治理的边界

背景

干了 10 年 SRE，从 3 人小团队到 200 人的 on-call 体系都轮过。有一个现象每次换团队都逃不掉：on-call 的人越来越不爱接电话了——不是懒，是真的累。我算过一笔账：一个中等规模微服务团队（8–12 个服务），如果告警规则没治理过，一个值班的周里，半夜被叫醒 2–4 次是常态；其中 70% 以上是噪音（GC 抖动、心跳丢一次、磁盘水位在 85% 上下晃、第三方监控误报）。

更烦的是，on-call 的"隐性成本"没人算：

• 你白天写代码，脑子一直挂着"会不会又响"，上下文切换成本巨大；
• 半夜被叫醒后第二天状态差，代码质量下降——这其实是延迟发生的风险；
• 新人把 on-call 当"惩罚"，不愿意接，老人接不动，恶性循环。

常见分歧（我见过三种典型做法）

1. "全员轮值、平均主义"：所有人排班，谁都不能例外。好处是公平、知识不垄断；坏处是高级工程师的 on-call 时间被"稀释"，真正难的问题最后还是那 1–2 个人兜底。
2. "分级值班 + 升级链"：L1 值班先接，搞不定 15 分钟升级 L2/L3。听起来完美，但实际落地时 L1 经常"不敢升级"——怕被说能力不行，硬扛到超时才升级，反而拖长了 MTTR。
3. "告警先治理、再排班"：先把告警降噪到"响了就一定该有人处理"，再谈轮值。这个方向我认同，但落地时团队往往觉得"降噪是额外工作"，没人愿意做。

我的倾向与理由

我倾向第 3 种，但有一个前置条件：on-call 的产出要被显性记录。具体来说——

• 每次 on-call 处理完，哪怕只是"看了下日志，确认是误报"，也要花 2 分钟在工单里写一句"本次响应：xx 告警，误报，原因是 yy"。这些记录年底汇总起来，就是你降噪的素材；
• 每月做一次"告警审计"：把过去 30 天所有告警按"是否真实故障 / 响应时间 / 处理结果"分桶，把"响了但没人需要处理"的告警直接降级或关掉；
• on-call 的时间计入"技术贡献"，在绩效/晋升时不应该是"负分项"。这是文化问题，不是技术问题。

想听大家在什么场景下怎么选？

1. 你们团队的 on-call 是全员轮值还是分级？升级链实际有效吗？
2. 半夜被叫醒的频率大概是多少？有没有做过"告警降噪"专项？效果如何？
3. on-call 的记录（响应日志、误报分析）在你们团队有没有被当作"产出"来对待？
4. 有没有因为 on-call 文化出问题（比如核心工程师 burnout 后离职，知识断档）的真实案例？

不追求标准答案，想看看不同规模、不同阶段的团队在这个问题上的取舍。