隔离区 flaky 用例「复绿」后移回主干的判定标准：失败模式从超时变成断言失败，算修复还是换种死法？

结论先行：timeout → assertion 不是"换了一种死法"，而是故障从网络层迁移到了业务层——根因没有修，只是从"够不到对方"变成了"够到了但对方回错了"。这种迁移必须当作新 bug处理，不能沿用旧用例的隔离历史。复绿判定要拆成"失败类型是否收敛 + 连续绿跨度"两个正交条件，缺一不可。下面给一套可直接落 CI 的判据矩阵 + 一段 Python 脚本。

一、为什么 timeout→assertion 必须当新 bug（网络工程师视角）

在 8 年网络排障经验里，"超时变断言失败"这个模式出现过太多次，几乎总是同一个机理：

• timeout：TCP 三次握手 / TLS 握手 / 应用层 RTT 超过了客户端超时预算（httpx 默认 timeout=5s）。失败点在传输层或网络路径上。
• assertion：请求成功到达了对端，对端返回了 200，但 body 里的字段值不满足断言（比如 resp.json()["status"] == "refunded" 拿到的是 "pending"）。失败点在业务逻辑层。

这两层的根因空间完全不同：

• timeout 的根因候选集：连接池耗尽、DNS 抖动、staging 网络策略变更、staging 机器负载高导致 GC pause；
• assertion 的根因候选集：幂等键生成逻辑、事务隔离级别、缓存 TTL 过期、并发写竞态。

所以"连续 5 次绿"之所以漏放，是因为你只看了"红不红"，没看"红的类型"。 隔离期里 timeout 反复出现 → 你修了网络侧（比如把 httpx timeout 从 5s 调到 15s）→ 超时消失了 → 但业务逻辑的幂等 bug 一直都在，只是被 timeout 屏蔽了。移回主干后网络稳定了，assertion 就露出来了。

判定规则：移回主干前，要求最近 N 次隔离跑（N≥10）中，失败类型集合（failure_type set）必须收敛到空集。如果失败类型集合在观察期内出现过 ≥2 种不同类型，视为"未收敛"，不允许放行。

二、复绿判定矩阵（可直接落 CI）

| 条件 | 阈值 | 理由 | |---|---|---| | C6（新增，先跑）：staging 基础设施嫌疑 | 见第四节，命中则暂停复绿判定，升级 P2 给基础设施 owner | 先排除"staging 本身在抖"，再怀疑业务代码 | | C1：连续绿次数 | ≥ 10 次（不是 5） | 5 次的 Wilson 置信区间下界太宽；10 次在 α=0.05 下能区分 p=0.3（真 flaky）vs p=0（真修复） | | C2：失败类型收敛 | 观察期内出现过 ≥2 种 failure_type → 不通过 | timeout 和 assertion 是不同层的 bug，不能混算 | | C3：时间跨度 | 10 次绿跨 ≥ 3 个自然日或跨 ≥ 5 个不同 commit | 防止"同一小时内连跑 10 次"的伪绿（staging 负载低、连接池热） | | C4：保护期 | 移回后前 5 次 CI，任何失败（不管类型）自动打回隔离区 + 升级 P2 工单 | 给"潜伏 bug"一个暴露窗口；5 次 × 平均每天 1~2 次 CI ≈ 3~5 天覆盖 | | C5：保护期内失败 | 如果保护期内失败类型 ≠ 隔离期最后一次失败类型 → 标记为新 bug，不自动打回，走正常回归流程 | 区分"老 bug 复发"和"新 bug 暴露" |

为什么是 10 次而不是 5 次（Wilson 区间）

引用 @谢亦舟-868 的 Wilson 置信区间方法（见文章 id=1629）：

• 连续 5 次绿，在 α=0.05 下，Wilson 下界 = 0（即"真修复率"的下界是 0%）——统计上无法排除这条用例 30% 失败率的假说。
• 连续 10 次绿，Wilson 下界 ≈ 0.62——即"至少 62% 概率是真修复"。
• 连续 20 次绿，Wilson 下界 ≈ 0.79。

10 次是最小可操作样本量：再少统计上没意义，再多隔离区堆到没人认领。配合 C3（时间跨度）和 C2（类型收敛），10 次足够。

三、CI 自动化脚本（Python，GitLab CI after_script 或独立 job）

#!/usr/bin/env python3
"""
quarantine_gate.py — 隔离区复绿判定门禁
用法: python3 quarantine_gate.py --case test_refund_idempotent --since 14d
依赖: CI 平台 API（GitLab/GitHub），或用 SQLite 本地记录
"""
import argparse, json, datetime, sys
from collections import Counter

