发布回滚预案模板应围绕“触发—决策—执行—验证—复盘”五段组织：用发布信息与回滚触发条件界定何时启动，用回滚范围与步骤说明回退到什么状态，用角色分工表明确谁判断、谁执行、谁验证、谁对外沟通，用决策记录表留下每次启动或放弃回滚的判断依据与时间点。模板以空白表格交付，字段说明、必填与选填、填写示例与维护方法保持同一套字段口径，便于直接复制到文档或表格工具中填写。
要点总览（TL;DR）
- 模板以五张表交付：发布与回滚基本信息、回滚触发条件与分级、回滚范围与步骤、角色分工、决策记录，字段名在空白表、说明表与示例表中保持一致。
- 角色分工按判断、执行、验证、沟通四类职责拆分，回滚决策人、回滚执行人、验证负责人为必填角色，验证应与执行分离，兼任情况需在表中写明。
- 决策记录以时间点为锚，逐条记录触发事件、判断依据、决策结论、决策人与后续动作，与回滚步骤通过时间点和步骤序号对应，便于复盘还原判断过程。
- 必填字段以“缺失后无法安全回滚”为标准，至少包含基线版本、回滚目标版本、数据变更说明、一条一级触发条件及判定人、可执行的回滚步骤与核心角色。
- 模板需设置版本号与维护责任人，按发布类型裁剪字段，预案在发布前评审，回滚后归档决策记录并复盘，将阈值偏差与步骤缺失回写到维护说明。
可复制空白模板
下面五张表构成一套完整的发布回滚预案。复制时建议保留表头与字段名，按发布单逐条填写；同一发布涉及多个服务时，每个服务单独复制一份“回滚范围与步骤表”，基本信息表与角色分工表可共用。
表1 发布与回滚基本信息表
| 字段 | 填写内容 |
|---|---|
| 预案编号 | |
| 发布名称 | |
| 发布单/需求链接 | |
| 发布负责人 | |
| 计划发布时间 | |
| 发布窗口 | |
| 涉及服务与版本 | |
| 变更类型 | |
| 影响范围 | |
| 当前线上基线版本 | |
| 回滚目标版本 | |
| 数据变更说明 | |
| 预案编制人/日期 | |
| 预案评审状态 |
表2 回滚触发条件与分级表
| 级别 | 触发条件 | 判定指标与阈值 | 观察窗口 | 建议动作 | 判定人 |
|---|---|---|---|---|---|
| 一级（立即回滚） | |||||
| 二级（限时决策） | |||||
| 三级（观察跟进） |
表3 回滚范围与步骤表
| 步骤序号 | 操作对象 | 操作内容 | 执行人 | 预计耗时 | 完成标志 | 失败时的下一步 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 |
表4 角色分工表
| 职责角色 | 承担人 | 具体职责 | 决策权限 | 联系方式 | 是否兼任 |
|---|---|---|---|---|---|
| 回滚决策人 | |||||
| 回滚执行人 | |||||
| 验证负责人 | |||||
| 对外沟通人 | |||||
| 数据处置负责人 | |||||
| 记录人 |
表5 决策记录表
| 记录时间 | 触发事件/观察现象 | 判断依据 | 决策结论 | 决策人 | 后续动作与责任人 | 完成时间 |
|---|---|---|---|---|---|---|
字段说明：每个字段填什么
字段说明与空白模板逐项对应。填写时以“读者能否据此复现判断”为标准：凡是需要临场判断的字段，都要写清指标、阈值或判断人，避免只写“视情况而定”。
基本信息字段含义
| 字段 | 含义与填写口径 | 常见填法 |
|---|---|---|
| 预案编号 | 预案的唯一标识，便于与发布单、决策记录互相引用 | 发布单号加日期，如 REL-20250612-01 |
| 发布名称 | 本次发布的业务描述，一句话说明改了什么 | 支付收银台优惠券叠加逻辑上线 |
| 发布单/需求链接 | 指向发布单、需求或变更单，保证预案可追溯 | 填写工作项编号或文档地址 |
| 发布负责人 | 对本次发布整体结果负责的人 | 填写姓名与所属团队 |
| 计划发布时间 | 具体到日期与时段 | 2025-06-12 22:00–23:00 |
| 发布窗口 | 允许发布与回滚的时间范围，超出窗口需重新决策 | 低峰时段，避开对账与结算时点 |
| 涉及服务与版本 | 列出服务名、新版本号与依赖关系 | 支付网关 v3.8.2、优惠券服务 v2.1.0 |
| 变更类型 | 区分代码、配置、数据库、依赖升级等类型 | 代码加配置变更 |
| 影响范围 | 受影响的用户、业务链路与下游系统 | 收银台下单链路，影响全部支付渠道 |
| 当前线上基线版本 | 回滚后应恢复到的版本，必须与发布前核对 | 支付网关 v3.8.1 |
| 回滚目标版本 | 回滚动作的终点状态，通常等于基线版本 | 与基线版本一致，或注明灰度回退范围 |
| 数据变更说明 | 本次发布是否改动表结构、数据或缓存格式，以及能否随版本回退 | 新增字段可兼容；缓存键格式变更需清理 |
| 预案编制人/日期 | 预案的编写责任人与定稿时间 | 填写姓名与日期 |
| 预案评审状态 | 记录预案是否经过评审及评审结论 | 已评审通过 / 待评审 |
触发条件字段的判定口径
触发条件要写成可观测的判断，而不是笼统的风险描述。判定指标应来自监控、日志或业务数据，阈值写明单位与统计口径；观察窗口说明在多长时间内达到阈值才触发；建议动作区分“立即回滚”“限时决策”“继续观察”，并写明由谁判定。三级分级的用意是避免所有异常都走同一条路径：一级条件明确、影响面大，直接执行回滚；二级条件需要决策人在限定时间内判断；三级条件进入观察清单，由值班人员跟进。
回滚范围与步骤字段的粒度
步骤粒度以“另一名工程师照着能执行”为准。操作对象写到具体服务、配置项或数据表；操作内容写动作与参数，不写“恢复服务”这类笼统表述；完成标志写可核验的结果，如健康检查通过、关键接口返回正常、监控指标回落；失败时的下一步写明是重试、跳过还是升级决策。涉及数据变更的发布，需单独列出数据处置步骤及其不可逆风险。
角色分工字段的职责描述
职责描述要写清动作与产出，而非头衔。回滚决策人负责依据触发条件作出启动或放弃回滚的判断，并对决策结果负责；回滚执行人按步骤表操作并回报每步完成情况；验证负责人独立核对业务与系统指标，给出“回滚成功/未成功”的结论；对外沟通人负责向客服、业务方与用户同步进展；数据处置负责人处理数据兼容与清理；记录人负责在决策记录表中留下时间点与依据。同一人兼任多个角色时，在“是否兼任”列写明兼任关系，避免决策与验证由同一人完成而失去复核。
决策记录字段的时间与依据
每条记录以时间为锚，按发生顺序追加，不覆盖历史记录。判断依据写当时看到的现象与数据，例如错误率、订单失败数、告警内容；决策结论写“启动回滚”“暂不回滚继续观察”或“放弃回滚并修复”；后续动作与责任人写清下一步由谁在何时完成。决策记录与回滚步骤通过时间点和步骤序号对应，复盘时可还原“先看到什么、谁在何时决定、执行到哪一步”。
必填与选填：哪些字段不能空
必填字段是发布前必须确认、缺失就无法安全回滚的信息；选填字段按发布规模和变更类型取舍。判断标准是：该字段缺失时，执行人是否还能在有限时间内完成回滚并作出判断。
必填字段清单及理由
| 所属表 | 必填字段 | 理由 |
|---|---|---|
| 基本信息 | 预案编号、发布名称、发布负责人、计划发布时间、涉及服务与版本、当前线上基线版本、回滚目标版本、数据变更说明 | 缺少基线版本或数据说明，回滚终点不明确；缺少负责人则无人对结果负责 |
| 触发条件 | 至少一条一级触发条件及其判定指标、阈值、判定人 | 没有明确触发条件，回滚启动只能依赖临场感觉 |
| 回滚步骤 | 步骤序号、操作对象、操作内容、执行人、完成标志 | 步骤不可执行或无法核验，回滚过程不可控 |
| 角色分工 | 回滚决策人、回滚执行人、验证负责人 | 决策、执行、验证三类职责缺一不可，且验证应与执行分离 |
| 决策记录 | 记录时间、判断依据、决策结论、决策人 | 缺少依据与时间点，事后无法追溯判断是否合理 |
选填字段清单及适用场景
| 字段 | 适用场景 |
|---|---|
| 发布窗口 | 有明确低峰时段或结算等敏感时点的业务 |
| 影响范围 | 面向多业务线或外部用户的发布 |
| 二级、三级触发条件 | 灰度发布、分批放量或指标波动需要观察期的发布 |
| 预计耗时 | 回滚步骤较多、需要协调停机窗口的发布 |
| 失败时的下一步 | 步骤之间存在依赖或存在不可逆操作的发布 |
| 数据处置负责人、对外沟通人 | 涉及数据变更或需要向外部同步进展的发布 |
| 联系方式 | 跨团队协作、夜间发布或值班交接场景 |
留空或待确认字段的标注方式
发布前无法确认的字段不要留白，统一填写“待确认”，并在字段后注明确认人与确认时限，例如“待确认（张三，发布前2小时）”。评审时逐项检查“待确认”项，未关闭的不得进入发布。确实不适用的字段填写“不适用”并简述原因，便于评审区分“遗漏”与“有意省略”。
不同发布规模下的字段取舍
小型配置类发布可保留基本信息、一级触发条件、回滚步骤与三类核心角色，决策记录至少保留一条；常规功能发布补齐影响范围、二级触发条件与失败处置；涉及数据库、资金或多服务联动的重大发布，五张表全部填写，并增加数据处置负责人与对外沟通人。取舍规则应写入模板维护说明，避免同一团队在不同发布中口径不一致。
填写示例：一次支付服务发布的回滚预案
以下为演示情景，用于说明字段如何落地，不代表真实项目数据。示例中的阈值、时间与人员均为示意。
示例背景与发布范围
某支付服务计划在低峰时段上线优惠券叠加逻辑，涉及支付网关与优惠券服务两个服务，支付网关由 v3.8.1 升级到 v3.8.2，优惠券服务由 v2.0.9 升级到 v2.1.0。本次发布包含配置变更与缓存键格式调整，缓存格式变更后旧版本读取新缓存可能异常，因此回滚步骤中包含缓存清理。
触发条件与回滚步骤的填写
| 级别 | 触发条件 | 判定指标与阈值 | 观察窗口 | 建议动作 | 判定人 |
|---|---|---|---|---|---|
| 一级 | 支付成功率明显下降 | 支付成功率低于 98%，且持续 5 分钟 | 发布后 30 分钟内 | 立即回滚 | 值班负责人 |
| 二级 | 优惠券核销异常增多 | 核销失败率高于 1%，持续 10 分钟 | 发布后 2 小时内 | 限时 15 分钟内决策 | 发布负责人 |
| 三级 | 个别渠道响应变慢 | P99 响应时间上升 20% | 发布后 4 小时内 | 继续观察并记录 | 值班人员 |
| 步骤序号 | 操作对象 | 操作内容 | 执行人 | 预计耗时 | 完成标志 | 失败时的下一步 |
|---|---|---|---|---|---|---|
| 1 | 支付网关 | 停止放量，将流量切回 v3.8.1 实例 | 后端值班工程师 | 5 分钟 | 新版本实例无流量 | 联系发布负责人升级决策 |
| 2 | 优惠券服务 | 回退至 v2.0.9 并重启 | 后端值班工程师 | 10 分钟 | 健康检查通过 | 重试一次，仍失败则升级 |
| 3 | 缓存 | 清理新格式缓存键，恢复旧格式读取 | 数据处置负责人 | 10 分钟 | 核销接口返回正常 | 暂停操作，评估数据影响 |
| 4 | 监控与业务 | 核对支付成功率与核销失败率 | 验证负责人 | 15 分钟 | 指标回到发布前水平 | 记录未达标项并上报 |
角色分工的填写
| 职责角色 | 承担人 | 具体职责 | 决策权限 | 联系方式 | 是否兼任 |
|---|---|---|---|---|---|
| 回滚决策人 | 发布负责人 | 依据触发条件决定启动或放弃回滚 | 可决定启动回滚 | 值班群与电话 | 否 |
| 回滚执行人 | 后端值班工程师 | 按步骤表执行回退与重启 | 无决策权，按指令执行 | 值班群 | 否 |
| 验证负责人 | 测试负责人 | 独立核对业务指标并给出结论 | 可判定回滚未成功 | 值班群 | 否 |
| 对外沟通人 | 业务运营 | 向客服与业务方同步进展 | 无 | 值班群 | 否 |
| 数据处置负责人 | 后端值班工程师 | 处理缓存与数据兼容问题 | 无 | 值班群 | 与执行人兼任 |
| 记录人 | 发布负责人 | 在决策记录表中记录时间与依据 | 无 | 值班群 | 与决策人兼任 |
决策记录的一次完整记录
| 记录时间 | 触发事件/观察现象 | 判断依据 | 决策结论 | 决策人 | 后续动作与责任人 | 完成时间 |
|---|---|---|---|---|---|---|
| 22:18 | 支付成功率告警 | 支付成功率降至 97.2%，持续 6 分钟，达到一级触发条件 | 启动回滚 | 发布负责人 | 执行人按步骤1至3回退，验证负责人核对指标 | 22:45 |
示例与字段说明的一致性
示例中的字段名与空白模板、字段说明表保持一致：基本信息中的基线版本对应回滚目标版本，触发条件使用同一套级别与判定口径，角色分工覆盖决策、执行、验证与沟通，决策记录以时间点为锚并写明依据。团队复制模板后，只需替换示例内容，字段结构无需改动。
调整与维护方法
模板的价值在于长期可用。发布形态变化时调整字段，预案定稿前评审，回滚发生后归档并复盘，模板本身也要有版本与责任人。
按发布类型裁剪字段的方法
先判断发布是否涉及数据变更、多服务联动与外部用户影响，再决定保留哪些表。纯配置调整可只保留基本信息、一级触发条件、回滚步骤与核心角色；涉及数据格式变更的发布必须保留数据变更说明与数据处置步骤；灰度发布增加二级触发条件与观察窗口。裁剪结果写入预案首页的“适用范围”说明，评审时据此核对。
预案评审与更新时点
预案应在发布前完成评审，评审检查项包括：基线版本与回滚目标是否一致、触发条件是否可观测、回滚步骤是否可执行、验证角色是否与执行角色分离、待确认项是否关闭。发布内容变更、依赖服务升级或线上基线变化时，同步更新预案并重新评审；长期未使用的预案在下次发布前复核一次。
决策记录的归档与复盘衔接
每次发布结束后，将决策记录与回滚步骤执行情况一并归档到发布单或对应文档中。复盘时按时间线核对：触发条件是否及时被观察到、决策依据是否充分、执行步骤是否按预期完成、验证结论是否独立。复盘中发现的阈值偏差或步骤缺失，回写到模板维护说明，作为下一次修订的依据。
模板版本与责任人维护
模板设置版本号与维护责任人，每次修订记录变更内容与生效日期。修订范围包括字段增删、必填项调整、示例更新与裁剪规则变化。团队可将模板放入文档工具的模板库中统一创建，减少各人自行复制造成的字段漂移；预案文档与发布工作项保持关联，评审结论与决策记录随发布单一同留存。ONES Wiki 支持通过页面模板库创建制式化文档，并记录页面版本、支持按角色配置读写权限，可用于承载预案模板与决策记录的协作与留痕；需要说明的是，文档版本回滚指页面内容的版本恢复，与本文讨论的发布回滚不是同一概念。
常见问题
发布回滚预案和发布方案是同一份文档吗，需要分开维护吗？
两者关注点不同。发布方案说明本次要上线什么、按什么顺序放量、如何验证；回滚预案说明出现什么现象时退回、退到什么状态、由谁判断与执行。实践中可以放在同一份发布文档的不同章节，但回滚预案应能独立阅读：执行人在发布现场只翻回滚章节，也能找到触发条件、回滚步骤和责任人。若两者合并，建议在回滚章节开头写明适用的发布单编号与基线版本，避免发布内容变更后回滚章节未同步更新。
小团队人手有限，决策人和执行人由同一人担任可以吗？
决策与执行由同一人担任在小规模发布中可以接受，但验证环节建议保留独立复核。可行的做法是：决策与执行合并为一人，验证由另一名同事承担，哪怕只是按完成标志逐项核对指标；对外沟通可由业务方兼任。角色分工表中在“是否兼任”列写明兼任关系，评审时重点检查验证是否与执行分离。若连验证也无法分离，至少在决策记录中写明“自验证”并附上核对的具体指标与数据，便于事后复盘判断。
发布后指标波动但未达到一级触发条件，决策记录该怎么写？
这种情况属于二级或三级条件的处理范围，同样要留下记录。记录时间、观察到的现象与具体数据、当时对照的阈值、决策结论（如“暂不回滚，继续观察 30 分钟”）以及观察责任人与下次复核时间。若观察期结束后指标回落，补一条记录说明关闭原因；若指标继续恶化并触发一级条件，再追加一条启动回滚的记录。这样时间线上能看出“先观察、后回滚”的完整判断过程，复盘时可以评估观察窗口设置是否合理。
预案评审应该在什么时点做，评审不通过还能发布吗？
评审应在发布前完成，通常在发布单进入待发布状态、变更内容冻结之后。评审检查基线版本与回滚目标是否一致、触发条件是否可观测、回滚步骤是否可执行、验证角色是否独立、待确认项是否关闭。评审不通过时，处理方式取决于缺口性质：字段填写不完整或待确认项未关闭，补齐后重新评审即可；回滚步骤本身不可执行或数据变更不可逆且无处置方案，应推迟发布或缩小发布范围。评审结论与遗留项记录在预案的评审状态字段中，随发布单留存。
决策记录和回滚步骤执行情况归档到哪里，后续复盘怎么用？
归档位置应与发布单关联，常见做法是把决策记录表与步骤执行情况放在同一份发布文档中，并在发布工作项上留下指向该文档的链接。复盘时按时间线核对四件事：触发条件是否被及时发现、决策依据是否充分、步骤是否按预期完成、验证结论是否独立得出。复盘中发现的阈值偏差、步骤缺失或角色空缺，回写到模板维护说明并记录修订版本，作为下一次发布前评审的检查项。归档内容同时可作为后续同类发布编写预案的参考。
