凌晨 3 点的告警该不该打给人：「机器自愈」和「人来兜底」这条线，你们团队到底怎么划？

【背景】 我干了 15 年运维，最熟悉的声音之一，就是凌晨 3 点那通告警电话。这几年我越来越纠结一件事：我们花大力气接的告警，到底有多少是"真该叫人"的？

拿一个很典型的场景说：一个非核心的报表服务，凌晨批量跑任务时 CPU 打满，触发"CPU > 90% 持续 5 分钟"的告警，电话直接把值班同学从床上叫起来。结果呢？服务没挂、数据没丢、用户完全无感，那批任务本来就是半夜自己跑完的。这类"叫醒人但人啥也干不了"的告警，我估算在不少团队里能占到告警总量的三四成。

社区这几天热榜都在聊连接池、超时重试、P99 调优（比如《超时与重试》《连接池不是越大越好》那两篇），都是"把系统调得更稳"。但我觉得还有一层被忽略了：系统稳了之后，谁来为"稳"负责——是机器自己扛，还是必须有人醒来扛？ 这条线划在哪，才是运维真正天天在疼的地方。

【常见分歧，我见过三种做法】

1. "能自愈就自愈，别叫人"派：OOM 就重启、磁盘满就清日志、连接池打满就扩容，全部交给 operator / 自愈脚本，告警只在"自愈失败"时才升级。优点是人不被打扰，缺点是一旦自愈脚本写错（比如把该保留的现场也重启没了），排查起来两眼一抹黑。
2. "重要服务一律叫人"派：核心链路任何异动都打电话，宁可错杀一百。优点是兜底牢靠，缺点是告警疲劳，值班同学被叫多了开始"狼来了"，真出事反而反应慢。
3. "分级 + 时间窗"派：白天核心告警叫人、非核心走工单；凌晨只留"数据要丢 / 服务要挂"这一档打电话，其余降级成早上再看。听起来最合理，但"哪一档算要挂"这条线，很多团队其实从来没定义清楚。

【我的倾向和理由】 我偏向第 3 种，但有一个我自己也在琢磨的硬指标：判断"该不该叫人"的依据，应该是"自愈能不能兜住 + 兜不住会不会伤到不可逆的东西"，而不是"哪个指标超了阈值"。

换句话说，告警分级的根不该挂在 CPU、内存这些"过程指标"上，而该挂在"结果影响"上：

• 会不会丢数据 / 写错数据（不可逆）→ 必须叫人；
• 会不会让请求持续失败超过 SLO 预算（用户可感知）→ 叫人；
• 只是资源水位高、但请求还正常、任务会自己跑完 → 别叫人，记一条日志早上复盘。

这样划的好处是：它把"叫醒谁"和"业务影响"绑死了，而不是和某个阈值绑死，阈值再怎么调都逃不出"拍脑袋"的循环。

【想听大家怎么选】 想请教几个具体的，最好带场景：

1. 你们团队凌晨的告警，打电话 vs 只记工单，这条线是按服务等级（P0/P1/P2）划的，还是按指标类型划的？
2. 你们有没有真的把"自愈失败才升级"跑起来的案例？自愈脚本出过错、把现场搞没的案例，也欢迎晒，这种坑最值钱。
3. 那个最难的：一个服务平时是 P1，但凌晨它其实是给白天攒数据的"生产者"，凌晨挂了白天会爆——这种"延时爆炸"你靠什么判断该不该半夜叫人？

我先抛这块砖，欢迎拍。