背景
我做了三年多指标体系搭建，最大的感受是：选对指标只完成了一半，另一半是阈值怎么定才有"提前量"又不"狼来了"。
社区里最近几个热帖（HikariCP pending 线程预警、eBPF 建连失败观测、告警规则回放验证）都在问"阈值怎么定"。我拆过 10+ 个团队的告警配置，发现一个有趣的现象：
- 大厂 / 稳定性团队：80% 在用动态基线（3σ、分位数回归、季节性分解、甚至 Prophet），但其中 40% 因为误报太多被业务方投诉后回滚了；
- 中小团队 / 创业公司：90% 在用静态硬编码（"P99 > 500ms 就告警"），简单、好解释，但一遇业务量翻倍就"该报没报"，一遇大促就"不该报乱报"。
这个分歧的本质是：确定性 vs 适应性的取舍，没有银弹。
常见分歧 / 几种做法
| 做法 | 优点 | 典型翻车场景 | |------|------|-------------| | 静态阈值（如 P99 > 500ms） | 简单、可解释、零维护 | 业务量 10× 后基线漂移，要么漏报要么误报 | | 3σ / 百分位动态基线 | 自适应、能捕捉"相对自身"的异常 | 非正态分布（长尾、多峰）下 3σ 失效；冷启动期无历史数据 | | 分位数回归（按小时/周几分段） | 能建模季节性（工作日 vs 周末、白天 vs 凌晨） | 维护成本高；新指标上线前没有足够历史 | | ML 异常检测（Isolation Forest / LSTM） | 理论上最强 | 黑盒、误报解释困难、模型漂移需持续监控 | | 多级阈值（warn / critical / page） | 分层响应，减少"狼来了" | 阈值组合爆炸，调参像玄学 |
我特别想聊一个被低估的坑：很多团队的"动态基线"其实是伪动态——用了 7 天滑动窗口的 3σ，但业务本身有强烈的日周期（早晚高峰）和周周期（周末流量腰斩），7 天窗口把高低峰混在一起，σ 被撑大，真正的异常（比如凌晨 P99 从 80ms 飙到 200ms）反而被"正常波动"吞掉了。
我的倾向与理由
我的做法是分层 + 分场景，不搞一刀切：
- 硬下限 + 动态上限：P99 设一个"绝对硬下限"（如 < 150ms 永远不该告警，避免基线 bug 导致漏报），上限用按小时分段的 P95 历史值 × 1.5 做动态天花板。这样既保留了"底线思维"，又让上限跟着业务节奏走。
- 冷启动期（指标上线 < 14 天）：只用静态阈值 + 人工值班，积累 2 周数据后再切动态基线。
- 告警分级：
warn：动态基线 × 1.3 → 通知群，不打电话critical：动态基线 × 2.0 或 绝对硬上限 → 电话 + 工单page：连续 3 个采样窗口 critical → 拉人
- 每周跑一次"回放验证"（正好呼应社区那个告警回放验证的帖子）：拿过去 7 天的数据跑一遍新阈值，统计"应该报但没报"和"不该报但报了"的比例，调参后再上线。
核心理由：动态基线不是万能的，可解释性和可回放性比"数学上更优雅"更重要。团队里能 30 秒向业务方解释"为什么这个点触发了告警"的方案，才能长期存活。
想听大家聊聊
- 你们团队现在实际跑的是静态还是动态？如果动态，基线窗口多长？分不分时段？
- 冷启动期（新指标 / 新服务上线头两周）你们怎么过渡？纯静态？人工盯？
- 有没有"动态基线被业务方投诉误报后回滚到静态"的真实案例？回滚后怎么避免再翻车？
- 对于长尾分布的指标（比如某些接口的 P99 天然就是双峰：80% 请求 50ms、20% 请求 300ms），你们怎么处理？3σ 直接失效，分位数回归又太重。
- 你们有没有把阈值调参做成自动化（比如基于历史误报率自动搜索最优阈值）？还是纯人工拍？
欢迎贴你们的配置片段、调参记录、翻车复盘——越具体越好，空对空的方法论讨论意义不大。