流水线异常协调要解决的是失败发生后无人定级、无人跟进、修完也不确认的问题。本文给出一套可直接落地的机制：先按影响范围和阻断程度分级，再把发现、判断、处置、验证、升级分到具体角色，最后用检查清单确认机制能跑起来。核心产物包括异常分级表、分步处置流程、角色交付物对照表、升级路径和完成检查清单。处置单与状态流转可以放在ONES中承载，便于记录责任人和复跑结果。
要点总览（TL;DR）
- 先按影响范围、是否阻断发布、是否可自愈三个维度把异常分为P1至P4四级，并为每级设定响应时限和通知对象，避免所有失败走同一套流程。
- 处置按发现登记、初步定级、分派模块负责人、定位修复、复跑验证五步推进，每步写明输入、动作、输出和完成标志，交接不靠口头转述。
- 值班人负责登记与跟进时限，模块负责人负责定位修复，环境负责人处置基础设施问题，发布负责人判断是否阻断发布，技术负责人负责超时裁决与跨团队拉通。
- 超过响应时限未定位、影响主干、连续多次失败或涉及跨团队依赖时按层级升级，所有沟通围绕唯一处置单进行，聊天工具只发通知和结论。
- 用检查清单核对机制是否可运行：无责任人、无时限、无复跑验证任一项出现，即视为机制未完成，需先补齐再运行。
先定异常分级与触发条件
分级的目的在于把响应资源放到正确的位置：主干被阻断和单分支偶发失败，需要不同的响应速度和通知范围。分级标准要写进团队可见的文档，避免值班人凭感觉判断。
异常触发来源通常包括五类：构建失败、测试失败、部署卡住、环境不可用、外部依赖超时。触发之后，按三个维度判断级别：影响范围是单分支、多分支还是主干；是否阻断当日发布；是否具备自愈条件（例如重试后恢复、依赖方已公告恢复时间）。
| 级别 | 判定条件 | 响应时限 | 通知对象 |
|---|---|---|---|
| P1 紧急 | 主干构建或部署失败，阻断当日发布；或多分支同时失败且原因不明 | 15分钟内响应，1小时内给出定位结论或升级 | 值班人、模块负责人、发布负责人、技术负责人 |
| P2 高 | 单分支失败但影响发布候选版本；或环境不可用导致多人无法验证 | 30分钟内响应，4小时内处置或升级 | 值班人、模块负责人、环境负责人 |
| P3 一般 | 单分支失败，不影响当日发布，可绕行 | 当个工作日内响应 | 值班人、提交人 |
| P4 观察 | 外部依赖超时、偶发失败，重试后可恢复 | 记录并跟踪，不单独占用处置资源 | 值班人记录，周会同步 |
有几类情况跳过常规排查直接升级：主干失败且15分钟内无法判断原因；同一流水线连续三次失败；失败涉及跨团队依赖且对方未响应；环境故障影响多个团队。直接升级意味着通知上一级责任人和相关团队负责人，同时保留处置单继续记录。
核心处置步骤：从发现到复跑验证
处置流程的价值在于每一步都有明确的输入、动作、输出和完成标志，交接时不靠口头转述。以下五步适用于P1至P3异常，P4按记录跟踪处理。
第一步：发现与登记
输入是流水线告警或人工发现的失败。动作是创建处置单，记录流水线编号、触发提交、失败阶段、报错摘要和首次发现时间。输出是一张信息完整的处置单。完成标志是处置单已创建并关联到对应流水线和提交。
第二步：初步定级与信息补全
输入是处置单。动作是核对是否为重复失败（同一提交或同一错误近期是否出现过）、是否影响主干、是否阻断发布，据此套用分级表确定级别和响应时限。输出是定级结果和通知记录。完成标志是级别、时限、通知对象三项均已填写，相关人员已收到通知。
第三步：分派到模块负责人
输入是定级后的处置单。动作是根据失败阶段和报错内容判断归属模块，指派模块负责人或最近提交人，明确其负责给出定位结论。输出是责任人和判断时限。完成标志是责任人已确认接单，处置单状态变为“处理中”。
第四步：定位与处置
输入是处置单和责任人。动作是先归类再修复：代码缺陷交由提交人修改并补充测试；配置错误核对流水线配置与最近变更记录；环境问题转环境负责人检查资源、凭据和网络；外部依赖问题联系依赖方并评估绕行方案。输出是原因分类和修复记录。完成标志是修复已提交，处置单中写明原因类别和修复内容。
第五步：复跑验证与关闭
输入是修复后的提交。动作是重新触发流水线，确认失败阶段通过、后续阶段正常执行。输出是复跑结果记录。完成标志是流水线全流程通过，处置单由发现人或值班人确认关闭，而非由修复人自行关闭。
角色分工与交付物
分工的关键是每个角色只对一件事负责，并且有对应的交付物可以核对。下表列出常见角色及其边界。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 值班人或流水线负责人 | 发现异常、登记处置单、初步定级、跟进响应时限 | 处置单（含定级与时间记录） |
| 模块负责人或提交人 | 定位失败原因、完成修复、提交复跑 | 修复记录（原因类别、修改内容、提交号） |
| 环境或平台负责人 | 处置环境不可用、资源不足、凭据失效等基础设施类异常 | 环境处置记录与恢复确认 |
| 发布负责人 | 判断异常是否阻断发布，决定延期或带条件发布 | 发布决策记录 |
| 协调人或技术负责人 | 超时未定位时裁决、跨团队拉通、决定是否降级或升级 | 升级裁决记录 |
复盘记录由值班人在异常关闭后牵头整理，内容包括时间线、原因分类、处置耗时和改进项。改进项要指定负责人和完成时间，否则复盘只停留在描述层面。
这些记录如果分散在聊天工具和邮件里，追溯成本很高。把处置单作为工作项放在ONES中，可以让责任人、状态、复跑结果和复盘改进项挂在同一条记录上，交接和统计都从这一处取数。
升级路径与沟通机制
升级不是失败，而是机制的一部分。写清升级条件和层级，值班人才能在时限到达时果断上报，而不是继续等待。
升级触发条件包括：超过响应时限仍未给出定位结论；影响主干或阻断发布；同一流水线连续多次失败；问题涉及跨团队依赖且对方未在约定时间内响应。升级层级一般为：模块负责人→技术负责人→发布负责人与相关团队负责人。每一级都设定等待时限，例如P1异常在1小时未定位即升至技术负责人。
同步信息建议统一格式，一条异常消息包含以下字段：处置单编号、流水线名称与编号、触发提交、失败阶段、报错摘要、当前级别、责任人、已尝试的处置、下次同步时间。所有沟通围绕处置单进行，聊天工具只发通知和结论，详细过程写回处置单，避免多头询问同一问题。
示例：一次主干构建失败的协调过程
以下为演示情景，用于说明规则如何串联，时间与角色可按团队实际调整。
10:05，主干分支构建在单元测试阶段失败，值班人收到告警，创建处置单，记录流水线编号、提交号和报错摘要。10:10，值班人核对发现该提交涉及支付模块，且当日有发布计划，按分级表定为P1，通知模块负责人和发布负责人，响应时限15分钟、定位时限1小时。
10:20，模块负责人接单，查看报错为测试用例断言失败，对比最近变更记录发现依赖版本被升级。10:40，确认为配置错误而非代码缺陷，回退依赖版本并提交修复。10:50，值班人触发复跑，测试阶段通过，后续部署阶段正常完成。11:00，发布负责人确认发布可按原计划进行，处置单关闭。
次日复盘记录：从发现到关闭共55分钟，原因类别为配置错误，改进项为在流水线中加入依赖版本变更的提示检查，负责人为平台负责人，完成时间定于本周内。改进项作为独立工作项跟踪，下次复盘时核对完成情况。
完成检查清单
以下清单用于判断异常协调机制是否具备运行条件，逐项核对，任一项不满足即需补齐。
- 分级表覆盖构建失败、测试失败、部署卡住、环境不可用、外部依赖超时五类来源，且每级有明确响应时限和通知对象。
- 每个异常有唯一处置单，单内包含流水线编号、提交、失败阶段、报错摘要、级别和责任人。
- 升级条件已写入文档，团队成员知晓在什么时限、向谁升级。
- 复跑验证是关闭处置单的前置条件，关闭动作由发现人或值班人执行。
- 复盘记录包含时间线、原因分类和改进项，改进项有负责人和完成时间并可跟踪。
- 阻断项：出现无责任人、无时限、无复跑验证中任一情况，视为机制未完成，需先补齐再运行。
常见问题
小团队人少，值班人和模块负责人常常是同一个人，这套分工还能用吗？
可以用，但要把职责分开记录，而不是合并成一个人凭记忆处理。同一个人既发现又修复时，处置单里仍要分别填写定级时间、接单时间、修复提交和复跑结果，这样复盘时才能看出时间花在哪一步。建议至少保留一条独立验证：修复人完成修改后，由另一位同事或发布负责人确认复跑通过再关闭处置单，避免自己修自己关。
外部依赖方故障导致的流水线失败，应该算我们的异常吗？
算，但处置方式不同。外部依赖超时或服务不可用通常定为P4观察级，值班人记录依赖方名称、影响范围和对方公告的恢复时间，并评估是否存在绕行方案。如果该依赖阻断了主干或当日发布，则按P1或P2处理，同时联系依赖方并在处置单中记录沟通结果。关键是把等待时间写进记录，避免异常长期挂着无人跟进。
复跑通过后，是否还需要保留处置单？
需要保留。处置单是后续复盘和统计的数据来源，关闭只是状态变化。建议保留流水线编号、触发提交、失败阶段、原因分类、处置耗时和复跑结果，按月汇总可以看出发失败集中在哪些阶段、哪类原因反复出现。如果团队使用ONES承载处置单，这些字段可以直接作为工作项属性用于筛选和统计。
升级之后原责任人还要继续处理吗？
要继续。升级改变的是信息同步范围和裁决层级，不转移定位与修复责任。升级时原责任人应在处置单中写明已尝试的处置、当前判断和卡点，接手的技术负责人或相关团队负责人据此裁决是继续排查、调整方案还是降级处理。裁决结论写回处置单，避免升级后出现两套并行的处理动作。
分级表中的响应时限怎么定才合理？
时限要结合团队的值班安排和发布节奏来定，先保证能执行再逐步收紧。可以从现有异常的实际处置耗时入手，取一个团队大多数情况能达到的值作为初版时限，运行一个月后按超时记录调整。P1的定位时限通常最短，因为它直接阻断发布；P3、P4可以放宽到工作日或按周跟踪。时限一旦写入分级表，就要和通知对象、升级条件一起对团队公布。