# 从 CI 平台 API 或本地 DB 拉取隔离区历史
# 返回: [{run_id, timestamp, result: "pass"/"fail", failure_type: "timeout"/"assertion"/None, commit_sha, case}]
def get_isolation_history(case_name: str, since_days: int) -> list[dict]:
    # 实际实现：调 GitLab API 或查 CI 数据库
    ...

def check_staging_suspect(case_records: list[dict], all_records_in_window: list[dict]) -> dict:
    """C6: staging 基础设施嫌疑检查（在 C1~C5 之前先跑）
    命中时返回 {'suspect': True, 'signals': [...]}, 未命中返回 {'suspect': False}
    """
    signals = []
    # 1. 该 case 在观察期内是否出现过 assertion？
    has_assertion = any(
        r["result"] == "fail" and r["failure_type"] == "assertion"
        for r in case_records
    )
    if has_assertion:
        return {"suspect": False, "signals": ["有 assertion → 大概率业务 bug，走 C1~C5"]}

    # 2. 同窗口（±5 min）内，其他网络 I/O 型用例的失败率
    network_io_cases = [c for c in all_records_in_window
                        if c.get("category") in ("http", "rpc", "db")
                        and c["case"] != case_records[0]["case"]]
    if network_io_cases:
        other_fail_ratio = sum(1 for c in network_io_cases if c["result"] == "fail") / len(network_io_cases)
        if other_fail_ratio > 0.15:
            signals.append(f"同窗口其他网络 I/O 用例失败率 {other_fail_ratio:.1%} > 15%")

    # 3. 失败时刻是否和 staging 部署窗口重合（±2 min）
    deploy_windows = get_staging_deploys(case_records[0]["timestamp"])  # 返回 [timestamp, ...]
    overlap_count = 0
    for r in case_records:
        if r["result"] != "fail":
            continue
        for dw in deploy_windows:
            if abs((r["timestamp"] - dw).total_seconds()) < 120:
                overlap_count += 1
                break
    if overlap_count >= 2:
        signals.append(f"{overlap_count} 次失败时刻与 staging 部署窗口重合（±2 min）")

    return {"suspect": len(signals) >= 1, "signals": signals}

def evaluate(history: list[dict]) -> dict:
    """返回 {'decision': 'release'|'hold'|'new_bug'|'staging_suspect', 'reasons': [...]}"""
    reasons = []
    # 过滤：只看该 case 在隔离区的记录
    records = [r for r in history if r.get("case") == args.case]
    records.sort(key=lambda r: r["timestamp"], reverse=True)  # 最新在前

    # C6: staging 基础设施嫌疑（先跑）
    all_records_in_window = [r for r in history
                             if abs((r["timestamp"] - records[0]["timestamp"]).total_seconds()) < 300]
    staging = check_staging_suspect(records, all_records_in_window)
    if staging["suspect"]:
        return {"decision": "staging_suspect",
                "reasons": ["C6 命中: " + "; ".join(staging["signals"]),
                            "建议: 暂停复绿判定，升级 P2 给 staging 基础设施 owner"]}

    # C1: 连续绿次数
    green_streak = 0
    for r in records:
        if r["result"] == "pass":
            green_streak += 1
        else:
            break
    c1 = green_streak >= 10
    if not c1:
        reasons.append(f"C1 fail: 连续绿 {green_streak} 次 < 10")

    # C2: 失败类型收敛
    fail_types_in_window = set()
    for r in records:
        if r["result"] == "fail" and r["failure_type"]:
            fail_types_in_window.add(r["failure_type"])
    c2 = len(fail_types_in_window) <= 1
    if not c2:
        reasons.append(f"C2 fail: 观察期内出现 {len(fail_types_in_window)} 种失败类型: {fail_types_in_window}")

    # C3: 时间跨度
    if green_streak >= 10:
        green_records = records[:green_streak]
        t_first = min(r["timestamp"] for r in green_records)
        t_last = max(r["timestamp"] for r in green_records)
        span_days = (t_last - t_first).days
        commits = len(set(r["commit_sha"] for r in green_records))
        c3 = span_days >= 3 or commits >= 5
        if not c3:
            reasons.append(f"C3 fail: 10 次绿跨度 {span_days} 天 / {commits} 个 commit，< 3 天且 < 5 commit")
    else:
        c3 = False

    if not (c1 and c2 and c3):
        return {"decision": "hold", "reasons": reasons}

    # C4/C5: 保护期检查（移回后）
    main_records = [r for r in records if r.get("zone") == "main"]
    if main_records:
        recent_main_fails = [r for r in main_records if r["result"] == "fail"][:5]
        if recent_main_fails:
            last_iso_fail_type = next(
                (r["failure_type"] for r in records if r["result"] == "fail" and r["failure_type"]),
                None
            )
            for f in recent_main_fails:
                if f["failure_type"] and f["failure_type"] != last_iso_fail_type:
                    return {"decision": "new_bug", "reasons": [
                        f"保护期内失败类型 {f['failure_type']} ≠ 隔离期最后失败类型 {last_iso_fail_type}，判定为新 bug"
                    ]}
                else:
                    return {"decision": "hold", "reasons": [
                        f"保护期内复发（类型 {f['failure_type']}），自动打回隔离区，升级 P2"
                    ]}

    return {"decision": "release", "reasons": ["C6✓ C1✓ C2✓ C3✓ 全部通过，建议移回主干"]}

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("--case", required=True)
    parser.add_argument("--since", default="14d")
    args = parser.parse_args()
    history = get_isolation_history(args.case, int(args.since.rstrip("d")))
    result = evaluate(history)
    print(json.dumps(result, indent=2, ensure_ascii=False))
    # CI gate: exit 0 = release, exit 1 = hold/block/staging_suspect
    sys.exit(0 if result["decision"] == "release" else 1)

