复盘会喊出 10 个候选指标、落地只留 2 个且多半是同步指标：小样本（10 次事故 × 7 min 窗口）下怎么用数据方法筛出真·前导指标？

【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。最近半年在 3 个不同团队做"事故复盘 → 改进项 → 监控告警"的落地收尾。反复出现同一个模式：复盘会上 6–8 个工程师各自喊"应该盯 X 指标"，最后落地时只留 1–2 个，而且留下来的 70%+ 是 P99、错误率、5xx 这类结果指标，不是真正的前导指标。

【现象（带数据）】

1. 复盘会平均产出 8–12 个候选指标（pending 线程数、连接池 active 占比、队列深度、GC pause、慢查询数、CPU、内存、网络重传……），落地时只留 2–3 个，且留下来的大多是同步/滞后指标。
2. 选"前导指标"全靠经验拍脑袋。比如"连接池 active 占比到底是不是 P99 的前导？它和 P99 是同时抖还是提前 30 s 抖？"——没人拉过数据验证，大家"觉得是"就上了。
3. 指标字典膨胀后（参考 id=1023，候选指标从 10 滚到 50+），"哪个真能提前报警、哪个只是事后确认"更难判断，告警规则越积越多但信噪比越来越差。
4. 最拧巴的：小样本。我统计了 3 个团队过去 12 个月的 P99 抖动事故，每团队 8–12 次，每次持续 30 s~2 min。一年也就 10 来个"事件"，每次事件窗口 7 min（前 5 min + 后 2 min）。这个量级根本跑不动常规时序方法。

【已尝试的排查与结果】

• Pearson 相关：对每个事故窗口（1 s 粒度）算候选指标与 P99 的 Pearson r。结果：同步指标（P99 本身、CPU、错误率）r 最高（0.85~0.95），真正有 lead time 的指标（pending 线程、连接池 active 占比）r 反而只有 0.4~0.6。"相关系数高"和"有提前量"是两回事，但团队里很多人把它们混为一谈。
• 互相关函数（CCF）看 lag：理论上最对路——CCF 峰值出现的 lag 就是 lead time。但 10 个事件 × 7 min 窗口，CCF 的 95% 置信区间宽到 ±20 s，分不清是"真提前 30 s"还是"噪声"。
• Granger 因果检验：要求几百个独立样本，10 个事件根本不够，p 值不可信。
• 事件对齐后的相位差：把 10 个事故按 P99 跳变时刻对齐，看各候选指标"上升沿"相对 P99 的偏移。能看出来 pending 线程平均比 P99 早 40~80 s 开始爬，但样本太小，无法排除"这 10 次恰好如此"。

【期望得到的答案形态】

1. 方法论：有没有一套可复现的"候选指标 → 真·前导指标"筛选流程？我说的不是"某个具体资源该盯哪个指标"（1524/1707/1856 已经聊得很透），而是通用的数据方法：从 N 个候选里用数据把它们分类为"前导 / 同步 / 滞后"三类，并给出判定依据。
2. 小样本落地：10 个事件 × 7 min 窗口的量级，互相关 / Granger / 相位差，哪个方法在这个量级下最不容易翻车？有没有 bootstrap / 置换检验等替代方案能把置信区间收窄到可用？
3. 区分真假前导：怎么从数据上排除"和 P99 强相关但其实是同步或滞后"的假前导？（比如错误率和 P99 相关系数 0.9，但它和 P99 是同时跳的，报警时已经晚了。）
4. 阈值与提前量：筛出真前导后，阈值怎么定才能"提前 30 s~2 min 报警"而不是"P99 已经飙了才触发"？（1524 里大家在问阈值，但我的卡点更上游——怎么先证明它确实是前导。）

【为什么问这个】 复盘会上的"应该盯 X 指标"如果全是经验判断，改进项落地后就变成了"又加了一条告警"，而不是"多了一个能提前报警的抓手"。我想把"前导指标"从信仰变成可验证的结论——哪怕一年只有 10 次事故，也应该有办法用数据把它们从 50 个候选里挑出来。