08 · 告警为什么没人看

⏱ 42 分钟 ｜ 🎁 短，但能救你很多个夜晚

🎯 一句话

一个每天响 20 次的告警，和没有告警是一样的 —— 甚至更糟， 因为它让你以为自己有监控。

📉 一、告警疲劳是怎么发生的

🔑 关键的数字：如果一个告警的误报率超过 50%，它在心理上就已经失效了。 人不会持续响应一个「多半是假的」的信号 —— 这不是态度问题，是必然。

🎚️ 二、告警分级：不是所有异常都该叫醒你

⭐ 绝大多数模型告警应该是 P2。 模型退化几乎总是渐进的，不需要半夜叫人。 把 P2 的东西设成 P0，是告警疲劳的头号来源。

🛠️ 三、六个降低误报的实用技巧

① 持续时间条件

② 用同比而不是绝对值

⭐ 同比是模型监控里性价比最高的一个技巧。 业务指标几乎都有强周期性，用绝对阈值一定会被周期打败。

③ 用分位数而不是均值

④ 分人群看，避免辛普森效应

🔗 这是第 14 章辛普森悖论在监控上的形态。

⑤ 告警要带上下文

⭐ 好的告警应该让人在 30 秒内判断出「要不要现在处理」。 🔗 第 11 章会给一份排查手册的模板。

⑥ 告警收敛

🧪 四、告警上线前必须做的一件事：回测

⭐ 第 ④ 步是关键：只看误报率会让你把阈值调得过松，什么都报不出来。 必须同时看漏报：拿历史上真实发生过的事故当测试集。

💡 这其实就是准确率-召回率权衡在告警设计上的应用 （🔗 ML基础 05）—— 告警系统本身就是一个分类器，你在给它选工作点。

📓 五、告警之外：值班手册和事后复盘

事后复盘要产出的东西：

⭐ 「发现延迟」是衡量监控体系最好的单一指标。 比「有多少个告警」有意义得多 —— 后者只说明你加了多少规则。

💀 六、第 48 次

上面那个"12 周"的时间线不是虚构的形状。下面这个是它的具体数字版。

⭐ 这个事故的责任不在值班同学身上。 在 2.1% 准确率下，"先静音"是理性行为 —— 一个人不可能每次都为 2% 的概率立刻起身。 是告警设计逼出了这个行为。

🔑 复盘后他们做的三件事（都在本章讲过）： 1. 这条规则从 P0 降到 P1，并加上"连续 10 分钟"的持续条件 2. 阈值改成和上周同一时段比，而不是和固定基线比 3. 新增一条真正的 P0：降级触发率 > 20%（这条在两个月回测里只会响 1 次）

结果：P0 从每月 24 次降到每月 0.5 次，而那唯一一次真事故仍然能被报出来。

📊 七、告警系统的四个数字

"我们有 30 个告警"不是一个指标。这四个才是：

💡 一个立刻可做的动作：给每条告警加一个"这是真的吗"的按钮（👍/👎）。 两周之后你就有了每条规则的准确率 —— 然后把准确率低于 30% 的规则全部降级或删掉。 删掉一条噪声告警，比新增一条监控更能提升可靠性。

🧪 八、告警回测：可以直接跑的框架

第四节说"上线前必须回测"。这是一个能跑的版本：

import numpy as np, pandas as pd

def backtest_alert(series: pd.Series, rule, incidents, sustain=1):
    """series : 按时间索引的指标（建议按小时）
       rule   : 函数 (series) -> bool 数组，True 表示该时刻满足告警条件
       incidents : [(开始时间, 结束时间)] 已知的真实事故
       sustain: 需要连续满足几个时间点才真的告警  ⭐"""
    raw = pd.Series(rule(series), index=series.index).fillna(False).astype(int)

    # ⭐ 持续时间条件：连续 sustain 个点都满足才算一次告警
    fired = raw.rolling(sustain, min_periods=sustain).sum() >= sustain

    # ⭐ 相邻的连续告警合并成一次「事件」，否则一次故障会被数成几十次
    grp = (fired != fired.shift()).cumsum()[fired]
    events = [(g.index[0], g.index[-1]) for _, g in fired[fired].groupby(grp)]

    # 召回：每个已知事故有没有在窗口内被报到
    hit = [any(s <= e2 and e >= s2 for s2, e2 in events) for s, e in incidents]

    # 误报：没有落在任何事故窗口内的告警事件
    fp = [ev for ev in events
          if not any(ev[0] <= e and ev[1] >= s for s, e in incidents)]

    days = (series.index[-1] - series.index[0]).total_seconds() / 86400
    return {
        "告警次数": len(events),
        "每月次数": round(len(events) / days * 30, 1),   # ⭐ 直接对上分级标准
        "召回": f"{sum(hit)}/{len(incidents)}",
        "误报次数": len(fp),
        "准确率": round(1 - len(fp) / max(len(events), 1), 3),
    }


