结论先行：别纠结"STL vs EWMA vs 同比环比"三选一，这是把检测当成了算法选型问题，但它本质是工程分层问题。我带 40+ 指标的体系跑了 14 个月，最终方案是三层叠加，每层解决不同时间尺度的问题，任何一层单独用都会翻车（和你描述的三种方案各有硬伤完全吻合）。
一、分层架构（日级和小时级确实要分开）
| 层 | 职责 | 适用粒度 | 算法 | 刷新频率 | |---|---|---|---|---| | L1 快变检测 | 抓"断崖式突变"（支付成功率从 99.2% 跌到 95%） | 小时级 / 5min 级 | EWMA + 动态 σ 带 | 每 5min 跑一次 | | L2 趋势检测 | 抓"温水煮青蛙"（DAU 每天跌 3% 连跌 4 天） | 日级 / 周级 | 同比 + 连续 N 天偏离 | 每日 T+1 跑一次 | | L3 结构变点 | 抓"业务逻辑变了"（版本发布、口径调整、渠道切换） | 日级 | 贝叶斯在线变点（BOCPD） | 每日跑一次 |
为什么不能只用一个算法：
- 你的 STL + 3σ 翻车在"残差 σ 被业务事件放大"——本质是 L3 该干的事被 L1 扛了；
- 你的同比 ±20% 漏报"每天跌 3% 连跌 4 天"——本质是 L2 该干的"连续偏离"逻辑缺失，单点同比当然抓不到；
- EWMA 在日级不收敛——因为日级只有 7 个点/周，EWMA 的"收敛"前提不成立，应该交给 L2 的趋势判断。
二、各层具体做法（带阈值）
L1：EWMA + 动态 σ 带（小时级指标）
适用指标：支付成功率、接口 P99、消息队列堆积、连接池 pending
算法：
EWMA_t = λ * x_t + (1-λ) * EWMA_{t-1} # λ = 0.2（5min 粒度）
σ_t = sqrt(λ/(2-λ)) * x_t - EWMA_t # 动态带宽
阈值：
- 告警条件：
|x_t - EWMA_t| > 4 * σ_t且x_t偏离基线超过绝对值下限（支付成功率：跌 > 0.5%；P99：涨 > 20ms） - 关键：绝对值下限是"兜底"，防止 σ_t 本身在低流量时段被压得很小，导致 0.01% 的波动也告警
- σ 的维护窗口：只取最近 7 天同时段的数据（排除节假日，见第五节）
我们的误报率：4 个小时级指标 × 30 天 ≈ 每月 3~5 次告警（其中 2~3 次是真实抖动，1~2 次是低流量时段的边缘 case）。比 STL 的 12% 周误报率好一个量级。
L2：同比 + 连续偏离（日级指标）
适用指标：DAU、次日留存、付费率、功能渗透率
算法（两层 AND 条件）：
条件 A：同比偏离 = (today - last_week_same_day) / last_week_same_day < -10%
条件 B：连续偏离天数 ≥ 3（滚动 7 天窗口内）
阈值怎么定的：
- 条件 A 的 -10%：跑 180 天历史，取"非节假日、非版本发布日"的同比偏离分布，P2 分位就是 -10%（我们 40 个指标里，DAU 的 P2 是 -8%，付费率是 -15%，每个指标单独定）
- 条件 B 的 3 天：你提到的"每天跌 3% 连跌 4 天"，3 天就能抓到第 3 天，比等到 4 天（同比还在阈值内）提前一天
关键改进：条件 B 不是"连续 3 天都 < -10%"，而是**"滚动 3 天中 ≥ 2 天 < -5%"**——这样每天跌 3% 的缓降也能在第 2~3 天触发，不需要等到单天跌破 -10%。
L3：贝叶斯在线变点（日级，抓结构变化）
适用场景：版本发布、口径调整、渠道结构变化——这类事件会让"基线本身"跳变，L1/L2 全部失效。
算法：Rust/Python 的 ruptures 库（BOCPD 或 PELT），对每个指标单独跑：
import ruptures as rpt
model = rpt.Pelt(model="rbf").fit(X) # X 是最近 90 天的日级序列
seg = model.predict(penalty=10) # penalty 控制灵敏度
- penalty 的定法：用 180 天历史回测，取"每年 4~6 个真实变点"对应的 penalty 值（我们 DAU 的 penalty ≈ 12，支付成功率 ≈ 8）
- 变点触发后：自动切换基线窗口（把变点前的数据从 EWMA / 同比的参考窗口里剔除），L1/L2 的阈值自动重算
三、误报率控制（狼来了问题的工程解法）
目标：40 个指标 × 30 天，总告警 ≤ 15 次/月（含真实异常）。
三个工程手段：
- 告警分级 + 冷却：同一指标 24h 内同类告警只发 1 次（去重窗口 24h）；L1 触发 = P2 通知 on-call，L2 触发 = P3 通知数据团队，L3 触发 = P1 通知全组（结构变点意味着所有指标基线可能要重算）
- 已知事件屏蔽：版本发布日、运营活动日、节假日（含前后 1 天）加入静默日历，L1/L2 的告警降级为"仅记录不通知"，但 L3 的变点检测不屏蔽（版本发布正是结构变点的来源）
- 误报反馈闭环：每次告警被标记"误报/已知原因"后，自动记录到
alert_feedback表。每月底跑一次：SELECT metric, reason, COUNT(*) FROM alert_feedback WHERE month=... GROUP BY 1,2，按 top-3 误报原因调参（通常是某个指标的绝对值下限没设够）
我们的实际数据：上线 14 个月，累计告警 87 次，误报 22 次（25%），漏报 3 次（都是"指标本身在变但业务方认为是正常的"——比如 DAU 自然衰减 5%，严格来说该报但业务方不认为是异常）。
四、指标树上下游联动
核心思路：不是"父指标异常时子指标降级"，而是**"先判上游，再判下游"**。
具体做法：
- 维护一张指标依赖 DAG（字段血缘 + 计算 SQL 解析），标注每个指标的"上游依赖指标"
- 告警触发时，先查 DAG：如果上游指标在 ±2h 内也触发了告警，下游告警自动标记为"可能为级联"，通知文案里带上"上游 {DAU} 同时异常，本指标可能为级联影响"
- 不自动降级（因为有时候上游和下游确实同时有独立问题），而是改通知策略：级联告警合并成一条（"DAU 跌 12%，其下游 3 个指标同时波动"），减少 on-call 的告警条数
踩坑：一开始我们做"上游异常 → 下游自动静默"，结果漏了一次"DAU 跌了 8%（没到告警线），但付费率独立跌了 25%"——上游小波动 + 下游大波动同时发生，静默策略把真正的付费率问题吞了。改成"标记级联但不静默"后，漏报从 5 次降到 3 次。
五、业务变更干扰（版本发布 / 运营活动）
最大的坑：不是算法被干扰，是算法的参考窗口被污染。
解法：
- 变更事件日历：每次版本发布、运营活动、口径调整，在
change_events表里记一条(date, metric_scope, type)。L1/L2 计算时自动排除这些天的数据（从 EWMA 参考窗口和同比参考日里剔除） - L3 变点检测兜底：如果变更没记入日历（漏记了），L3 会捕获到结构变点，自动触发"基线重算"——相当于人工记日历的兜底
- 口径变更的特殊处理：指标口径变了（比如 DAU 的定义从"打开 App"改成"停留 > 30s"），必须手动标记为"口径断裂"，L1/L2/L3 的参考窗口全部重算，不能用历史数据做同比。我们的做法是：口径变更日的指标序列标记为
baseline_break，后续 7 天为"新基线收敛期"，只记录不告警
踩坑：一次"次日留存"的口径从"次日打开"改成"次日有行为"，我们忘了标记 baseline_break，L2 的同比逻辑把新口径的"高 5%"当成了"异常上涨"，告警了 3 天才被人工关掉。从那以后口径变更必须走 baseline_break 标记。
六、落地节奏建议（40 个指标，20 人团队）
| 阶段 | 周期 | 做什么 |
|---|---|---|
| P0 | 2 周 | 先把 L2（同比 + 连续偏离）跑起来，只覆盖 5 个核心日级指标。实现最简单（ClickHouse SQL + 定时任务），先解决"4-12h 滞后"的痛点 |
| P1 | 3 周 | 上 L1（EWMA + 动态 σ），覆盖小时级指标。需要 5min 粒度的预聚合表（ClickHouse AggregatingMergeTree） |
| P2 | 2 周 | 上 L3（BOCPD），跑在日级序列上。ruptures 库 Python 脚本，每天凌晨跑一次 |
| P3 | 持续 | 指标依赖 DAG + 级联告警合并 + 误报反馈闭环 + 变更事件日历 |
别一上来就上 Prophet / LSTM：40 个指标的维护成本确实是硬伤，而且这些模型的"可解释性"在 on-call 场景下是致命的——告警响了，on-call 问"为什么报"，你没法用"因为 LSTM 的 hidden state 变了"来回答。EWMA + 同比 + BOCPD 这套组合，每一步都能用人话解释。
引用了提问里提到的 #186（指标归因拆解流程）和 #984（指标体系分层设计），前者是"异动后怎么拆"，我这个回答是"异动前怎么抓"，两者拼起来才是完整的指标异动治理闭环。