性能异常如何排优先级：效应量、置信度与调查队列
自动回归每天可能产生几十条告警。如果只按“下降百分比”排序，最上面往往充满小样本、低基数或数据质量差的误报。本文将影响幅度、统计可信度、用户覆盖和证据完整度组合成可解释的调查队列。
一、告警不等于缺陷
一个指标超过门槛，只能说明它值得检查。设备温控、路径漂移、后台任务、采集丢事件和版本配置差异都能制造告警。反过来，真实回退也可能因为平均值稀释而未越过固定阈值。
系统应该输出候选事件，并说明为什么值得调查，而不是自动宣布根因。
二、四个核心维度
1. 效应量
既看绝对变化，也看相对变化。例如帧时间增加 2 ms 在 8 ms 与 40 ms 基线上意义不同。对接近零的指标，相对变化容易失真，应设置最小绝对门槛。
2. 统计可信度
考虑重复次数、组内波动、置信区间和跨设备一致性。样本越少、波动越大，结论越不稳定。
3. 用户影响
场景频率、设备覆盖、持续时间和是否处于核心路径，决定同样的性能变化有多重要。
4. 证据完整度
是否有有效 Trace、日志、构建身份、温控数据、操作书签和可复现路径。证据不足的事件可能需要先补测，而不是直接分给开发修复。
三、先做硬过滤，再做评分
配置不一致、采集损坏、路径未完成和明显温控异常应先进入数据质量队列，不参与性能排名。对有效样本，再计算可解释分数：
priority = impact × confidence × exposure × evidence乘法能让任一关键维度很低时总分下降，但实际系统应设置最低保障：例如核心启动路径发生严重卡顿，即使证据暂缺，也必须高优先级补采。
四、置信度不能只看 p 值
统计显著不代表业务重要，业务变化大也可能因样本不足尚未显著。报告应同时展示效应量、区间估计、样本量和原始分布。对非正态、长尾帧时间，可使用稳健统计或重采样方法，而不是机械套用单一检验。
五、同一根因的多条告警要聚合
一个资源加载问题可能同时触发 FPS、Game Thread、IO 和内存峰值告警。可按运行身份、时间窗口、场景阶段和归一化调用栈聚合为一个事件，保留多个症状。
聚合后优先级取决于综合影响，而不是把四条告警分别占据队列。系统要允许人工拆分，避免相邻但无关的问题被误合并。
六、队列应该输出下一步动作
- 高影响、高置信、高证据：直接进入根因分析与责任分派；
- 高影响、低证据：优先补采 Trace 或重复实验；
- 低影响、高置信：进入版本预算与批量优化池；
- 低置信且数据质量差：修复测试流程，不进入产品缺陷；
- 多设备一致回退：提高优先级；
- 仅单设备异常：先检查设备健康与分档代表性。
七、评分模型也要回测
定期比较历史告警的最终结果：哪些确认是真实回退、哪些是误报、哪些因排序过低延误。使用这些标签调整权重和规则，但保留模型版本。不能用新评分悄悄重写旧事件的当时决策。
八、面向人的解释
一条好的队列卡片应该写清：
核心战斗阶段 P95 帧时间较同设备基线上升，多个重复样本方向一致；影响中端设备档，Trace 与操作书签完整。建议先检查变点附近资源加载事件。
它给出事实、影响范围、可信理由和下一步，而不是只显示一个神秘的 87 分。
结语
性能运营的瓶颈通常不是发现异常，而是把有限分析时间放在最值得处理的问题上。用效应量、置信度、用户影响和证据完整度构建调查队列，才能让自动化告警真正转化为优化产出。
