题目重点：流水线失败不全是代码错误，区分确定失败、环境故障和flaky。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练合同：按commit构建与测试，有发布门禁；日志与测试版本可追溯。
- 题目未给组织具体重试/发布规则；本文采用确定性失败阻断，环境错误可有限重试，flaky需标记和负责人。
解题路线
- job状态机区分QUEUED/RUNNING/PASS/FAIL/INFRA_ERROR/CANCELLED，attempt每次不同，artifact记录commit、镜像、随机种子、依赖和失败签名。
- 环境错误指数退避有限重试；确定断言失败保留首失败，不用直到一次成功就抹掉原失败。flaky检验使用多次证据、隔离清单期限与责任人，避免自动永久绕过门禁。
- 通知按失败签名、branch、commit段聚合，先向owner给可操作信息，再按持续时间/影响升级。修复后发恢复消息；不能以“降低通知数”牺牲关键事故覆盖。
- pipeline取消旧commit时保留证据，部署读取固定artifact digest与测试结果，避免最新标签被更新产生测试过A发布B。
手动走一遍
单测试10次1次失败，重跑成功仍记录flaky事件与首次栈；不能标为完全无问题。全机器DNS故障导致1000job失败，聚合为基础设施事故，同时各job保留引用，修复后控制重试洪峰。
规模与取舍
吞吐受worker并发、测试时长和重试倍率限制；预计执行量=原job数×平均attempts。监控p95排队、失败分类、误告警、漏告警与flaky隔离年龄。
易错点与追问
容易失分的边界
- 只缓存“测试名通过”会跨commit/环境复用无效证据。
- 重试不是幂等天然保证：integration测试可能写共享数据或触发付费外部动作。
继续深挖
- 如何智能选择变更相关测试，同时用全量周期回归检测漏选？
- 测试失败但产品急需修复时，例外授权如何记录证据、责任和回滚门槛？
