【背景】
干运维 10 年，oncall 手机响了不下几千次。我粗略统计过自己前 5 年的告警工单：大约 80% 的"翻车"集中在两头——要么"该告没告"（P99 已经飙了 3 倍，但没触达阈值，等用户投诉才查），要么"不该告也告了"（凌晨 QPS 从 200 自然回落到 50，同比下跌 75%，触发了"流量骤降"告警，结果只是业务低谷）。阈值到底怎么定，我所在团队从来没有形成过统一答案，每次大促前 review 告警规则都要吵一轮。
社区热榜刚有连接池 P99 抖动的排查文章（id=18），讲得非常扎实，但那是"告警响了之后怎么查"。我更想聊上游问题：这条告警到底该不该配、阈值定多少、什么该告什么不该告。
【三种常见做法，各有硬伤】
做法 A：固定阈值
最经典的写法：P99 > 200ms 持续 5min → P1 告警。
- 优点：简单、可解释、新人第一天也能看懂。
- 硬伤：同一个接口，白天 QPS 800 时 P99 正常 120ms，凌晨 QPS 20 时 P99 自然 300ms（连接池冷、缓存命中率低）。你的 200ms 阈值，要么白天太松（真抖动到 250ms 才告），要么凌晨太紧（正常波动就响）。我见过一个团队把阈值从 200 调到 500 来减少误报，结果真故障时 P99 飙到 480ms，没告，靠用户工单兜的。
做法 B：动态基线（同比/环比偏离 N 倍 / Nσ） 很多 APM 平台的默认方案：和昨天同时段比，偏离 > 3σ 告警。
- 优点：自适应，不用手动逐接口调阈值。
- 硬伤：①"3σ"还是拍脑袋的，前提假设正态分布，但 P99 本身是长尾指标，分布大概率偏斜；②节假日、大促、发版日，基线本身就不对，环比 5 倍可能是正常业务增长；③新上线的接口没有 7 天历史基线，前一周等于裸奔。
做法 C：SLO 预算（错误预算消耗速率） Google SRE 那套：定义 SLO（比如 99.9% 请求 < 500ms），错误预算 = 0.1%，按时间窗口算消耗速率，消耗速率 > 14.4×（即 1 小时内烧完 1 天的预算）就告警。
- 优点：面向用户影响，天然过滤掉"内部指标抖动但用户无感"的噪音。
- 硬伤：①前提是 SLO 定义得好，但很多团队的 SLO 是"拍个 99.9 就完了"，没分核心/非核心链路、没区分读和写；②SLO 是结果指标，等你烧完预算，用户已经骂了 10 分钟了；③需要把内部指标（CPU、IO、连接池）和 SLO 关联起来，不然 SLO 告警只能告诉你"坏了"，不能告诉你"哪里坏了"。
【我的倾向：分层告警，别指望一种方案通吃】
我现在的做法（跑了 3 年没大翻车，但不一定是最佳）：
- P0 层（用户可感知）：用 SLO 预算。核心链路（下单、支付、查询）的 P99 和错误率，按 30 天 SLO 算预算消耗速率。消耗速率 > 14.4× 触发 P0 电话告警，oncall 5 分钟内响应。
- P1 层（容量/资源异常）：用动态基线。CPU > 80% 持续 10min、连接池使用率 > 90%、磁盘 IO util > 95%——这些用同比基线（和上周同时段比），偏离 > 2σ 触发 P1 短信告警。
- P2 层（硬边界兜底）：用固定阈值。磁盘使用率 > 90%、日志目录 > 500G、TLS 证书有效期 < 14 天——这些就是硬线，不跟你玩统计，超了就是超了。
关键原则：告警必须能回答"所以我现在该做什么"。如果一个告警响了，oncall 打开工单发现"不知道干嘛"，那这条告警要么阈值太松（该提前告没告），要么缺上下文（该带的指标快照、最近变更、关联服务状态没带）。
【想听大家聊聊】
- 你们线上告警阈值到底怎么定的？是 A/B/C 哪种，还是混着来？混的比例大概怎么分？
- 动态基线的"N 倍"/"Nσ"你们怎么选的？有没有踩过基线本身的坑（比如节假日误报、新接口裸奔）？最后怎么收的？
- SLO 预算你们真的在用吗？还是停留在架构评审 PPT 上？如果真在用，SLO 是开发定的还是 SRE 定的？
- 告警收敛策略：同一个根因（比如磁盘满）触发了 5 条告警（IO 飙高、服务超时、队列积压、健康检查失败、日志暴涨），你们怎么合并的？按服务？按指标？按时间窗口？
- 有没有"告警响了但 oncall 不知道该干嘛"的亲身经历？最后怎么解决的？是改阈值、加上下文、还是直接删掉这条告警？
欢迎带上你的具体数字：什么接口、什么阈值、什么告警频率、误报率大概多少、MTTA 多少分钟。空谈不如数据，数字越具体讨论越有营养。