Flaky test 容忍度之争：「偶发失败」到底该设 1% 容忍线，还是零容忍直接红灯？

【背景】 做了 5 年测试开发，最近半年我们组围绕「flaky test（偶发失败）」打了一架，而且我发现不同团队的口径完全不一样，所以想拉出来聊聊。

我们的现状：CI 上 ~3200 个用例，按 3 次重跑统计，稳定复现的 flaky 大约 12 个（占比 0.37%）。这 12 个用例的共性是：依赖时间戳比较、依赖网络抖动、依赖并发写共享文件。每次发布前只要撞上，就得人工判断「是它又飘了还是真回归」，平均一次浪费 20~40 分钟。

【常见分歧 / 几种做法】我在不同团队见过四种流派：

1. 零容忍派：任何 CI 红灯都默认是真 bug，flaky 一律当天修，修不完就隔离（quarantine）出主线。代表论据：容忍线一旦存在，就会被用来「合法化」偷懒。
2. 容忍线派：给一个明确预算，比如 flaky 率 < 1%、且单用例失败率 < 5% 才放行；超过预算冻结新需求先还债。代表论据：零容忍在时间压力下必然演变成「重跑三次绿了就过」，规则形同虚设。
3. 隔离派：不修不删，直接挂到 quarantine 队列，每两周清一次，清不动就降级为 nightly。代表论据：CI 的价值是快，把慢排查挪到离线。
4. 放任派：口头都知道是 flaky，但没有任何机制，靠工程师记忆。——这一派我见过最多，也最危险。

【我的倾向与理由】 我倾向「容忍线 + 隔离 + 到期熔断」的组合，而不是纯零容忍：

• 容忍线必须有数字，且写进 CI 配置而不是 wiki。我们用的是：单用例 30 次内失败率 ≥ 5% 自动进 quarantine；quarantine 里停留 > 14 天直接删除并在周报公示。数字可以吵，但没有数字一定烂。
• 隔离不等于放任：quarantine 是「带 TTL 的停车场」，不是坟场。删一个烂用例的成本远低于 3000 人每天怀疑 CI 的成本。
• 但零容忍派有一句话我服：容忍度会侵蚀。所以我们的对冲措施是——flaky 率进团队周报，连续 4 周上升触发一次专项，而不是等它变成事故才回头看。
• 另外一条工程纪律：任何「重跑通过」必须在 CI 日志里留痕（哪个用例、重跑几次、最终状态），否则「偶发」和「真 bug」在数据上就分不开了。

【想听大家】

1. 你们团队现在是哪种流派？容忍线（如果有的话）具体是多少，怎么定下来的？
2. quarantine 队列你们怎么管？有没有「隔离了半年没人碰」的经验（我猜有）？
3. 零容忍派的朋友：你们怎么防止「重跑到绿」变成默契操作？有没有技术手段而不靠自觉？
4. 一个更尖锐的问题：如果让你选，是宁可 CI 慢一点（比如加 10% 时长做稳定性验证），还是要快但允许偶发假绿？你的业务场景是什么让你这么选？

欢迎贴你们的 CI 配置片段、flaky 率数据、翻车案例——具体数字比立场有用。