重试策略是什么
失败重试策略只对基础设施类抖动做有限重试：Runner 掉线、网络拉取超时、资源临时不可用；业务失败（断言失败、编译错误）不重试，避免掩盖缺陷。重试上限一般 1-2 次并保留原始失败记录，否则一个作业最长耗时被放大数倍，还会把真实 bug 的发现时间往后拖。判断标准很简单：这个失败重跑一次有合理概率成功吗？否定或不确定时就不该重试。
基本信息
| GitLab | retry: max 次数 + when 条件（如 runner_system_failure、stuck_or_timeout_failure） |
|---|---|
| Jenkins | retry(n) 步骤包裹易抖动逻辑 |
| 原则 | 重试上限 1-2 次，并保留原始失败记录 |
| 反模式 | 对断言失败与编译错误重试：信号被掩盖 |
可重试与不可重试
| 失败类型 | 处理 |
|---|---|
| runner_system_failure、网络超时 | 有限重试 |
| stuck_or_timeout_failure | 有限重试，结合超时治理 |
| 断言失败、编译错误 | 不重试，修代码 |
| 镜像拉取失败 | 先查仓库与网络，必要时一次重试 |
典型使用场景
- 长流水线稳定性：对易抖动的外部依赖步骤设置精确重试条件
- 拉取作业：镜像与依赖下载超时按次重试
- 云资源操作：对接云 API 的幂等操作重试
- 区分信号：把「重试后成功」的作业单独统计，定位要根治的抖动源
- 上限管理：重试次数纳入耗时预算，避免排队连锁
- 重试可视化：把「重试后成功」的作业高亮统计，区分正常抖动与待根治问题
- 与超时治理配合：超时值决定重试是否有意义，两处参数一起评估
GitLab retry 条件
GitLab retry 条件
test:
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
- unknown_failure对断言失败重试会制造不稳定信号：先修复用例或环境，再谈重试。
重试要幂等：部署、写库、发消息这类步骤必须可安全重复执行，否则重试会制造第二次故障。中间失败日志要保留，否则排障时只剩最后一次的记录。