回滚触发条件要写成可观测、可判定、有责任人的规则：先约定发布窗口内看哪些指标、达到什么阈值，再区分“立即回滚”“暂停放量观察”“继续发布”三档，并把判定权、决策时限和回滚后的动作一并写清。本文用一份假设的电商订单服务发布示例，展示触发条件表如何填写、每条规则为什么这样定，以及换到其他系统时需要调整哪些部分。文中阈值均为示例数据，需按自身监控基线与历史发布情况校准。
要点总览（TL;DR）
- 回滚触发条件要写成可观测、可判定、有责任人的规则：明确指标、阈值、观测窗口、判定级别、责任人与决策时限。
- 示例按错误率、延迟、业务成功率、数据异常、依赖告警五类指标分组，区分“立即回滚”“暂停放量观察”两档处置。
- 阈值和窗口需按自身监控基线与历史发布数据校准，示例数值仅用于说明填写格式。
- 迁移时先反推阈值，再按变更影响面确定观测窗口，并把条件写入发布检查单与发布评审。
- 不可回滚的变更、灰度与全量的判定差异、一般服务事件需要区别处理，不能直接照搬示例表。
示例目标：这份回滚触发条件要解决什么问题
先交代示例背景。以下场景为假设情景，用于演示填写方法，不代表任何真实客户案例或实测结果。
假设某电商平台的订单服务发布一个新版本，变更范围包括订单创建接口的校验逻辑调整和优惠券抵扣计算的重构。发布方式为先灰度10%流量，观察30分钟后逐步放量至全量。本次发布安排在交易低谷期，观测窗口从首批灰度实例接入流量开始，持续到全量发布后2小时。
这份触发条件表要解决的核心问题是：发布过程中和发布后，出现什么信号时应当回滚、什么信号只需暂停观察、什么信号可以继续放量，以及每个判断由谁在多长时间内做出。把这三个问题提前写死，可以避免出事时临时争论“算不算严重”“要不要再等等”。
| 项目 | 示例设定 |
|---|---|
| 发布对象 | 订单服务新版本（假设） |
| 变更内容 | 订单创建校验逻辑调整、优惠券抵扣计算重构 |
| 发布方式 | 灰度10%流量，观察30分钟后逐步放量 |
| 观测窗口 | 首批灰度接入起，至全量发布后2小时 |
| 判定目标 | 明确何时回滚、何时暂停观察、由谁在多长时间内判定 |
完整示例：订单服务发布的回滚触发条件表
下表是填写完成的示例。每条条件包含指标、阈值、观测窗口、判定级别、责任人与决策时限，以及对应的执行动作。表中数值均为示例，用于说明填写格式和判断逻辑。
| 指标类别 | 具体指标 | 阈值（示例） | 观测窗口 | 判定级别 | 责任人 | 决策时限 | 执行动作 |
|---|---|---|---|---|---|---|---|
| 错误率 | 订单创建接口5xx错误率 | 连续5分钟高于2% | 5分钟滑动窗口 | 立即回滚 | 发布值班负责人 | 确认后10分钟内启动 | 停止放量，回滚至上一稳定版本，通知业务方 |
| 错误率 | 订单创建接口5xx错误率 | 5分钟内处于1%–2%之间 | 5分钟滑动窗口 | 暂停放量观察 | 发布值班负责人 | 15分钟内给出结论 | 冻结当前灰度比例，加密监控，排查原因 |
| 延迟 | 订单创建接口P99响应时间 | 连续10分钟超过800ms | 10分钟滑动窗口 | 立即回滚 | 发布值班负责人 | 确认后10分钟内启动 | 回滚版本，检查依赖服务与数据库慢查询 |
| 延迟 | 订单创建接口P99响应时间 | 10分钟内处于500–800ms | 10分钟滑动窗口 | 暂停放量观察 | 发布值班负责人 | 20分钟内给出结论 | 保持灰度比例，观察是否随流量上升恶化 |
| 业务成功率 | 下单支付成功率 | 较发布前基线下降超过3个百分点，持续15分钟 | 15分钟对比窗口 | 立即回滚 | 业务负责人与发布值班负责人共同确认 | 确认后15分钟内启动 | 回滚版本，核对优惠券抵扣计算结果，通报客服 |
| 业务成功率 | 优惠券核销成功率 | 较基线下降1–3个百分点，持续15分钟 | 15分钟对比窗口 | 暂停放量观察 | 业务负责人 | 30分钟内给出结论 | 冻结放量，抽样核对核销记录 |
| 数据异常 | 订单金额与优惠券抵扣金额不一致的记录数 | 出现任意1条可复现的不一致 | 发布全程 | 立即回滚 | 发布值班负责人 | 发现后立即启动 | 回滚版本，冻结相关数据修复流程，启动数据核对 |
| 数据异常 | 订单状态流转异常（如已支付订单停留在待支付） | 10分钟内出现3条及以上 | 10分钟窗口 | 立即回滚 | 发布值班负责人 | 发现后立即启动 | 回滚版本，导出异常订单清单交业务处理 |
| 依赖告警 | 下游库存服务、支付网关的错误率或超时告警 | 发布后新增告警且与本版本调用相关 | 发布全程 | 暂停放量观察 | 发布值班负责人 | 20分钟内给出结论 | 冻结放量，联合依赖方排查是否为本次变更引发 |
| 依赖告警 | 数据库连接池耗尽或主从延迟告警 | 发布后触发且持续5分钟未恢复 | 5分钟窗口 | 立即回滚 | 发布值班负责人 | 确认后10分钟内启动 | 回滚版本，检查新版本SQL与连接使用 |
回滚执行范围：仅回滚订单服务本次发布的版本，灰度实例与全量实例一并回退至上一稳定版本；数据库变更若已执行，按预先准备的兼容方案处理，不在此表展开。回滚后必做动作包括：确认核心指标恢复至基线、在发布记录中登记回滚原因与时间、通知业务方与客服、保留现场数据供复盘、24小时内完成初步复盘并决定修复后再发布的时间。
逐项解释：每条触发条件为什么这样写
为什么用观测窗口而非单点数值。监控曲线本身有抖动，单点超过阈值往往只是瞬时波动。用“连续5分钟高于2%”这类滑动窗口，能过滤掉偶发尖峰，也让判定有明确的时间依据，避免值班人员凭感觉决定再等一等。窗口长度与指标特性相关：错误率变化快，窗口可以短；业务成功率受用户行为影响，窗口需要拉长到15分钟才能看出趋势。
为什么区分立即回滚与暂停观察两档。两档对应不同的风险确定性。立即回滚用于信号明确、影响面大、继续放量会扩大损失的情况，例如错误率突破高位、出现数据不一致。暂停观察用于信号可疑但尚未确认的情况，例如指标轻度偏离、依赖方告警原因不明。保留中间档的价值在于：既不让团队在模糊信号下贸然回滚造成不必要的发布中断，也不让明显恶化的指标因为“再看看”而拖延处置。
业务成功率类指标与纯技术指标的差别。5xx错误率和响应时间反映服务是否正常响应，业务成功率反映用户是否真正完成了下单支付。技术指标正常但业务成功率下降，说明问题出在逻辑层面，例如优惠券抵扣计算错误导致用户放弃支付。这类指标需要业务负责人参与判定，因为技术值班人员未必能判断业务影响是否可接受。示例中把下单支付成功率的判定设为双人确认，正是这个原因。
数据异常类条件为何单独列出。数据错误具有不可逆性：错误订单一旦写入并流转，事后修复成本远高于回滚版本。因此数据异常类条件的阈值设得最严，出现1条可复现的金额不一致即触发立即回滚，且不设观察档。这类条件也要求回滚后立即冻结相关数据修复流程，先保留现场再处理。
责任人、决策时限与升级路径的设置理由。每条条件都指定责任人，是为了在告警响起时有人拍板，而不是在群里互相询问。决策时限把“多久内必须给出结论”写清楚，暂停观察档尤其需要，否则容易无限期冻结。升级路径的写法是：发布值班负责人在决策时限内无法判断时，升级至发布总负责人；涉及业务影响的，同步通知业务负责人。示例表中未单列升级路径一栏，实际填写时可在责任人栏后补充。
可迁移规律：换一套系统怎么改这张表
这张表的结构可以复用，数值和档位需要按自身情况重填。以下步骤给出改造顺序。
- 从历史发布与监控基线反推阈值。取过去若干次正常发布期间各指标的分布，以正常波动范围的上沿作为暂停观察档的起点，以明显偏离且伴随用户影响的位置作为立即回滚档。没有历史数据时，先按保守值填写，在头几次发布后校准。
- 按变更影响面确定观测窗口长度。变更涉及核心交易链路时，观测窗口覆盖到全量发布后至少一个业务高峰；变更只影响边缘功能时，窗口可以缩短。窗口要覆盖“问题可能暴露的最晚时点”，而不是固定套用2小时。
- 把分级档位与组织决策链对应。立即回滚档的责任人应当是当班即可拍板的角色，暂停观察档可以引入业务负责人或技术负责人共同判断。决策时限按组织实际响应速度设定，写得太短无法执行，写得太长失去约束意义。
- 回滚后动作清单按通用结构填写。止血（回滚版本、停止放量）、通报（通知业务方、客服、相关团队）、复盘（保留现场、分析根因）、修复再发布（确定修复方案与重新发布条件）。四类动作各自指定负责人和完成时限。
- 把条件写入发布检查单与发布评审。发布前评审时逐条确认触发条件已填写、监控已配置、责任人已知晓；发布检查单中把“触发条件表已确认”作为放行项。发布结束后，把实际触发的条件和判定过程记录到发布工作项与评审文档中，供下次校准阈值时参考。
在把触发条件与回滚决策沉淀为可追溯记录时，可以把条件表作为发布工作项的附件或检查项，把每次判定结果、回滚原因和复盘结论记录在同一处，形成从发布申请、评审、执行到复盘的连续记录。ONES 支持在工作项中维护发布相关信息并关联评审文档，便于后续按版本回溯当时的判定依据；具体配置方式按团队实际使用的功能为准。
适用边界：哪些情况不适合照搬这张表
这张表是填写示例，不是生产配置。以下情形需要区别对待。
| 情形 | 是否可直接套用 | 说明 |
|---|---|---|
| 示例中的阈值 | 不可直接使用 | 数值仅对应假设场景，必须按自身监控基线与历史发布数据重新校准 |
| 不可回滚的变更（如不可逆数据迁移） | 不适用 | 回滚路径不存在时，需要改为前向修复方案、数据补偿预案和更严格的发布前验证，判定逻辑围绕“是否继续执行”而非“是否回滚”设计 |
| 灰度发布与全量发布 | 需调整 | 灰度阶段的判定侧重“是否继续放量”，阈值可以更敏感；全量阶段的判定侧重“是否回滚”，需考虑回滚本身的业务影响 |
| 一般服务事件 | 不适用 | 与发布无关的故障按服务事件与问题管理流程处置，不套用发布回滚判定表 |
| 底层部署命令与工具操作 | 不在本文范围 | 本文只讨论判定规则，不涉及具体部署脚本或平台操作步骤 |
另外，发布回滚判定与日常告警处置的边界要划清：告警负责发现问题，回滚判定表负责回答“这个问题是否由本次发布引起、是否需要回滚”。两者联动，但判定依据和责任人不同，填写时不要把告警规则直接等同于回滚条件。
常见问题
发布回滚触发条件里，观测窗口设多长比较合适？
观测窗口的长度取决于指标特性和变更影响面。错误率这类变化快的指标，5分钟滑动窗口通常能过滤瞬时抖动；业务成功率受用户行为影响，需要拉长到15分钟才能看出趋势。变更涉及核心交易链路时，观测窗口应覆盖到全量发布后至少一个业务高峰；只影响边缘功能时可以缩短。关键是让窗口覆盖“问题可能暴露的最晚时点”，而不是固定套用某个时长。
如果发布后指标只是轻度偏离，应该回滚还是继续观察？
轻度偏离对应“暂停放量观察”档：冻结当前灰度比例、加密监控、排查原因，并在设定的决策时限内给出结论。这样既避免在模糊信号下贸然回滚造成不必要的发布中断，也不让可疑指标因为“再看看”而无限期拖延。如果观察期内指标继续恶化或原因指向本次变更，再升级为回滚。
不可回滚的变更（如不可逆数据迁移）怎么设计触发条件？
回滚路径不存在时，判定逻辑要围绕“是否继续执行”而非“是否回滚”设计。可以改为前向修复方案、数据补偿预案和更严格的发布前验证，并把触发条件写成“暂停执行、启动补偿、通知相关方”的动作组合。这类变更的观测窗口通常需要更长，判定责任人也要提前明确。
触发条件表写好后，怎么保证发布时真的被执行？
把条件表嵌入发布流程：发布前评审逐条确认触发条件已填写、监控已配置、责任人已知晓；发布检查单把“触发条件表已确认”作为放行项；发布结束后把实际触发的条件、判定过程和回滚原因记录到发布工作项与评审文档中，作为下次校准阈值的依据。记录与评审放在同一处，便于按版本回溯当时的判定依据。
发布回滚判定和日常告警处置是什么关系？
两者联动但职责不同：告警负责发现问题，回滚判定表负责回答“这个问题是否由本次发布引起、是否需要回滚”。与发布无关的故障按服务事件与问题管理流程处置，不套用发布回滚判定表。填写时不要把告警规则直接等同于回滚条件，否则容易把非发布引起的问题误判为回滚信号。