# 用法：把几套候选规则一起跑，挑工作点
rules = {
    "绝对阈值 CTR<3%":      lambda s: s < 0.03,
    "同比 <上周70%":        lambda s: s < s.shift(24 * 7) * 0.7,      # ⭐ 去周期
    "同比 <上周70% 且持续":  lambda s: s < s.shift(24 * 7) * 0.7,
}
# backtest_alert(ctr_hourly, rules["同比 <上周70% 且持续"], known_incidents, sustain=3)

⭐ 这个表就是本章的核心方法： 不要问"这个阈值合不合理"，要问"在同样的召回下，哪个规则误报最少"。 🔗 这就是准确率-召回率曲线在告警设计上的用法 —— 你不是在调参数，你是在一条曲线上选工作点。

📐 三种阈值形式的对比

💡 实践中的组合：业务指标用同比 + 固定基线两条线。 同比抓突变，固定基线抓慢漂移 —— 单独任何一条都会漏掉一整类问题。

⚠️ 告警设计的八个坑：

📓 九、一份可以照抄的值班手册模板

⭐ 模板里最关键的是 ①：它把"这个告警意味着什么"变成了三个可以立刻看的数。 没有这一步，值班的人会从"打开看板"开始 —— 而那通常要 10 分钟。 🔗 第 11 章会把这套判断扩展成一棵完整的排查树。

🔗 十、和站内其他章的关系

✅ 检查点

1. 为什么说「每天响 20 次的告警比没有告警更糟」？关键的误报率数字是多少？
2. 告警四个级别的划分依据是什么？P0 的判据是什么？
3. 为什么绝大多数模型告警应该是 P2？
4. 六个降低误报的技巧里，哪个性价比最高？为什么？
5. 分人群看是为了防什么？
6. 好的告警应该让人在多久内做出判断？要带哪些上下文？
7. 告警回测时，只看误报率会有什么问题？
8. 衡量监控体系最好的单一指标是什么？为什么不是「告警数量」？
9. 「第 48 次」那个事故里，告警准确率是多少？为什么说责任不在值班同学身上？他们复盘后做了哪三件事？
10. 告警系统该看哪四个数字？一次事故的实际影响时长由哪三段组成？哪一段最常被忽略？
11. 回测那张表里，三条规则的召回都是 3/3，这说明了什么？该选哪条？
12. 绝对阈值 / 环比 / 同比 / 固定基线各自的弱点是什么？业务指标推荐怎么组合？
13. 为什么告警要「指定到人」而不是发到大群？
14. 值班手册里最关键的是哪一部分？为什么？

🛑 可以停在这里

⚡ 走神救援

⭐ 每天响 20 次的告警比没有告警更糟——它让你以为自己有监控。 误报率超过一半之后，人就不会再持续响应了；这是必然，不是态度问题。

四级里绝大多数模型告警应该是 P2（模型退化几乎总是渐进的）。把 P2 当 P0 是告警疲劳的头号来源。P0 的判据只有一条：多等一小时会造成不可逆损失。

降误报最值钱的两招：用同比不用绝对值（业务指标都有周期，绝对阈值必然被凌晨打败）和加持续时间条件。其余四招：分位数代替均值、分人群看、告警带上下文、按根因收敛。

⭐ 上线前必须拿历史回测，而且不能只看误报——要拿历史真实事故当测试集看漏报。 告警系统本身就是个分类器，你是在选工作点。

💀 那个「第 48 次」：两个月响了 48 次 P0 只有 1 次是真的，真出事时值班同学静音了，22 分钟后被客服叫醒。责任不在人身上——那个准确率下先静音是理性行为，是告警设计逼出来的。

⭐ 立刻能做的一件事：给每条告警加 👍/👎，两周后删掉准确率最低的那批规则。删一条噪声告警比加一条监控更能提升可靠性。

下一节 👉 09-特征重要性的三种谎言.md ⭐