11 · 从告警到根因

⏱ 42 分钟 ｜ ⭐ 一份可以照抄的排查手册

🎯 一句话

线上排查最贵的不是修，是「不知道从哪查」。 这一章给一条固定的排查顺序 —— 从最便宜、最可能的原因开始，逐级往下。

🪜 一、排查顺序：便宜的先查

🔑 ⑥ 放在最后不是随意的： 真正「模型自己变差了」的情况远比想象的少。 绝大多数线上问题是数据、管道、配置、外部变化造成的。 一上来就重训模型，是最常见的浪费。

① 是真的吗（别急着查）

⭐ 「分母变了」这条每年都会坑到人： CTR 跌了不一定是点击少了，可能是曝光暴涨（比如上了个新坑位）。 看比率类指标时，永远同时看分子和分母的绝对值。

② 什么时候开始的 ⭐ —— 最有价值的一步

⭐ 拐点时间是排查里信息量最大的一个数字。 有了它，你能把「所有可能原因」缩小到「那个时间点附近发生的事」—— 通常就剩三五件事可查。

配套要有的东西：一条变更时间线

拐点其实可以让机器帮你找（不用肉眼盯曲线）：

import numpy as np

def find_changepoint(series, min_seg=6):
    """最小二乘单拐点检测：把序列切成两段，找「组内方差和」最小的切点。
    series: 按小时（或按天）排好序的指标序列"""
    x = np.asarray(series, dtype=float)
    n = len(x)
    best, best_cost = None, np.inf
    for k in range(min_seg, n - min_seg):
        cost = x[:k].var() * k + x[k:].var() * (n - k)   # ⭐ 两段各自越"平"越好
        if cost < best_cost:
            best, best_cost = k, cost
    a, b = x[:best], x[best:]
    jump = b.mean() - a.mean()
    se = np.sqrt(a.var() / len(a) + b.var() / len(b)) + 1e-12
    # ⭐ 关键是这个 z：跳变幅度要和"本来的波动"比，否则天天都能找出拐点
    return {"拐点位置": best, "跳变幅度": jump, "显著性z": jump / se}

# 用法：把最近 14 天 × 24 小时的指标喂进去，拿到「第几个小时」

⭐ 一定要看那个 z，不要只看 best： 这个函数永远会返回一个拐点，哪怕序列完全是白噪声。 经验阈值：|z| ＜ 3 时基本可以认为「没有拐点，只是在正常波动」 —— 这时候你要查的不是「谁变了」，而是回到 ① 确认「跌」是不是真的存在。

③ 谁变了

⭐ 一个关键原则：能回滚就先回滚，再慢慢查。 止损优先于定位。 回滚后指标恢复了，也顺便验证了「就是这次发布的问题」。

④ 哪部分流量

💡 拆开看还能发现第 14 章那种情况： 总体没变，但两个人群一涨一跌互相抵消 —— 那其实是两个问题。

⑤ 哪个特征（这一步用第 5、9、10 章的工具）

import numpy as np, pandas as pd, shap

def diff_shap(model, X_bad, X_good, top=10):
    """对比异常时段和正常时段，找出贡献变化最大的特征"""
    ex = shap.TreeExplainer(model)
    sb = ex.shap_values(X_bad).mean(axis=0)     # ⭐ 带符号取均值，看方向
    sg = ex.shap_values(X_good).mean(axis=0)
    d = pd.DataFrame({
        "特征": X_bad.columns,
        "异常时段贡献": sb, "正常时段贡献": sg, "变化": sb - sg,
        "特征均值变化": X_bad.mean().values - X_good.mean().values,
    })
    return d.reindex(d["变化"].abs().sort_values(ascending=False).index).head(top)

⭐ 同时看「贡献变化」和「特征均值变化」这两列，能直接分辨两种情况：

贡献变了	特征均值变了	说明
✅	✅	输入变了（数据/管道问题）⭐ 最常见
✅	❌	输入没变但作用变了 → 可能是模型或编码问题

⑥ 最后才是模型本身

⚠️ 「加载了错误版本」比想象中常见，而且查起来只要 10 秒 —— 建议把它提到第 ① 步一起查。

💀 二、一次真实的排查复盘（完整时间线）

这个案例值得逐行读，因为它踩中了本教程前十章里的三个坑， 而且它的特征是「所有技术指标都正常」。

告警：周二 09:12，拦截率从 1.8% 掉到 1.1%（告警阈值 1.5%）。

💀 这个故障最恶心的地方： 降级是设计好的行为，所以整条链路"完全健康" —— 接口成功率 100%，错误率 0，P99 延迟反而从 42ms 降到 26ms （因为不查 Redis 了，更快了）。 一个只看「服务健康」的监控体系，对它是全盲的。