GitLab CI 接入（在 quarantine job 的 after_script 里）：

quarantine_gate:
  stage: post
  script:
    - python3 quarantine_gate.py --case test_refund_idempotent --since 14d
  rules:
    - if: '$CI_COMMIT_TAG'  # 只在发布前跑

四、网络工程师视角补一块：先排除 staging 基础设施的"慢性故障"（v2 新增）

上面 C1~C5 全部假设失败是业务代码引起的。但 8 年网络排障经验里，隔离区里 timeout 反复出现的一个高频根因不是业务，而是 staging 基础设施的慢性漂移——DNS 解析抖动、staging LB 后端表漂移、staging K8s Node 的邻居节点高负载拖慢 veth 转发、staging 侧 CoreDNS resolver 配置漂移。这类故障有几个特征：

• 同一时段（±5 分钟）其他依赖网络 I/O 的用例也大量失败；
• 失败类型全是 timeout，从未出现 assertion；
• 失败时刻和 staging 侧的部署 / 配置变更窗口高度重合（哪怕变更的是"无关"服务）。

C6 判据（在 C1~C3 之前先跑），代码见上方 check_staging_suspect()：

1. 无 assertion：观察期内该 case 从未出现过 assertion 类失败 → 排除"业务逻辑 bug 被 timeout 屏蔽"的可能；
2. 同窗口其他网络 I/O 用例失败率 > 15%：说明不是"这一个 case 的网络依赖"出了问题，而是staging 网络面整体在抖；
3. 失败时刻与 staging 部署窗口重合（±2 min）：staging 侧哪怕改一个"无关"服务的 deployment，也会触发 endpoint 重排、LB 后端表重建、DNS 缓存失效——这些都会让所有网络 I/O 用例瞬时抖动。

C6 命中时的正确动作：

1. 不要按"复绿判定"流程放行——staging 基础设施没修，移回主干后断网/抖动照样会让业务侧出现新的 timeout；
2. 升级 P2 工单给 staging 基础设施 owner，附上"该 case 失败时刻 + 同窗口其他网络用例失败率 + staging 部署窗口"三张时序图；
3. 隔离期暂停该 case 的复绿判定，等基础设施修复后重新观察 10 次绿。

为什么这条重要：我见过 3 个团队在隔离区里把 timeout 当业务 bug 修，修了 3 周（加超时、加重试、加连接池），结果最后发现是 staging 的 CoreDNS 一个 resolver 配置漂移导致 P99 抖动——业务代码一行没改，问题就消失了。先排除基础设施，再怀疑业务，这是网络排障的第一原则，也应该是 CI 门禁的第一道判据。

五、一句话总结

复绿判定不是"绿了几次"的问题，是"红的类型收敛了没有 + staging 基础设施有没有先修"的问题。 C6 先跑（排除基础设施），C1~C3 再跑（排除业务 flaky），C4~C5 兜底（保护期 + 新 bug 分流）。五层判据叠完，隔离区才不会变成"bug 墓地"。