决策人：唯一可授权
回滚是承认上线不成立的动作，必须由单一角色下令，避免集体讨论拖延。为什么：多人共同决策等于无人负责；决策人可以是技术负责人也可以是业务负责人，但预案里要写姓名而非岗位，换人时同步更新。
执行人：发布与运维
负责按快照切版本、回退配置、恢复流量，并在每一步记录时间戳。怎么做：执行人只执行预案内动作，遇到预案外情况必须回到决策人，不允许临场发挥改脚本，否则回滚结果无法追溯，也无法在复盘中还原现场。
数据负责人
库表回退、缓存清理、消息补偿、快照恢复都由数据岗判断与操作，并对数据一致性签字。边界：涉及客户主数据、资金与个人信息字段时，需客户方数据负责人共同确认，我方不单独处置，操作日志同步留存。
业务验收人
从用户视角判断恢复了没有，负责抽检关键路径、核对错发通知与订单状态。为什么需要业务确认：技术指标正常不等于业务正常，缺少业务确认的回滚经常在次日被投诉推翻，届时已无法判断问题出在哪一层。
安全与合规
确认回滚过程未扩大数据暴露面、临时账号与调试开关已回收、日志完整可审计。怎么做：把安全复核做成回滚清单的最后一栏，未完成不得关闭事件，并登记每个临时账号的回收时间，避免留成长期后门。
适用与不适用
适合谁
- 正在编写或评审回滚预案的实施团队
- 上线涉及多方供应商、责任边界需要写清的项目
- 出现过没人拍板导致恢复延迟的组织
不适合谁
- 单人维护、无生产流量的试验性系统
- 把回滚完全外包、不保留内部决策人的企业
典型场景
某物流企业的调度助手夜间异常，值班表上只有运维一人。按新预案，值班运维先执行降级切流，同时通知决策人与数据负责人；数据岗确认无结构变更后，执行人退回版本，次日业务负责人完成运单抽检并签认，安全岗回收两个临时账号。
可执行步骤
- 在预案首页列出五类角色的姓名、联系方式与替补人，并按季度核对。
- 为每个角色写清回滚前、中、后的动作清单，以及需要交付的记录名称。
- 明确决策人的授权范围，以及哪些情形可以不请示直接执行并事后报备。
- 演练时按真实角色分工实跑，重点检查交接环节是否顺畅、有无卡点。
- 事件结束后由各角色在复盘表上签认本岗结论与遗留事项的处理人。
常见坑
- 预案只写岗位不写姓名，夜间值班人翻遍通讯录也找不到该找谁，延误在前十分钟就发生。
- 让运维同时担任决策与执行，出问题时既当裁判又当运动员，复盘难以客观，也无人能约束。
- 数据岗未被纳入演练，真回滚时才发现没人有权执行快照恢复，只能临时授权，而窗口已过大半。
自检与验收清单
- 五类角色是否都落实到姓名、联系方式与替补人
- 决策人的授权边界是否书面化并告知值班人员
- 数据回退与快照恢复是否明确操作人与确认人
- 业务验收人是否参与过最近一次回滚演练并签字
- 安全复核是否作为关闭事件必须完成的前置条件
常见问题
小团队人手不够怎么分角色？
可以合并，但不能空缺：决策与执行必须分开，数据处置可由技术负责人兼，业务验收尽量由使用部门承担。合并后在预案里写明某人同时承担哪两项，并在演练中验证这种兼任不会变成自己批自己，也不会留下没人认领的环节。
供应商要参与回滚吗？
涉及外部模型、云资源或第三方接口的部分需要供应商配合，应在合同中约定响应时限与联系人。供应商负责其服务范围内的恢复，客户方仍对整体业务恢复负责，不能把决策权交出去，也不能把整体责任推给供应商。
角色名单多久更新一次？
建议与组织调整同步，至少每季度核对一次。人员变动是预案失效最常见的原因，很多方案内容没问题，只是电话打不通。核对时顺带确认替补人是否知道自己的职责，以及是否接到过通知。