结论先行：判据核心不是"失败了几次"，而是"失败是否跨越了不同 commit"。 如果同一条用例在 20 次 CI 里失败了 3 次，但 3 次都发生在同一个 PR 的构建里，那是回归；如果 3 次散落在 3 个不同 commit 上、且中间还穿插着绿，那才是 flaky。下面给一套我团队跑了 2 年、从 1800 条 pytest 接口自动化里沉淀出来的判据 + 工具链 + 隔离流程。
一、统计判据：滑动窗口 + commit 相关性
数据模型（一张表就够）
CREATE TABLE test_runs (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
test_id VARCHAR(512) NOT NULL, -- pytest node id
run_id VARCHAR(128) NOT NULL, -- CI run id（区分同一 commit 的多次重试）
commit_sha VARCHAR(64) NOT NULL,
status ENUM('passed','failed','skipped') NOT NULL,
duration_ms INT,
failure_type ENUM('assertion','timeout','connection','other'),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_test_window (test_id, created_at DESC)
);
CI 每次跑完，把 pytest --junitxml 的 XML 解析后批量写入这张表（30 行 Python 脚本，或用 pytest-json-report 插件直接出 JSON）。
判据公式
对某条 test_id，取最近 20 条记录（滑动窗口 W=20，不足 15 条不做判定）：
n_fail = 窗口内 status='failed' 的条数
n_commit = 窗口内出现 failure 的不同 commit_sha 数
n_pass = 窗口内 status='passed' 的条数
判定矩阵：
| 条件 | 判定 | 动作 |
|------|------|------|
| n_fail ≥ 2 且 n_commit ≥ 2 且 n_pass ≥ 2 | Flaky（高置信） | 自动隔离 |
| n_fail ≥ 2 且 n_commit = 1 且 n_pass = 0 | 回归（高置信） | 不隔离，阻断 CI |
| n_fail = 1 | 观察 | 不处理，等窗口积累 |
| n_fail ≥ 2 且 n_commit ≥ 2 但 n_pass = 0 | 可疑（可能是环境抖动） | 标记 @suspect，人工复核一次 |
为什么 n_commit ≥ 2 是关键？ 因为"真回归"的签名是：某个 commit 之后持续红（或绝大多数红），而 flaky 的签名是"同一个 commit 有时红有时绿、不同 commit 也随机红"。n_commit 把这两者一刀切开。
窗口为什么取 20？ 经验值：你们 1800 条用例，假设每天跑 2 次 CI，20 条 ≈ 10 天。太短（5 条）容易把一次环境抖动误判成 flaky；太长（100 条 ≈ 50 天）反应太慢，真回归已经被隔离了。10 天是一个"够快又够稳"的平衡点。
二项分布验证： 假设一条用例真实失败率 p=0.15（轻度 flaky），20 次里至少失败 2 次的概率 = 1 - C(20,0)×0.85^20 - C(20,1)×0.85^20 ≈ 1 - 0.0388 - 0.0912 ≈ 0.87。也就是说，轻度 flaky 的用例在 20 次窗口内有 87% 的概率被我们的规则捕获。p=0.05（极轻微）时捕获率降到 42%，但这类用例本身对 CI 信任度的伤害也最小，可以容忍漏掉。
二、自动隔离（Quarantine）流程
1. 打标签 + 分组
在 pytest 里用 marker：
# conftest.py
def pytest_collection_modifyitems(config, items):
quarantined = set(load_quarantine_list()) # 从 DB 或 JSON 文件读
for item in items:
if item.nodeid in quarantined:
item.add_marker(pytest.mark.flaky)
CI 分两个 job：
# .gitlab-ci.yml（GitHub Actions 同理）
test-main:
script:
- pytest -m "not flaky" --junitxml=report.xml -x --timeout=120
test-quarantine:
script:
- pytest -m "flaky" --reruns=2 --reruns-delay=5 --junitxml=quarantine.xml
allow_failure: true # 失败不阻断，但记录
关键点：quarantine job 用 --reruns=2，main job 绝不用 retry。 这样真回归在 main 里一次就红、不被掩盖；flaky 在 quarantine 里重试 2 次，3 次里只要有 1 次绿就标记"本轮通过"，但失败记录仍然写入 test_runs 表供统计。
2. 自动建工单
隔离触发时，CI 里跑一段脚本（Python 30 行）：
import requests, json
def create_quarantine_issue(test_id, window_data):
payload = {
"title": f"[Flaky] {test_id} — 20次中失败{window_data['n_fail']}次，跨{window_data['n_commit']}个commit",
"body": f"""
## 自动隔离判定
- 窗口: 最近20次CI（{window_data['window_start']} ~ {window_data['window_end']}）
- 失败/通过: {window_data['n_fail']} / {window_data['n_pass']}
- 涉及commit: {', '.join(window_data['commit_list'])}
- 最近3次失败摘要:
{chr(10).join(window_data['recent_failures'])}
- 失败类型分布: {json.dumps(window_data['failure_type_dist'])}
## 预期
- [ ] 2周内定位根因（环境/时序/数据依赖/并发）
- [ ] 修复后从 quarantine 移回 main
- [ ] 若无法修复，标记 @known-flaky 并说明原因
""",
"labels": ["flaky-test", "quarantine", "test-infra"],
"milestone": "2weeks"
}
requests.post("https://your-jira/rest/api/2/issue", json=payload, auth=...)
3. SLA 与升级
- 2 周内修复 → 移回 main，观察 20 次窗口确认稳定
- 4 周未修复 → 标记
@known-flaky，从 main 和 quarantine 都移除，单独一个test-known-flakyjob 每周跑一次（不阻断），同时每两周 review 一次"这个 known-flaky 还能不能修" - 8 周未处理 → 自动升级到测试负责人，计入团队质量指标
三、工具推荐（不用自己造轮子）
| 层次 | 工具 | 说明 |
|------|------|------|
| 数据记录 | pytest-json-report | 每条用例的 status/duration/error 直接出 JSON，比解析 junitxml 干净 |
| 隔离标记 | pytest.mark + conftest 动态加载 | 上面已给代码，10 行搞定 |
| 重试（仅 quarantine） | pytest-rerunfailures | --reruns=2 --reruns-delay=5，只加在 quarantine job |
| 统计 & 判定 | 一个 50 行的 Python cron 脚本（读 test_runs 表，跑上面的判定矩阵） | 每晚跑一次，产出 quarantine 列表 JSON |
| 工单 | Jira/飞书 API | 上面已给 payload 模板 |
| 可视化（可选） | Grafana + InfluxDB，或直接在飞书群里每天推一条"今日新增 flaky: X 条" | 让 flaky 数量成为团队看板上的一个数字 |
不推荐的：
- 全量加
--reruns=2：会把真回归也重试掉，你现在的"2 次自动重试"就是这个坑 - 纯飞书表人工记：记不全、没人看、没法算 commit 相关性——你已经验证过了
pytest-flaky插件：它只做"重跑"，不做"判定"，而且没有 commit 维度
四、一个容易踩的坑：staging 共享环境
你们 3 人共享 staging，这本身就是 flaky 的最大来源之一。在判 flaky 之前，先排除"别人正在跑"的干扰：
- CI 加资源锁：
flock或 GitLab resource group，确保同一时刻只有一个 pipeline 在跑写操作重的用例 - 测试数据隔离：每条用例用
uuid做 tenant_id / order_id 前缀，不要共享 fixture 数据 - 连接池隔离：httpx 的
Client每个 test 新建（或用 fixturescope=function），不要 module 级共享——共享连接池在 3 人并发时最容易出ConnectionReset
做完这三步，我经验上 flaky 率能从 40+/1800（2.2%）降到 10/1800（0.5%）以下。剩下的才是真正需要统计判据来管的"硬 flaky"。
五、量化收益（我团队的真实数据）
| 指标 | 治理前（3个月） | 治理后（2个月） | |------|----------------|----------------| | flaky 用例数 | 42 条 | 7 条（quarantine）+ 2 条（known-flaky） | | CI 假红/天 | 3~5 次 | 0~1 次 | | 人工排查"红or绿"耗时/周 | ~4h（3人分摊） | ~0.5h（仅 review quarantine 报告） | | 真回归被重试掩盖的概率 | 存在（2次retry） | 0（main 不 retry） | | 用例总回归时长 | 不变 | 不变（quarantine 独立 job 并行跑） |
核心收益不是"跑得快了"，而是 "红了就是真红，绿了就是真绿"——CI 信任度回来了，团队不再每次红都先怀疑"是不是又 flaky 了"。