背景
做指标体系这几年，我发现一个很反直觉的现象：大家花大量精力在"采集什么指标"和"看板怎么画"上，但对最基础也最容易被低估的一步——阈值到底怎么定——讨论得远远不够。
我见过三种典型翻车：
- 某支付网关 P99 延迟告警写死 200ms，平时 P99 在 80–120ms 之间，但每天凌晨 2 点批跑期间会正常升到 180–250ms，告警每天响 4 次，半年后团队直接把它静音了；
- 某推荐服务 QPS 基线从 5k 涨到 40k（业务增长），但告警阈值还停在"超过 10k 就 P1"，大促前两周天天假 P1；
- 某团队上了动态基线（基于 7 天 EWMA + 3σ），发版当天 QPS 正常波动被判定为异常，告警风暴把 oncall 打懵了，最后发现是基线本身在发版后 24h 内还没收敛。
常见分歧 / 几种做法
| 策略 | 代表场景 | 优势 | 痛点 | |------|----------|------|------| | 固定阈值（SLO 线） | P99 延迟 ≤ 300ms、错误率 ≤ 0.5% | 简单、可解释、"为什么告警"一句话说清 | 波动大的服务要么误报多要么漏报多 | | 动态基线（EWMA / Holt-Winters / 分位数） | QPS、连接池水位、队列深度 | 自适应、误报少 | 基线滞后、冷启动、发版/大促时失真；排查时"为什么触发"不好解释 | | 混合：SLO 固定 + 趋势动态 | 核心 SLA 固定，容量类动态 | 兼顾 | 两套逻辑维护成本翻倍，团队认知负担大 | | ML 异常检测（Isolation Forest、Prophet 等） | 多指标联合、季节性强的业务 | 最灵活 | 黑盒、可解释性最差、线上推理成本、冷启动最痛苦 |
我的倾向与理由
我目前的做法（8 年数据 / 指标体系经验的"偏见"）：
-
SLO / SLA 类指标（P99 延迟、错误率、可用性）→ 固定阈值，不商量。 理由：SLO 本身就是业务承诺，"P99 不超过 300ms"是写给客户的，不应该因为"历史均值是 120ms 所以阈值自动收紧到 150ms"。SLO 阈值变了，等于承诺变了，那应该走业务评审而不是算法自动调整。
-
容量 / 流量 / 趋势类指标（QPS、连接数、队列深度、GC 频率）→ 动态基线 + 兜底固定上限。 理由：这些指标的"正常"本身随业务增长漂移，写死必然过时。但动态基线必须有 hard cap（比如"无论如何不超过 200k"），防止基线算法在极端情况下（新服务冷启动、流量归零后恢复）算出一个荒谬的值。
-
冷启动 / 数据不足（< 7 天）→ 先用宽固定阈值，攒够数据再切动态。 理由：基线是"从历史学出来的"，没有历史就学不出来。硬上 ML 不如老老实实写个宽阈值 + 人工盯。
-
可解释性 > 精度。 一条告警触发后，oncall 第一反应是"为什么"。固定阈值"超过 300ms"一句话就解释完了；动态基线"3σ 之外的 z-score 为 4.2"——oncall 得打开算法文档才能理解。在值班场景下，解释速度就是响应速度。
想听大家聊聊
- 你们线上告警阈值是写死的还是动态的？核心服务（支付、登录）和内部服务（日志、埋点）的策略一样吗？
- 动态基线你们用什么算法？EWMA、Holt-Winters、Prophet、还是直接上 ML？线上推理延迟和成本怎么控的？
- 基线"冷启动"阶段（新服务上线前 7 天）你们怎么处理？有没有"宽阈值 → 动态"的自动切换机制？
- 大促 / 节假日 / 发版这种"正常波动"你们怎么排除？是提前调阈值、还是加白名单、还是用"同比上周同期"代替"环比上一小时"？
- 有没有人踩过"动态基线本身 bug 导致大面积误报 / 漏报"的坑？怎么发现的、怎么兜底的？
欢迎贴具体配置、算法选型、踩坑记录——我比较好奇大家"阈值到底怎么定"这件事上，有没有一个团队级的共识，还是各服务各搞一套。