回滚演练是什么
定期在类生产或生产环境执行一次真实回滚：验证版本可退、数据兼容、权限具备、观测正常。把「能不能回」从假设变成事实——很多团队第一次演练才发现镜像已被清理、回滚脚本年久失修、权限根本不在自己手里。演练要有记录、有产出：问题清单与预案修订，并且要练决策：什么情况下回滚、什么情况下继续修复。
基本信息
| 频率 | 按季度或随重要架构变更执行 |
|---|---|
| 环境 | 类生产环境或低峰期生产，按业务风险选择 |
| 检查点 | 回滚耗时、数据一致性、监控与告警、操作权限 |
| 前置 | 确认当前版本与上一版本的制品都还在 |
| 产出 | 问题清单与预案修订，进入可靠性待办 |
| 参与 | 发布人与值班共同执行，避免个人依赖 |
典型使用场景
- 季度例行：固定节奏验证回滚路径整体可用
- 重大变更前：数据库迁移、协议升级前先验证退路
- 新人上手：通过演练让新人掌握回滚操作与判断标准
- 预案修订后：改完流程要走一遍确认没有遗漏
- 事故后抽查：真实回滚过的事件，检查预案是否同步更新
- 多服务联动：验证一组服务同时回退的编排
演练记录模板
演练记录模板
日期：2026-10-12 目标：web@prod
结果：成功 耗时：4m30s
发现：旧镜像 tag 未归档，已补推
跟进：更新回滚预案第 3 步
下次演练：随下个季度例行安排检查点与证据
| 检查点 | 通过标准 | 证据 |
|---|---|---|
| 耗时 | 在承诺的恢复时限内 | 演练记录 |
| 数据 | 回退后数据可读且一致 | 校验脚本输出 |
| 监控 | 告警与仪表盘正常反映 | 截图或注释记录 |
| 权限 | 执行人具备操作权限 | 操作日志 |
演练时可能发现镜像标签已被清理：验证镜像保留策略是固定环节。
回滚不只是回应用：配置、开关、数据库脚本都要能一起退，链条缺一环就卡住。
演练要练决策：先定「什么时候选回滚而不是继续修复」的标准，再练操作。