全绿就敢发版吗？聊聊「测试通过」和「线上不出事」之间到底隔着什么

背景

做了 15 年测试开发，我最近在一个 12 人后端团队做发布质量复盘时，撞上一堵反复出现的墙：过去 18 个月，团队接口自动化从 600 条涨到 2100 条，CI 全绿率长期 95%+，单测覆盖率 78%，但同期线上 P1/P2 事故还是有 4 起。事故复盘里，测试侧被点名的次数其实不多——更多是"开发漏了某个字段校验""配置中心推了一个错的环境变量""某条老 SQL 在 8.0 下执行计划变了"。

换句话说：「测试通过」和「线上不出事」之间，有一道我们一直没拆清楚的断层。 这道断层到底宽多少、由谁负责拆，我看了三个团队的实践，发现大家基本分三种做法，但没有一种让所有人都服气。

三种常见做法

• 做法 A：CI 全绿即放行。 质量门禁 = 自动化通过率 + 单测覆盖率 + 静态扫描。优点：规则简单，谁都能执行；缺点：质量责任被压到测试侧，开发对"质量"的理解变成"测试没找出来的就是测试的锅"，结果测试越严、开发越被动，最后大家默契地绕过门禁走 hotfix。
• 做法 B：把指标分层。 在 A 之上加"缺陷逃逸率""线上事故数""核心链路覆盖率"。优点：数字更立体；缺点：逃逸率统计口径极难统一——谁来界定"这个 bug 算测试责任还是开发责任"，一旦口径不清，这个指标就变成吵架的燃料。
• 做法 C：按风险分层，只对核心链路强门禁。 非核心链路走抽检 + 灰度。优点：最接近真实决策；缺点："哪些是核心"这个判断本身是主观的，而且团队里没人愿意承认自己那条链路是"非核心"。

我的倾向与理由

我个人偏 C 的骨架 + B 的指标：核心链路必须有"自动化 + 数据隔离 + 可复现压测"三件套，非核心链路走 diff 驱动的用例拉取 + 灰度兜底。但我自己也在卡一个具体的数字——全绿 + 灰度 30 分钟无异常，到底够不够？ 我见过 30 分钟灰度窗口里没抓到但放量后 4 小时才爆的"定时任务型"bug；也见过灰度 3 天还放出去、上线当天爆的"数据规模型"bug。所以"多久算够"这件事，我到现在没有标准答案。

想听大家聊的具体场景（越具体越好）

1. 你团队里有没有"全绿但上线后 P1"的事故？事后复盘时，大家是怎么界定"测试责任"边界的？
2. 如果核心链路 860 条用例全绿、逃逸率为 0、P99 达标，灰度 5% 流量 30 分钟无异常——你们会全量吗？还是要求更长的灰度窗口 / 更高的流量比例 / 额外的观察指标？
3. 当开发说"这个场景测试没覆盖，不算测试责任"时，你们团队的回应话术是什么？
4. 有没有人真的把"逃逸率"跑通了？口径是怎么定的？

期待带场景、带数字、带复盘细节的回答，别口号。