凌晨 3 点把新同学从被窝里叫醒的告警，你补的是 runbook 还是"叫醒前的上下文"？

【背景】 做了 15 年 SRE，从写 crontab 盯日志到现在的 K8s + Prometheus 体系，我处理过最心虚的一类事故复盘，都不是"没告警"，而是"告警响了，人接不住"。

去年一次真实的例子：凌晨 2 点多，核心链路的 P99 超阈值告警把值班的新同学叫醒。他按 runbook 查了服务状态——全绿；查了依赖——正常；最后折腾了 40 分钟才发现是上游一个批任务在 2 点整批量重推历史订单，属于已知行为，每周一都会发生一次。事后复盘，这位同学一点没错：runbook 写的是"服务故障排查流程"，而这次根本不是故障。告警把人叫醒的那 3 分钟里，他需要的是"现在是什么情况"，而不是"故障了怎么办"。

【常见的几种做法，分歧就出在这】

1. 全押 runbook：把每个告警都配一份操作手册，越写越厚，最后没人看，值班同学还是靠猜；
2. 告警文案里塞上下文：在 alert annotation 里直接写"本周知会""当前在跑哪些批任务""最近一次变更"，告警从一行字变成一小段话，但有人觉得这是把告警平台当 IM 用；
3. 分层：告警只负责叫醒，上下文靠值班群里的一条"周知"贴：轻，但贴丢了、过期了、没人维护，等于没有；
4. 自动化兜底：把这类已知周期行为直接做成静默窗口 / 自动抑制，压根不叫人——这是最省事的，但谁来判定"已知"？判错了就是漏报。

【我的倾向】 我倾向于"告警文案必须自带 30 秒上下文"：这条告警是什么级别、影响哪个业务、最近 1 小时有没有变更、当前有没有已知进行中的批处理。理由很朴素——凌晨被叫醒的人认知带宽只剩 10%，runbook 要他先判断"我处在哪一步"，而上下文是直接把判断省掉。成本其实不高：变更系统、批任务调度器的 API 都是现成的，拼进 alert 模板就行。

但我也有犹豫：上下文塞多了，告警群会不会又变成没人读的公告栏？自动抑制的"已知"边界谁来划？

【想听听大家】

• 你们团队告警叫醒人之后，"上下文"这件事实际是怎么落地的？是告警自带、群里贴周知、还是靠老带新口口相传？
• 有没有过"明明有 runbook，值班还是抓瞎"的真实案例，卡在哪一步？
• 对"自动抑制已知行为"，你们敢放多大的口子？漏报的账谁背？