构建失败的分级与修复时限，核心是把“影响多大”和“多久必须修好”绑定在一起：先按影响范围把失败分成阻断级、严重级、一般级和提示级，再为每一级指定责任角色、响应时限、修复时限和升级路径，并把规则写进流水线，让失败自动打级、自动通知、超时自动升级。本文给出一套可直接套用的分级定义、责任时限矩阵、落地步骤和复盘机制，适合正在建立或收紧持续集成管理规范的研发团队参考。
要点总览（TL;DR）
- 按影响范围把构建失败分为阻断级、严重级、一般级和提示级，判定顺序固定为：是否阻断主干合并、是否影响发布候选、是否只影响个人分支。
- 每一级绑定唯一第一责任人、响应时限、修复时限和升级对象；时限先以可执行的宽松值起步，运行两到四周后按实际修复耗时分布收紧。
- 把分级条件写进流水线，实现自动打级、按级通知、超时自动升级，并建立按级别、模块、责任人聚合的失败看板。
- 复盘触发条件设为同一根因两周内重复三次以上或单周某级失败超阈值，结论转成有负责人和期限的改进项，并反哺分级规则与门禁。
- 用检查清单定期核对规则覆盖度、时限执行、升级触发、复盘产出和失败趋势，找出闭环中的断点。
分级标准：按影响范围把构建失败分成四级
构建失败的分级依据是影响范围，判断顺序可以固定为三问：是否阻断主干合并，是否影响发布候选，是否只影响个人分支。三个问题依次回答，级别随之确定，避免同一失败被不同人判成不同级别。
四级定义如下：阻断级指主干分支构建失败或导致主干无法合并，全团队开发活动受阻；严重级指发布候选分支构建失败，或主干虽可构建但关键测试阶段失败，影响本次发布；一般级指功能分支构建失败，影响单个需求或小范围联调，主干与发布不受影响；提示级指构建成功但存在告警，如静态检查告警、依赖版本过期提醒、非阻塞的测试波动。
| 级别 | 判定条件 | 典型例子 | 判定人 |
|---|---|---|---|
| 阻断级 | 主干构建失败或主干合并被阻塞 | 主干编译报错、主干单元测试大面积失败、合并请求因构建红灯无法合入 | 流水线自动判定，值班人确认 |
| 严重级 | 发布候选分支构建失败，或主干关键测试阶段失败 | Release 分支打包失败、集成测试在主干持续失败、制品无法产出 | 流水线自动判定，构建维护人确认 |
| 一般级 | 功能分支构建失败，主干与发布不受影响 | 个人分支编译错误、分支内单测失败、分支依赖安装失败 | 流水线自动判定，提交人确认 |
| 提示级 | 构建通过但存在告警或非阻塞问题 | 代码规范告警、依赖版本过期、偶发测试波动但未失败 | 流水线自动标记，提交人自行处理 |
判定时机放在构建结束的那一刻：流水线根据分支类型、失败阶段和失败范围自动打级，值班人或构建维护人只在规则无法覆盖的边界情况下人工复核。把判定前移到流水线，可以减少“谁来定级”的扯皮，也让后续的时限和通知有统一输入。
修复时限与责任分工：每级对应谁、多久、怎么升级
时限设定遵循一个原则：级别越高，响应越快、修复窗口越短、升级越早。初始时限宜宽松可执行，运行两到四周后根据实际修复耗时分布逐步收紧，避免一上来就设定无人能达成的目标。
责任角色分四类：提交人是失败构建的直接责任人，负责定位与修复；模块负责人对反复失败的模块承担兜底责任，协调跨人排查；值班人负责当班期间的失败确认、分派与升级；构建维护人负责流水线本身的问题，如环境、脚本、依赖源故障。角色可以兼任，但每个失败必须有唯一的第一责任人。
| 级别 | 第一责任人 | 响应时限 | 修复时限 | 超时升级对象 |
|---|---|---|---|---|
| 阻断级 | 提交人，值班人确认 | 15 分钟内响应 | 2 小时内修复或回滚 | 模块负责人，30 分钟未响应升级至技术负责人 |
| 严重级 | 提交人，构建维护人协助 | 1 小时内响应 | 当个工作日内修复 | 模块负责人，超时升级至发布负责人 |
| 一般级 | 提交人 | 当个工作日内响应 | 2 个工作日内修复 | 模块负责人，超时在迭代例会上通报 |
| 提示级 | 提交人 | 不强制响应 | 随下次提交或迭代内处理 | 纳入周度复盘统计，不单独升级 |
表中的具体数字是参考起点，团队应按自身节奏调整：每日多次发布的团队可以把阻断级修复时限压到 1 小时以内；发布周期以周为单位的团队，严重级修复时限可以放宽到两个工作日。调整的依据是历史数据，而不是主观感觉。升级路径要提前写清楚通知对象和通知方式，超时后由系统自动提醒，避免依赖某个人记得去催。
落地步骤：让分级和时限在流水线里自动生效
规则写在文档里只是共识，写进流水线才是机制。落地分四步推进，每步都有明确的输入、动作、输出和完成标志。
步骤一：梳理现有失败类型并归类
输入是近四到八周的构建失败记录，动作是逐条标注失败阶段、影响分支和根因类别，输出是一张失败类型清单及各类占比。完成标志是清单覆盖了绝大多数历史失败，且团队对分类口径没有分歧。这一步的价值在于让分级规则建立在真实数据上，而不是凭空设计。
步骤二：确定分级规则与时限并达成团队共识
输入是步骤一的失败类型清单和本文的四级框架，动作是逐级确认判定条件、责任角色、响应与修复时限、升级对象，输出是团队确认版的分级与时限矩阵。完成标志是矩阵在团队评审中通过，并明确生效日期。共识环节不能省，时限只有被责任人认可才可能被执行。
步骤三：在流水线中配置分级标记与通知
输入是确认版矩阵，动作是把分支类型、失败阶段等条件映射为级别标记，并配置按级别分发的通知渠道和接收人，输出是自动打级、自动通知的流水线配置。完成标志是用模拟失败验证过每一级都能正确打级并通知到人。通知要包含级别、失败阶段、提交人和日志入口，让接收人打开消息就能开始处理。
步骤四：建立失败看板与超时提醒
输入是流水线产生的失败数据，动作是搭建按级别、按模块、按责任人聚合的失败看板，并配置超时未修复的自动提醒，输出是可持续查看的失败视图和超时提醒规则。完成标志是看板数据与实际失败一致，且至少触发过一次超时提醒并被正确处理。
如果团队使用 ONES 承载研发管理，可以把流水线数据接入项目视图：ONES 支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据、更新执行状态和日志，并将流水线与项目关联，用于可视化 CI/CD 过程、识别阻塞。这样失败记录、关联的工作项和责任人信息处在同一处，分级后的处置和后续复盘不必在多个系统之间来回核对。
复盘机制：把高频失败转成持续改善
分级和时限解决的是单次失败的处置效率，复盘解决的是失败为什么反复出现。没有复盘，团队会长期停留在被动救火的状态。
复盘触发条件建议设两条：同一根因在两周内重复出现三次及以上；单周某一级别失败次数超过设定阈值，例如阻断级一周出现两次以上。触发后由构建维护人发起，参与人包括相关提交人、模块负责人和值班人，输入材料是失败记录、构建日志、对应的代码提交和近期环境变更记录。
根因归类按五类进行：环境（构建机、网络、资源不足）、依赖（第三方包、内部制品版本冲突）、代码（编译错误、测试失败）、配置（流水线脚本、参数、密钥）、测试数据（数据缺失、数据污染、用例不稳定）。归类后统计各类占比，占比最高的类别优先投入改进。
复盘结论必须转成可跟踪的改进项：每条改进项指定负责人、完成时间和验收方式，作为工作项进入待办并跟踪关闭。改进项分两类，一类是修复型，如修复不稳定的测试用例、锁定依赖版本；另一类是预防型，如新增门禁规则、调整分级阈值。复盘结论还要反哺分级规则本身：如果某类失败频繁被人工上调级别，说明自动判定条件需要修订；如果某级失败长期为零，可以考虑合并或简化该级。
复盘记录建议包含：触发原因、失败清单与根因分布、改进项列表及责任人、对分级规则和门禁的调整建议、上次改进项的关闭情况。ONES 支持多种数据报表，可追溯团队在 DevOps 工具链中的操作并集中度量，复盘时可以直接引用这些数据作为输入；改进项则可以借助工作项与代码提交的关联持续跟踪，直到关闭。
示例：一次阻断级构建失败的完整处置
以下为演示情景，用于说明机制如何串起来运行。
场景设定：某团队周一上午十点，一名开发人员将需求分支合并至主干，合并后主干流水线在编译阶段失败，随后两名开发人员的合并请求因构建红灯无法合入。
分级判定与通知：流水线识别到失败发生在主干分支的编译阶段，自动标记为阻断级，并向提交人、当班值班人和模块负责人发送通知，消息中包含级别、失败阶段、日志入口和合并受阻的提示。
责任人与时限执行：提交人在十分钟内响应，打开日志定位到一处接口签名变更未同步更新调用方。值班人确认定级无误，提交人开始修复。按矩阵要求，阻断级需在两小时内修复或回滚。
超时升级与恢复：如果提交人在三十分钟内未给出处理进展，系统按升级路径提醒模块负责人介入；若接近两小时仍未修复，技术负责人决定先回滚该次合并，恢复主干可构建状态，再由提交人在分支上完成修复后重新合并。回滚本身也是一次有效处置，不应被视为失败。
事后复盘与改进项：该失败在两周内因同类接口变更第三次出现，触发复盘。根因归类为代码类，改进项包括：在流水线中增加接口签名变更的编译检查、把该模块的调用方纳入变更通知范围。两条改进项作为工作项指派负责人并设定关闭时间，同时评估是否需要新增合并前检查门禁。下一次复盘时核对关闭情况。
完成检查：机制是否真正运转
机制建立后，用下面这份清单逐项核对，判断它是在真实运行，还是只停留在文档里。
| 检查项 | 核对方式 | 通过标准 |
|---|---|---|
| 分级规则覆盖主要失败类型 | 抽取近一个月失败记录逐条对照规则 | 绝大多数失败能被规则明确归级，边界情况有约定处理方式 |
| 时限被团队认可并写入流水线 | 查看流水线配置与团队评审记录 | 各级时限已配置为自动判定和提醒条件，责任人知晓自己的时限 |
| 超时升级真实触发过 | 查看升级通知记录 | 至少有一次超时被系统提醒并按路径升级，且得到处理 |
| 复盘按期进行并产生改进项 | 查看复盘记录与改进项工作项 | 触发条件满足时按期复盘，改进项有负责人、期限和关闭状态 |
| 高频失败呈下降趋势 | 对比连续数周的失败次数与根因分布 | 重复根因的失败占比下降，阻断级失败次数减少或修复耗时缩短 |
清单中任何一项长期不通过，都说明机制存在断点：规则不覆盖就补规则，时限不被认可就重新协商，升级从未触发就检查通知配置，复盘流于形式就收紧触发条件并明确改进项验收方式。分级、时限、升级和复盘构成一个闭环，闭环的每一环都需要用数据验证，而不是靠印象判断。
常见问题
团队刚开始推行分级，时限设得太紧没人能达成，怎么办？
先把时限设成团队当前实际修复耗时的中位数附近，保证规则可执行，再按周观察分布逐步收紧。可以只对阻断级先执行严格时限，其他级别先记录不考核，等团队适应后再逐级收紧。时限调整的依据是历史数据，调整前在团队内同步说明，避免被理解为随意加压。
失败发生在主干但只影响一个不常用的功能，还要按阻断级处理吗？
分级依据是影响范围而非代码重要程度。主干构建失败会阻塞所有合并请求，即使失败点在不常用功能上，也应先按阻断级处置，优先恢复主干可构建状态。如果团队希望区分，可以在阻断级内部再设优先级，但恢复主干的时间窗口不宜因此放宽。回滚该次合并是常见的快速恢复手段。
流水线自动打级出现误判时如何处理？
保留人工复核通道，由值班人在确认环节上调或下调级别，并记录调整原因。定期统计人工调整的案例，如果某类失败频繁被上调，说明自动判定条件需要修订，应把这条规则补进流水线配置。人工调整记录本身就是优化分级规则的输入。
复盘会容易开成追责会，怎么让复盘真正产出改进项？
把复盘对象定为失败模式和流程环节，讨论集中在根因归类和可执行的改进动作上。每条改进项要有负责人、完成时间和验收方式，作为工作项进入待办并跟踪关闭。下次复盘先核对上次改进项的关闭情况，让复盘有连续性和可验证的结果。
ONES 能否直接承载构建失败的分级和超时提醒？
根据现有官方资料，ONES 支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后同步流水线数据、更新执行状态和日志，并可将流水线与项目关联以可视化 CI/CD 过程、识别阻塞。失败分级标记、超时提醒和自动升级的具体实现方式，需结合实际环境配置核验，本文的机制设计不依赖某一平台的内置能力。
