构建失败后靠群里喊人，处理人往往落不实、时限也容易被拖过去。更稳妥的做法是把派单和时限写成规则：先按失败类型分层，再按代码归属、模块负责人、值班人顺序锁定处理人，并按阻断程度设定响应与解决时限。本文给出可直接套用的对照表、角色职责和落地检查清单，并说明这些记录如何衔接ONES的流水线与工作项管理。
要点总览（TL;DR）
- 处理人按四级顺序锁定：代码提交人、模块负责人、构建值班人、团队负责人，前一级超时未确认则自动升级到下一级。
- 时限按阻断程度分档：主干编译失败15分钟响应、2小时内给出结论；主干测试失败30分钟响应、4小时内给出结论；非阻断分支失败1个工作日响应、3个工作日内给出结论。
- 响应时限与解决时限分开定义，解决结论可以是修复、回滚、临时豁免或转交，避免把“已回复”当成“已解决”。
- 失败分类依据流水线阶段和日志关键字判定，无法自动分类时由构建值班人兜底初判并转派。
- 规则落地后需定期核对派单准确率、时限达成率和升级有效性，并随团队节奏调整分类规则与值班表。
先给结论：处理人按什么顺序锁定，时限按什么分档
构建失败后的处理人由一条固定的锁定顺序决定，时限由失败对主干和发布的影响程度决定。把这两条规则写进流水线通知和工单字段，每次失败就会自动落到具体的人和截止时间。
处理人锁定顺序分四级：第一级是本次变更的代码提交人，第二级是该代码所属模块的负责人，第三级是当日构建值班人，第四级是团队负责人或构建平台负责人。前一级在响应时限内未确认，自动进入下一级，不依赖人工转派。
时限要区分两个概念。响应时限指处理人确认“我接手了”并给出初步判断的时间；解决时限指给出结论的时间，结论可以是修复完成、回滚、临时豁免或转交他人。两者分开定义，避免把“已回复”当成“已解决”。
下表给出可直接套用的分档建议，团队可结合发布节奏调整数值，但分档逻辑应保持稳定。
| 失败类型 | 典型影响 | 首要处理人 | 响应时限 | 解决时限 |
|---|---|---|---|---|
| 主干编译或静态检查失败 | 阻断所有下游构建与合入 | 代码提交人 | 15分钟 | 2小时内给出结论 |
| 主干单元或集成测试失败 | 阻断主干质量门禁 | 代码提交人，测试负责人协同 | 30分钟 | 4小时内给出结论 |
| 环境、依赖与资源类失败 | 可能阻断多条流水线 | 构建平台值班人 | 15分钟 | 2小时内恢复或给出绕行方案 |
| 流水线配置与脚本失败 | 影响该流水线全部构建 | 流水线维护人 | 1个工作日 | 2个工作日内修复 |
| 非阻断分支构建失败 | 不影响主干与发布 | 分支提交人 | 1个工作日 | 3个工作日内给出结论 |
表中“给出结论”包含修复、回滚、标记已知问题并挂接后续任务等处理方式，不要求每次都在时限内完成代码修复。这样设定是为了让失败在时限内有人负责、有明确去向，避免长期悬空。
第一步：把构建失败分成可派单的几类
派单的前提是知道失败属于哪一类，因为不同类别对应的处理人范围不同。分类依据主要看流水线失败发生在哪个阶段，以及日志中的关键信息。
编译与静态检查失败
失败发生在编译、打包或静态扫描阶段，日志中出现编译错误、语法错误、依赖解析失败、代码规范告警超阈值等信息。这类失败通常由最近一次提交直接引起，处理人范围最窄，优先指向提交人。
单元测试与集成测试失败
失败发生在测试执行阶段，日志中有断言失败、用例超时、测试环境连接失败等记录。需要区分是用例本身的问题还是被测代码的问题：用例近期被修改且与失败用例相关，测试负责人参与判定；否则仍以代码提交人为主责。
环境、依赖与资源类失败
表现为构建节点失联、镜像拉取失败、依赖仓库不可达、磁盘或内存不足、许可证服务异常等。这类失败与业务代码无关，处理人应指向构建平台侧的值班人，同时通知受影响流水线的负责人。
流水线配置与脚本失败
失败出现在流水线定义文件、构建脚本、凭证配置等环节，日志中常见配置解析错误、变量未定义、权限不足。处理人是流水线维护人，若变更来自某次提交，则由该提交人与维护人共同确认。
无法自动判定的失败如何兜底
日志信息不足、失败原因跨多个阶段或首次出现时，规则应设置兜底：先派给当日构建值班人，由其在一个响应时限内完成初判并转派给正确责任人。兜底不等于无人负责，值班人承担初判和转派的交付物。
分类规则建议以配置形式维护，用日志关键字和阶段位置作为判定条件，并保留人工改判入口。分类准确率会随规则迭代提升，初期允许一定比例的人工修正。
第二步：用代码归属和值班表确定处理人
从一条失败记录到具体的人，需要三类信息：这次构建包含哪些提交、这些提交涉及哪些代码目录、这些目录对应哪位负责人。把这三类信息固化为字段，派单才能自动完成。
从提交记录、代码库目录、模块清单取归属信息
流水线触发时记录本次构建的提交列表和变更文件路径；代码库按目录划分模块，模块清单维护每个目录的负责人和备份负责人；值班表按日期维护构建值班人。三者关联后，系统即可输出候选处理人。
值班表与轮值规则的设计要点
值班表按周或按日轮换，明确值班时段、交接时间和替补人。值班人负责环境类失败的处置和无法自动判定失败的初判，不替代模块负责人对业务代码负责。值班表应提前发布，避免临时找人。
跨模块失败和多人提交时的主责判定
一次构建包含多个模块的提交时，按变更文件与失败日志的关联度确定主责：失败堆栈或报错指向哪个模块，就由该模块负责人主责，其他提交人作为协同人。无法区分时，由提交次数最多或变更范围最大的模块负责人主责，并在处理记录中写明判定依据。
环境类失败的平台侧责任人
环境、依赖和资源类失败统一由构建平台值班人主责，受影响流水线的模块负责人作为知会对象。平台侧修复后需在处理记录中注明影响范围和恢复时间，便于后续统计。
处理人映射所需字段清单如下：构建编号、触发分支、提交列表、变更文件路径、模块名称、模块负责人、备份负责人、构建值班人、失败分类、主责人、协同人、判定依据。字段齐全后，派单结果可复核、可追溯。
第三步：设定反馈时限与升级路径
时限只有落到具体时间点才有约束力。建议在失败记录上直接写入响应截止时间和解决截止时间，而不是只写“尽快处理”。
响应、首次反馈、解决三档时限的定义
响应指处理人确认接单；首次反馈指给出初步判断，说明失败原因方向和预计处理方式；解决指给出结论，包括修复、回滚、豁免或转交。三档时限依次放宽，响应最紧，解决最宽。
按阻断程度分档的时限建议
阻断主干构建的失败按分钟级响应、小时级解决；阻断单条流水线但不影响主干的失败按小时级响应、工作日级解决；非阻断分支失败按工作日级响应和解决。具体数值参考第一节对照表，团队可根据构建频率和发布窗口微调。
超时未响应的自动升级对象与方式
响应超时后，失败记录自动升级到模块负责人；模块负责人仍未响应，升级到构建值班人和团队负责人；解决时限超时，升级到团队负责人并进入周度复盘清单。升级动作应自动触发，并在失败记录中留下升级时间和对象。
夜间与非工作时间的时限处理
非工作时间的时限可以顺延，但需要明确规则：阻断主干的失败在发布窗口内仍按原时限执行，其余失败顺延至下一个工作时段开始计时。顺延规则要写入通知内容，让处理人清楚截止时间。
升级路径可以概括为：提交人 → 模块负责人 → 构建值班人 → 团队负责人。每一级都有对应的触发条件和时限，升级不是惩罚，而是保证失败在约定时间内有人接手。
角色与交付物：谁在什么时点做什么
规则能否执行，取决于每个角色是否清楚自己在什么时点交付什么。下表按角色汇总职责与交付物。
| 角色 | 主要职责 | 关键时点 | 交付物 |
|---|---|---|---|
| 代码提交人 | 确认失败是否由本次提交引起，给出修复或回滚方案 | 响应时限内确认，解决时限内给出结论 | 失败原因说明、修复提交或回滚记录 |
| 模块负责人 | 判定主责归属，协调跨模块问题，超时后接手 | 提交人未响应时、跨模块失败时 | 主责判定记录、协调结论 |
| 构建值班人 | 处置环境类失败，初判无法自动分类的失败并转派 | 环境类失败发生时、兜底失败发生时 | 初判记录、转派记录、环境恢复说明 |
| 构建平台负责人 | 维护分类规则、值班表和升级配置，统计时限达成情况 | 每周或每个迭代 | 规则变更记录、时限达成报表 |
| 团队负责人 | 处理升级事项，主持复盘，调整规则 | 升级触发时、复盘会上 | 升级处理结论、复盘记录 |
失败记录、处理结论和复盘记录需要留存。失败记录至少包含构建编号、失败分类、主责人、时限和升级历史；处理结论写明原因和处理方式；复盘记录针对重复失败或超时失败，记录改进动作和责任人。留存周期可与迭代周期对齐，便于统计和追溯。
在工具层面，构建失败记录需要能落到具体工作项上，并携带处理人和截止时间字段。ONES 可集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，同时在项目、迭代、需求中可视化代码提交与流水线构建过程。团队可以据此把失败记录关联到对应工作项，让派单结果和时限跟踪与需求交付过程放在同一处查看。具体的自动派单和时限字段配置需按团队实际集成情况核验。
示例：一次主干构建失败的完整处理过程
以下为演示情景，用于说明规则如何串联，时间点为示意。
10:02 失败发生。主干分支构建在编译阶段失败，流水线记录构建编号、提交列表和变更文件路径，分类规则依据日志中的编译错误判定为“编译失败”，主责人锁定为最近一次提交的提交人，响应截止时间10:17，解决截止时间12:02。通知内容包含失败阶段、报错摘要、主责人、截止时间和升级路径。
10:08 处理人确认。提交人确认接单，查看日志后判断是接口签名变更未同步调用方，给出首次反馈：预计30分钟内提交修复。
10:31 修复提交。提交人推送修复，流水线重新触发并构建通过。处理人在失败记录中写明原因和处理方式，状态改为已解决。
超时升级的实际触发。若该提交人未在10:17前确认，记录自动升级到模块负责人；模块负责人10:25仍未响应，升级到构建值班人和团队负责人，团队负责人协调后指定他人接手，升级时间和对象写入记录。
关闭与记录。构建通过后关闭失败记录，保留失败分类、主责人、响应时间、解决时间和升级历史。若同类失败一周内出现三次，进入复盘清单，由构建平台负责人分析分类规则或代码规范是否需要调整。
完成检查：规则是否真的落地
规则建立后需要定期核对运行效果，以下清单可逐项打勾。
- 派单准确率：抽查最近两周的失败记录，主责人判定与实际原因一致的比例是否达到团队约定目标。
- 无人认领失败数量：统计响应时限内无确认记录的失败数，是否为零或已全部进入升级流程。
- 响应时限达成率：按失败类型分别统计，阻断主干类是否达到约定比例。
- 解决时限达成率：区分修复、回滚、豁免等结论类型，检查是否存在长期挂起未关闭的记录。
- 升级触发有效性：抽查升级记录，确认升级对象正确、升级后有人接手并给出结论。
- 分类规则维护：检查分类规则最近一次更新时间，新增失败类型是否已纳入规则。
- 值班表完整性：确认未来两周值班表已发布，替补人明确。
- 复盘闭环：重复失败和超时失败是否都有复盘记录，改进动作是否有责任人和完成时间。
检查频率建议与迭代节奏一致，由构建平台负责人汇总结果，团队负责人在复盘会上确认改进项。规则本身也应随团队规模和发布节奏调整，调整后同步更新通知模板和字段配置，保证派单与时限始终可执行。
常见问题
构建失败后提交人已经离职或长期不在岗，处理人怎么定？
派单规则需要为每个模块维护备份负责人。当提交人无法响应时，响应时限到期后自动升级到模块负责人；模块负责人可指定备份负责人接手，并在失败记录中更新主责人。若模块负责人也长期空缺，则由构建值班人临时承接初判，团队负责人协调确定新的负责人并更新模块清单。
夜间或节假日发生的构建失败，时限要不要顺延？
可以顺延，但需要区分场景。阻断主干且处于发布窗口内的失败，按原时限执行，不因非工作时间顺延；其余失败顺延至下一个工作时段开始计时。顺延规则应写入通知内容，让处理人看到明确的截止时间，避免因默认顺延导致主干长时间不可用。
一次构建包含多个模块的提交，失败日志指向不明确时如何判定主责？
先看失败堆栈或报错信息与哪个模块的变更文件关联最直接，关联明确的由该模块负责人主责。无法区分时，按提交次数最多或变更范围最大的模块负责人主责，其他提交人作为协同人。判定依据要写入处理记录，便于后续复核和规则优化。
环境类失败和业务代码失败同时出现，应该先派给谁？
环境、依赖与资源类失败统一由构建平台值班人主责，因为这类失败可能影响多条流水线，优先恢复环境才能让后续构建继续验证。业务代码失败在环境恢复后重新触发构建再判定；若环境问题由某次提交的配置变更引起，则由该提交人与平台值班人共同确认。
规则运行一段时间后派单准确率不高，应该调整什么？
优先检查分类规则的判定条件是否覆盖了新增的失败类型，日志关键字和阶段位置是否需要补充；其次检查模块清单中的负责人和目录映射是否随代码结构调整而更新；最后看值班表交接是否清晰。建议按迭代周期抽查失败记录，把误判案例转化为规则调整项，由构建平台负责人维护并同步通知模板。
