CI 里 5% 的 flaky 用例：重试、隔离还是删掉？聊聊不稳定用例的团队策略

背景

做了 3 年测试开发，最近维护一套 B 端 SaaS 的接口自动化（pytest + httpx，约 1800 条用例，跑在共享 staging 环境 + MySQL 8 + Redis 7）。撞上一堵很现实的墙：CI 里大概有 3%–5% 的用例是「时好时坏」的 flaky——同一份代码，这次红下次绿，红的理由五花八门：staging 环境造数没跑完就开跑、上游 mock 服务偶发 500、Redis 连接池偶发超时、甚至两条用例并发时互相踩了共享数据。

更麻烦的不是红本身，而是红带来的副作用：开发开始对 CI 脱敏（红了就点重跑，重跑绿了就当没事），review 时没人再认真看那 3% 的红色日志；有一次真 bug 被 flaky 噪音埋了两天才挖出来。我把它比作「狼来了」——谎话（假红）说多了，真狼来了也没人信。

常见分歧 / 几种做法

我观察到团队里大致有三派：

1. 重试派：在框架层加 retry（比如 pytest-rerunfailures，失败自动重跑 2 次）。优点是 CI 基本不红、体验好；缺点是假绿变多，真正的偶发 bug 被重试「洗白」，而且重试会掩盖环境问题，让造数慢、连接池小这类根因永远不被修。
2. 隔离派：给 flaky 用例打标（如 @flaky），主流程跳过，单独放一个 nightly 慢车道跑；每周复盘隔离区，修好一个放一个。优点是主流程干净、根因有专门时间修；缺点是多了一套「隔离区」的维护成本，而且隔离区很容易变成「数字垃圾桶」，越积越多没人管。
3. 删除/重写派：认为一条不稳定 3 个月以上的用例基本没有信号价值，不如删掉重写或干脆砍掉。优点是套件瘦身、信噪比高；缺点是删除有心理成本（「当初写它是有原因的啊」），而且有些 flaky 恰恰是环境真实缺陷的信号，删了等于把报警灯摘了。

我的倾向与理由

我倾向于「隔离 + 限期」：flaky 用例一律进隔离区，但每个隔离用例必须挂一个 issue 和 deadline（比如 2 周），超期没修自动在群里 @ 负责人。理由有三：

• 隔离区给了「修根因」的专门空间，比一上来就删更温和，也给环境缺陷留了证据；
• 限期 + 责任人避免隔离区变成数字垃圾桶（这是隔离派最大的坑）；
• 重试可以作为临时止血（比如发版日），但不作为常态——否则假绿会侵蚀团队对 CI 的信任，这是最贵的成本。

配套我还会做两件事：一是把 flaky 率（flaky 次数 / 总运行次数）进周报，作为团队指标之一；二是给共享环境加「用例间数据隔离」的规范（每条用例用自己的 tenant_id / 造数前置断言），因为经验上 70% 的 flaky 是并发踩数据，不是真随机。

想听大家

• 你们团队现在对 flaky 是哪种策略？重试、隔离、删除，还是「能忍就忍」？
• 隔离区你们怎么防「数字垃圾桶化」？有没有好用的机制（看板、自动报警、超期删除）？
• 有没有量化过 flaky 率，它和线上 bug 漏测率有没有相关性？
• 你们觉得「flaky 率进周报」会不会变成 KPI 游戏（大家倾向把 flaky 直接删掉刷指标）？

欢迎带具体数字和工具链来聊，越具体越好。