构建失败策略是什么
构建失败处理策略是团队对「主干构建红灯」的响应约定：谁负责修、多长时间内修、红灯期间能否继续合并新代码。目标只有一个——不让问题顺流而下进入发布环节。Google SRE 与 DORA 的经验一致：修复中断的构建应优先于一切新工作，因为红灯会迅速传染给所有协作者，恢复成本随时间上升。
基本信息
| 适用平台 | 任何以主干为集成中心的 Git/CI 流程 |
|---|---|
| 响应 | 失败通知直达提交者与负责人，优先修复再开新工作 |
| 停止线 | 主干连续失败或红灯超时即暂停合并，集中恢复 |
| 豁免 | 紧急修复走显式例外流程：值班负责人批准并留记录 |
典型使用场景
- 主干随时可发布：红灯清零前不再放开合并
- 多人协作仓库：提交者与值班轮换制，明确第一责任人
- 不稳定流水线治理：把「重跑一下就好」的隐性成本显性化
- 新人上手规范：写清失败时的第一反应与求助路径
通知内容模板
通知内容模板
项目 / 分支 / 提交 / 失败作业 / 日志链接 / 首次失败时间 / 责任人
# 附「下一步动作」：重跑入口、日志直达页、快速回滚命令红灯分级与响应
| 级别 | 判定 | 响应 |
|---|---|---|
| 单次失败 | 主干单条流水线失败 | 提交者限时响应，修不掉则先回滚 |
| 连锁失败 | 后续提交在坏基线上连续失败 | 暂停合并，责任人集中修复 |
| 超时红灯 | 红灯时长超过约定上限 | 值班升级通知，负责人介入 |
「按需重跑」不是修复：统计重跑成功率可识别真实的不稳定源（随机失败的用例、抖动的环境），把它们当缺陷治理而不是当噪声忽略。
失败分类（代码、用例、环境、基础设施）是归因的前提：四类混在一起统计，改进方向永远看不清。