代价：

为什么没被早发现（三条，每条都对应前面某一章）：

⭐ 改进之后，三个月后同类问题（另一个特征源限流）再次发生： 发现延迟从 31 小时降到 4 分钟。 这就是第 8 章说的「每次事故都该让发现延迟下降一点」的实际样子。

🩺 三、症状 → 最先怀疑什么（速查）

这张表是上面那套流程的「快捷方式」：先看症状对号入座，猜错了再回到六步流程。

⭐ 第一行是最值得记住的一条： 「所有技术指标都正常，业务指标却掉了」几乎总是降级、兜底或默认值。 因为真正的故障会留下错误率，而降级不会。

📋 四、一份可以直接用的排查模板

## 事件：<指标> 于 <时间> 下降 <幅度>

### ① 确认
- [ ] 口径未变 / 数据已跑完 / 基线合理 / 分母正常
- [ ] 模型版本号符合预期

### ② 时间点
- 拐点：______（精确到小时）
- 形状：突变 / 阶梯 / 缓降 / 周期

### ③ 该时间点附近的变更
| 时间 | 变更 | 相关性 |
|---|---|---|

### ④ 影响范围
| 维度 | 受影响的分组 | 未受影响的分组 |
|---|---|---|

### ⑤ 特征层面
| 特征 | 贡献变化 | 均值变化 |
|---|---|---|

### 结论
- 根因：
- 止损动作 / 时间：
- **发现延迟**：______（从发生到发现）⭐
- 改进项：新增什么监控能提前 N 小时发现

⭐ 最后两行是复盘的价值所在（第 8 章）： 每次事故都应该让「发现延迟」下降一点。

🧠 五、六个经验法则

💡 第 ② 条在紧急情况下最容易违反： 慌了就同时回滚模型、改配置、重启服务 —— 恢复了，但你永远不知道原因，下次还会再来一遍。

⭐ 第 ⑤ 条的具体做法：排查像二分查找 —— 每一步都问「这个问题在哪一半」，而不是「是不是这个原因」。 六步流程本身就是一条二分链：时间维度二分 → 流量维度二分 → 特征维度二分。 一个维度平均能砍掉一半可能性，三个维度就是 1/8。

⚠️ 六、排查时最常踩的七个坑

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

✅ 检查点

1. 排查的六个步骤是什么？为什么「模型本身」放最后？
2. 「是真的吗」这一步要查哪四件事？哪一条每年都坑人？
3. 为什么说拐点时间是信息量最大的数字？四种形状各指向什么？自动找拐点时为什么必须看 z 而不只看位置？
4. 「变更时间线」该包含什么？它省了哪一步的时间？
5. 排查时的第一原则是什么？
6. 按流量维度拆开看，两种结果分别意味着什么？
7. SHAP 对比时，同时看「贡献变化」和「特征均值变化」能分辨什么？
8. 那个 Redis 扩容的案例里，为什么所有技术指标都正常？发现延迟是多少、后来降到了多少？「成功率 100%、延迟反而下降、但业务指标掉了」几乎总是什么原因？
9. 紧急情况下最容易违反哪条经验法则？后果是什么？

🛑 可以停在这里

⚡ 走神救援

⭐ 排查顺序：便宜的先查。 ①是真的吗 ②什么时候开始的 ③谁变了 ④哪部分流量 ⑤哪个特征 ⑥模型本身。

⭐ ⑥ 放最后，因为「模型自己变差」远比想象中少，绝大多数是数据、管道、配置或外部变化——一上来就重训是最常见的浪费。

⭐ 拐点时间是信息量最大的数字，它能把可能原因缩到那个时间点附近的三五件事。形状直接指向类型：突变 → 发布/配置/上游；阶梯 → 数据源或口径变了；缓降 → 漂移不是故障；周期 → 定时任务。

原则：止损优先于定位，能回滚先回滚；一次只改一个变量（慌了同时回滚+改配置+重启，恢复了也永远不知道原因）；先缩范围再看细节。

💀 那个 Redis 扩容配错前缀的案例：特征读超时触发了设计好的降级，于是成功率 100%、错误率 0、延迟反而更好，只有拦截率悄悄掉了——一个只看服务健康的监控体系对它完全失明。

⭐ 最该记住的速查：技术指标全正常、业务指标却掉了 → 几乎总是降级、兜底或默认值。 真故障会留下错误率，降级不会。所以「没报错」不等于「没出错」。

下一节 👉 12-AB实验你以为你懂了.md