发布异常处理指围绕一次发布活动，从发布前风险识别、发布中异常发现与判定，到发布后回滚、修复与复盘的全过程处置，范围限定在“由发布动作引发或暴露”的异常。它与一般服务事件响应的关键区别在于：前者要判断继续、暂停还是回滚，后者以恢复服务和止损为核心。
要点总览（TL;DR）
- 发布异常处理的范围限定在由发布动作引发或暴露的异常，覆盖发布前风险识别、发布中异常判定、发布后回滚或修复与复盘。
- 纳入范围包括发布后的功能异常、性能退化、配置错误、数据不一致、依赖不兼容，以及灰度与分批发布中暴露的问题；与发布无关的容量故障、第三方中断、安全攻击不纳入。
- 发布异常处理的核心决策是继续、暂停还是回滚，决策依据是影响范围、根因清晰度和修复所需时间，回滚授权在发布前约定。
- 与一般服务事件响应的主要差异在触发来源、处置目标、时间窗口和决策权：前者围绕一次发布活动，后者面向服务运行中的各类故障，以恢复服务和止损为目标。
- 发布引发的严重故障会同时进入两条流程：回滚是恢复手段之一，事件关闭以服务恢复和影响消除为准，不以回滚完成为准。
发布异常处理的直接定义
发布异常处理，是在一次明确的发布活动范围内，对由发布动作引发或暴露的异常进行识别、判定、处置和收尾的管理过程。它关注的不是所有线上问题，而是与“这次发布”有因果或时间关联的问题，并围绕这些问题做出继续发布、暂停发布、回滚版本或修复后重发等决策。
这个定义包含三个要素。第一是发布活动，即一次有明确版本、范围、时间窗口和负责人的变更交付，它构成处置的对象边界。第二是异常，包括功能不符合预期、性能退化、配置错误、数据不一致、依赖不兼容等可观察的偏差。第三是处置动作，涵盖发现、影响判定、决策、执行回滚或修复、验证以及复盘归档，形成从发现到收尾的闭环。
发布异常处理与发布流程、变更管理的关系可以这样理解：发布流程规定一次发布如何准备、审批、执行和验证；变更管理关注变更是否被评估、授权和记录；发布异常处理则是发布流程中异常分支的处置机制，它依赖发布流程提供的版本信息、发布单和观察指标，也依赖变更管理提供的授权与记录规则。三者共享同一套发布对象和责任人，但回答的问题不同：发布流程回答“怎么发”，变更管理回答“能不能发、谁批准”，发布异常处理回答“发出去出了问题怎么办”。
范围边界：哪些异常属于发布异常处理
判断一个异常是否属于发布异常处理，核心看它是否由本次发布动作引发或暴露，以及是否需要在发布窗口内做出继续、暂停或回滚的决策。以下清单按纳入与不纳入两类整理。
| 类别 | 典型情形 | 判断要点 |
|---|---|---|
| 纳入 | 发布后功能异常，如接口返回错误、页面功能不可用 | 异常出现在发布后，且与本次变更内容相关 |
| 纳入 | 性能退化，如响应时间上升、错误率升高 | 发布前后指标出现可对比的恶化 |
| 纳入 | 配置错误，如开关、参数、路由配置与预期不符 | 配置随本次发布变更并可回退 |
| 纳入 | 数据不一致，如迁移脚本导致字段或记录异常 | 数据变更由本次发布引入 |
| 纳入 | 依赖不兼容，如新版本与下游服务或中间件不匹配 | 兼容问题在本次发布后暴露 |
| 纳入 | 灰度与分批发布中暴露的问题 | 问题出现在部分批次或部分流量，尚未全量扩散 |
| 不纳入 | 与发布无关的容量故障 | 流量自然增长或资源不足导致，发布前后无关联变化 |
| 不纳入 | 第三方依赖中断 | 外部服务自身故障，发布动作未改变依赖关系 |
| 不纳入 | 安全攻击 | 攻击行为导致，需按安全事件流程处理 |
| 不纳入 | 底层部署命令与脚本教程 | 属于操作技能，不属于异常处置范围 |
边界模糊时，可以用三个问题判定。第一，异常是否在发布时间窗口内出现，或是否在发布后短时间内被观察到。第二，异常是否与本次变更的代码、配置、数据或依赖存在可追溯的关联。第三，处置动作是否需要在“继续发布、暂停发布、回滚、修复后重发”之间做选择。三个问题中若前两个成立、第三个也需要回答，通常应纳入发布异常处理；若异常与发布无关联，或处置目标已经转为恢复线上服务，则应转入一般服务事件响应。
灰度与分批发布是容易混淆的场景。灰度阶段暴露的问题，因为尚未全量，处置空间更大，通常优先暂停放量、定位问题、决定回滚或修复后继续。这类问题属于发布异常处理的典型范围。若灰度问题已经造成大范围用户不可用，处置目标转为尽快恢复服务，则同时进入事件响应，两条流程并行。
发布异常处理的组成环节与决策点
发布异常处理按时间顺序分为发布前、发布中和发布后三个阶段，每个阶段有明确的输入、动作、交接物和决策点。
发布前：把风险清单和回滚预案准备好
发布前需要产出风险清单、回滚预案和观察指标。风险清单列出本次变更涉及的功能、配置、数据和依赖，标注高风险项；回滚预案说明回滚条件、回滚步骤、回滚授权人和回滚后的验证方式；观察指标明确发布后看哪些指标、看多久、阈值是多少。这一阶段的交接物是发布单中的风险与回滚章节，责任人是发布负责人，评审人是技术负责人或变更审批人。
发布中：发现异常并做出继续或暂停决策
发布中按批次或灰度比例推进，同时观察指标。发现异常后，先做影响判定：影响范围是部分流量还是全量，影响程度是功能不可用还是体验下降，是否涉及数据错误。影响判定完成后，发布负责人依据回滚预案中的条件做出决策：继续发布、暂停放量、回滚已发布批次，或修复后重发。这一阶段的关键交接物是异常记录，记录异常现象、影响范围、判定依据和决策结果，便于后续复盘。
发布后：回滚执行、修复验证与复盘归档
发布后的处置分两条路径。回滚路径适用于异常影响较大、根因尚不明确或修复时间不可控的情况，动作包括执行回滚、验证回滚后指标恢复、确认数据一致性。修复路径适用于根因明确、修复范围可控的情况，动作包括提交修复、重新验证、按原计划或调整后的计划重发。两条路径的选择依据是影响程度、根因清晰度和修复所需时间：影响面大且根因不明时优先回滚，影响可控且修复路径清楚时可以选择修复后重发。
无论走哪条路径，收尾都需要复盘归档，记录异常现象、时间线、决策过程、处置结果和改进项。复盘文档是这一环节的主要交接物，责任人是发布负责人，参与人包括开发、测试和运维。在实际协作中，发布单、异常记录和复盘文档需要有统一的承载位置和状态流转，ONES 可以在发布管理场景中承载发布单、异常记录与复盘文档，让风险清单、回滚决策和复盘结论沿同一工作项留痕，便于交接和追溯。
与一般服务事件响应的区别
发布异常处理与一般服务事件响应都涉及线上异常，但两者回答的问题不同。用同一组口径对照，可以看清差异所在。
| 对照维度 | 发布异常处理 | 一般服务事件响应 |
|---|---|---|
| 触发来源 | 由发布动作引发或暴露的异常 | 服务运行中的各类故障与中断，起因可能是容量、依赖、数据、安全等 |
| 处置目标 | 判断继续、暂停还是回滚，控制发布风险 | 尽快恢复服务、止损，降低对用户的影响 |
| 时间窗口 | 集中在发布窗口及发布后观察期 | 全天候响应，按事件等级组织 |
| 决策权与流程 | 发布负责人依据回滚预案决策，回滚授权在发布前约定 | 事件指挥统一协调，按升级机制调动资源 |
| 收尾与复盘 | 回滚或修复验证后复盘发布过程，改进发布预案 | 服务恢复后复盘事件根因，改进监控与应急预案 |
触发来源的差异决定了两者的起点不同。发布异常处理的起点是一次具体的发布活动，异常需要与本次变更建立关联；服务事件响应的起点是服务状态偏离正常，起因可能来自容量增长、第三方依赖中断、数据异常或安全攻击，与某次发布未必相关。
处置目标的差异决定了两者的决策逻辑不同。发布异常处理的核心决策是继续、暂停还是回滚，决策依据是影响范围和回滚预案；服务事件响应的核心决策是恢复服务与止损，决策依据是事件等级和影响面，恢复手段可以是切换、限流、扩容或回滚。
时间窗口和决策权的差异影响组织方式。发布异常处理集中在发布窗口和观察期内，决策权相对集中，发布负责人依据事先约定的回滚条件行事；服务事件响应需要全天候值守，按事件等级启动响应，由事件指挥协调多个团队，并按升级机制逐级上报。
交叉情形需要特别说明。发布引发的严重故障，例如发布后核心功能大面积不可用，既属于发布异常处理，也应同时进入服务事件响应：一方面由发布负责人执行回滚或暂停，另一方面按事件等级启动响应、恢复服务、对外沟通。两条流程并行时，回滚是恢复手段之一，事件关闭以服务恢复和影响消除为准，不以回滚完成为准。
具体例子与常见误解
下面用一个完整示例说明发布异常处理的边界。某服务计划发布新版本，发布单中列明本次变更涉及订单查询接口和一项缓存配置，回滚预案约定错误率超过阈值即回滚。发布按 10% 灰度放量，观察期内发现订单查询错误率上升，影响部分灰度用户。发布负责人判定影响范围限于灰度流量、根因尚不明确，决定暂停放量并回滚灰度批次。回滚后指标恢复，团队定位到缓存配置与旧版本不兼容，修复配置后重新按灰度发布，验证通过后全量。整个过程记录了异常现象、影响判定、回滚决策和复盘结论，属于典型的发布异常处理。
反例是一个与发布无关的服务事件。某服务在凌晨出现数据库连接耗尽，导致部分请求失败，当天没有发布活动。值班团队按事件等级启动响应，通过扩容连接池和限流恢复服务，事后复盘定位为连接泄漏。这个事件属于一般服务事件响应，起因与发布无关，处置目标是恢复服务，不走发布异常处理的继续、暂停或回滚决策。
常见误解有三个。第一，把所有线上故障都归为发布异常。判断依据是异常与发布动作是否存在可追溯关联，无关联的故障应按服务事件响应处理。第二，把回滚等同于事件关闭。回滚只是恢复手段之一，服务是否恢复、影响是否消除、用户是否恢复正常，才是事件关闭的依据；发布异常处理的收尾还包括修复验证和复盘归档。第三，认为发布异常处理只在发布当天。发布后的观察期内暴露的问题仍属于发布异常处理范围，观察期的长度应在发布前约定，并与异常的影响程度相匹配。
常见问题
发布后观察期内才暴露的问题，还算发布异常处理吗？
算。发布异常处理的时间范围包括发布窗口和发布后的观察期，观察期长度应在发布前约定，并与本次变更的影响程度相匹配。只要异常与本次发布存在可追溯关联，即使出现在发布当天之后，仍按发布异常处理，走影响判定、回滚或修复、验证和复盘归档的路径。
如果观察期结束后才出现、且无法与本次变更建立关联的故障，则按一般服务事件响应处理。
发布引发的严重故障，应该走发布异常处理还是事件响应？
两条流程并行。发布负责人依据回滚预案执行暂停或回滚，控制发布风险；同时按事件等级启动服务事件响应，由事件指挥协调恢复服务、对外沟通和升级上报。回滚是恢复手段之一，事件关闭以服务恢复和影响消除为准，不以回滚完成为准。事后复盘可以合并进行，分别改进发布预案和应急预案。
回滚预案应该在什么时候准备，需要包含哪些内容？
回滚预案在发布前准备，作为发布单的一部分经过评审。内容至少包括：回滚触发条件（如错误率、响应时间阈值）、回滚步骤与执行人、回滚授权人、回滚后的验证方式，以及数据变更是否可逆的说明。触发条件写得越具体，发布中的决策越少依赖临场判断。
涉及数据迁移的发布，还需在预案中说明回滚后数据一致性的处理方式。
灰度阶段发现问题，应该先暂停放量还是直接回滚？
取决于影响范围和根因清晰度。影响限于灰度流量、根因尚不明确时，通常先暂停放量，阻断影响扩散，再定位问题；根因明确且修复范围可控时，可以修复后继续灰度。若灰度问题已造成大范围用户不可用，处置目标转为尽快恢复服务，应直接回滚并同时启动事件响应。
发布异常处理的复盘和服务事件复盘有什么不同？
发布异常处理的复盘聚焦发布过程本身：风险清单是否遗漏、观察指标是否合理、回滚决策是否及时、预案是否需要修订，改进项落到发布流程和预案上。服务事件复盘聚焦故障根因：监控是否覆盖、应急手段是否有效、升级机制是否顺畅，改进项落到监控和应急预案上。发布引发的严重故障，两类复盘可以共用同一份时间线记录，但改进项分别归属。
