共享 staging 下「失败后重试即绿」：怎么区分 flaky 用例 vs 环境瞬时污染，有没有可执行的排查顺序？

背景

我负责一条 B 端 SaaS 的接口自动化，pytest 7.4 + httpx，约 800 条用例，跑在 50 个并发 worker 共享的 staging 上（MySQL 8 同库 + Redis 7 + Kafka 1 个 topic）。

现象

最近两个月，每天 CI 红灯约 2~3 次，其中 约 60% 是「失败一次，重试（retry=1）即绿」。

典型 case 举例：

• test_order_refund_flow：断言 refund_status == "completed"，实际拿到 "pending"，重试后绿；
• test_inventory_sync：断言库存数量，实际差 1，重试后绿；
• test_user_notification：断言消息已送达，实际未收到，重试后绿。

三个 case 没有共同的技术根因，但共性是：都依赖 staging 的异步状态收敛（Kafka 消费、定时任务、MQ 投递），且都发生在 50 worker 高并发时段（早 9:00-10:00，多团队同时跑）。

已尝试的排查

1. 看日志：失败时段 MySQL 慢查询日志有 3~5 条 >200ms 的查询（正常时段 <50ms），但不确定是否与本用例相关；
2. 看 Redis：INFO 里 used_memory 在失败时段从 40% 涨到 72%，但不确定是否是缓存污染；
3. 看 Kafka：consumer lag 在失败时段从 0 涨到 ~5000，恢复后归零；
4. 关掉重试（retry=0）：红灯率从 2~3 次/天 涨到 8~10 次/天，但每次失败都能稳定复现（不是 flaky，是真的环境状态没收敛）；
5. 给断言加 polling（最多等 5s）：红灯率降到 1~2 次/天，但引入了新的不确定性（等待时间不稳定）。

卡点

我现在的困境是：「失败后重试即绿」这个信号太模糊——它既可能是 flaky（用例本身不稳定），也可能是环境瞬时污染（高并发导致状态收敛延迟）。这两种情况的修复策略完全不同：

• flaky → 隔离、修用例；
• 环境污染 → 降并发、加资源、改断言策略（polling）。

我需要的答案形态：

1. 可执行的排查顺序：失败后，应该按什么顺序检查哪些指标？（比如：先查 Kafka lag → 再查 MySQL 慢查询 → 最后查 Redis？还是反过来？有没有优先级依据？）
2. 判定规则：在什么条件下可以判定是「环境污染」而非「flaky」？（比如：Kafka lag > X 且 MySQL 慢查询 > Y 条，就判定为环境污染？）
3. 可落地的方案：有没有现成的工具或模式，可以在 CI 里自动采集这些指标并在失败时做归因分析？

参考

站内已有相关讨论：

• Wilson 置信区间 + 最小样本量给 flaky 用例定判据（谢亦舟-868）
• flaky 用例该不该隔离，靠什么客观数据判据（谢亦舟-868）

但这两个都聚焦在「判 flaky 还是判真 bug」，没有覆盖「判 flaky 还是判环境污染」这个维度。