背景
干了 10 年 SRE，从 3 人小团队到 200 人的 on-call 体系都轮过。有一个现象每次换团队都逃不掉：on-call 的人越来越不爱接电话了——不是懒，是真的累。我算过一笔账：一个中等规模微服务团队（8–12 个服务），如果告警规则没治理过，一个值班的周里，半夜被叫醒 2–4 次是常态；其中 70% 以上是噪音（GC 抖动、心跳丢一次、磁盘水位在 85% 上下晃、第三方监控误报）。
更烦的是，on-call 的"隐性成本"没人算：
- 你白天写代码，脑子一直挂着"会不会又响"，上下文切换成本巨大；
- 半夜被叫醒后第二天状态差，代码质量下降——这其实是延迟发生的风险；
- 新人把 on-call 当"惩罚"，不愿意接，老人接不动，恶性循环。
常见分歧（我见过三种典型做法）
- "全员轮值、平均主义"：所有人排班，谁都不能例外。好处是公平、知识不垄断；坏处是高级工程师的 on-call 时间被"稀释"，真正难的问题最后还是那 1–2 个人兜底。
- "分级值班 + 升级链"：L1 值班先接，搞不定 15 分钟升级 L2/L3。听起来完美，但实际落地时 L1 经常"不敢升级"——怕被说能力不行，硬扛到超时才升级，反而拖长了 MTTR。
- "告警先治理、再排班"：先把告警降噪到"响了就一定该有人处理"，再谈轮值。这个方向我认同，但落地时团队往往觉得"降噪是额外工作"，没人愿意做。
我的倾向与理由
我倾向第 3 种，但有一个前置条件：on-call 的产出要被显性记录。具体来说——
- 每次 on-call 处理完，哪怕只是"看了下日志，确认是误报"，也要花 2 分钟在工单里写一句"本次响应：xx 告警，误报，原因是 yy"。这些记录年底汇总起来，就是你降噪的素材；
- 每月做一次"告警审计"：把过去 30 天所有告警按"是否真实故障 / 响应时间 / 处理结果"分桶，把"响了但没人需要处理"的告警直接降级或关掉；
- on-call 的时间计入"技术贡献"，在绩效/晋升时不应该是"负分项"。这是文化问题，不是技术问题。
一个我后来才补上的坑：「告警审计」本身会制造新的盲区
2024 年 Q3 我们做了一次完整的 30 天告警审计，结果很有说服力：
- 480 条告警规则中，"响了但 0 人处理"的占 31%（149 条）——这些不是误报，是"没人认领"；
- "响了且处理了，但事后证明是误报"的占 22%（106 条）——这些是真正的噪音；
- "响了且是真实故障"的只占 9%（43 条）——这才是 on-call 真正该响的那部分。
审计之后我们砍掉了 149 条"无人认领"的规则（不是降级，是直接删），降噪效果立竿见影。但三个月后复盘时发现一个新问题：砍掉的 149 条里有 3 条在 Q4 真的响了（一次磁盘水位 92% 持续 40 分钟、一次 GC 停顿 1.2s 导致 P99 飙 8 倍），因为那 3 条"以前没人认领"不代表"不需要人看"，只是"以前恰好没出事"。
教训：告警审计的"砍"不能一刀切。正确的做法是分两批处理——
- 第一批：30 天内响了 ≥3 次且 0 人处理的，直接删（这是真正的"狼来了"）；
- 第二批：30 天内响了 1–2 次且 0 人处理的，不删，改为"静默 14 天"（不通知人、只记日志），14 天后如果还是 0 人处理再删。
- 硬规则：任何一条"响了但没人处理"的告警，删除前必须有一个明确的理由写进审计记录（"为什么这条不需要人看"），不能只写"噪音"两个字。
这条教训我后来贴在了团队的 on-call runbook 首页，比任何"告警降噪指南"都管用——因为它告诉值班同学：你有权关掉一条告警，但你必须写下"为什么这条不需要人看"，而且 14 天后有人来检查你的理由是否成立。
想听大家在什么场景下怎么选？
- 你们团队的 on-call 是全员轮值还是分级？升级链实际有效吗？
- 半夜被叫醒的频率大概是多少？有没有做过"告警降噪"专项？效果如何？
- on-call 的记录（响应日志、误报分析）在你们团队有没有被当作"产出"来对待？
- 有没有因为 on-call 文化出问题（比如核心工程师 burnout 后离职，知识断档）的真实案例？
不追求标准答案，想看看不同规模、不同阶段的团队在这个问题上的取舍。
0赞
0收藏
0楼层