异常检

用统计和规则方法标记偏离预期方差的指—20% 的下跌在几分钟内被调查，而非下月报告才发现

为什么

周二某指标跌 30% 要么—bug、要么是营销失败、要么是数据管道断了 —三种情况晚发现的成本都在复利。bug —6 小时影响 6 小时的用户；—6 天影响一个队列并让周报误导。人工监控（有人每天早上看仪表盘）不可扩展：你有 200 个指标，人看 5 个，坏的那个总在没看—195 个里。异常检测把"这个数字正常—自动化，让答案为否时团队被警报，无需人盯每张图。目标不是替代人判断，而是分拣 99% 的正常日子让 1% 的异常日子得到全部注意力

何时使用

指标—4+ 周干净历史数据后（建立基线方差）。上线前就设好，让第一个异常被捕获而非从用户投诉中得知

如何做

1. 收集指标 4-8 周干净历史数据，粒度与告警粒度一致（小时或天—2. 选方法：先简单（高斯—mean +/- 3*std，稳健用 median +/- 3*MAD），仅当简单法假阳—> 5% 才升级到季节性（STL 分解、Prophet—3. 处理季节性：周几（周末流量低）、几点（凌晨 3 点总低）、节假日 —先减去预期季节分量再检测异—4. 把告警阈值设在假阳性可接受的点（起—1 假警/周，信任增长后收紧）
5. 加死人开关：2 个间隔无数据则告—管道断了不报异常因为没有数字可测
6. 路由告警—on-call 频道，含指标名、当前值、预期范围、仪表盘深链 —不只"指标异常"
7. —2 周影子期：告警只记不—在开 paging 前测假阳性率
8. 每季度复核重调：产品增长后方差变化，1k 用户/天对的阈值在 10k 时错了

示例

# 异常：部署成功率下跌 2026-09-21 14:00 UTC
指标：deploy_success_rate（小时，最—6 周基线）
当前—.71  预期：[0.92, 0.99]  Z-score—4.2

告警路由到：#oncall-platform
Runbook：https://wiki/runbooks/deploy-success-drop

调查—  14:03  on-call 确认告警
  14:05  查部署日志：eu-west 区域连续 7 次失—  14:08  根因：CDN 配置推送只—eu-west 破坏了资源解—  14:12  回滚 CDN 配置
  14:15  成功率回—0.97
  14:20  开复盘文档

无异常检测：会在次日早会—8h 后）发现，影—eu-west —400 次部署—
配置— 周影子后调）—  方法：稳健（median +/- 3*MAD—  季节性：周几、几—  阈值：3.0（z-score—  最少样本：336— 周小时）
  假阳性率—.8/周（可接受）

常见问题

⚠对原始值而非偏离预期告警 —凌晨 3 点指标总低，固定阈值每—3 点触发，团队学会忽略所有异常告警，包括下午 2 点那个真的
⚠数据管道无死人开—最灾难的异常（完全无数据）恰是永不触发告警的那个因为没有数字可测，于是静默仪表盘被当做好日子
⚠阈值调太紧以避假阳—团队把阈值设—5 sigma"止噪"，阈值高到只有人本会注意的异常才触发—defeating 目的
⚠对每个指标告警而非关键—10 —200 个异常告警意味着 190 个被忽略—0 个关键的被埋在噪声里；告警预算有限应花在异常即意味用户可见损害的指标上

最佳实践

✓先稳健简单法（median +/- 3*MAD）再—ML —简单法—90% 异常、可向非技术干系人解释、以可预测方式失败；ML 以神秘方式失败侵蚀信任
✓检测异常前总减去季节—周二—1000 跌到 700 是异常；周日—1000 跌到 700 只是周末，混淆二者摧毁告警可信度
✓每个告警含仪表盘深链—runbook —on-call —5 分钟花在"这是真的—，上下文链把其变 30 秒，一年省数百工程师小时
✓任何影响量的产品变更（上线、调价、新市场）后重调阈—基线分布移了，调到旧分布的阈值要么不停触发要么永不触发