回滚测试是什么
回滚测试验证发布失败后的退路是否真的可用：版本回退、数据与表结构能否兼容、配置与开关能否复原、灰度流量能否切回、用户会话与缓存如何过渡。回滚不是把发布脚本倒着放一遍——数据库迁移往往不可逆，新旧代码对数据的双向兼容才是最难的部分。回滚路径要准备，更要演练。
基本信息
| 触发条件 | 核心功能故障、错误率超阈值、资损风险、回滚预案到点未恢复 |
|---|---|
| 覆盖链路 | 代码版本回退、数据库迁移与兼容、缓存重建、配置开关、消息队列状态 |
| 数据兼容 | 新版本写的旧版读不了的字段要评估，必要时用双写与扩展字段过渡 |
| 验证方式 | 在预发环境完整演练一次回滚加回滚后的功能回归 |
| 时长目标 | 明确回滚操作耗时目标，与故障恢复时间要求对齐 |
| 记录要求 | 回滚演练结果与步骤持续维护，纳入发布检查表 |
典型使用场景
- 大版本发布前：按计划演练一次完整回滚，验证脚本与数据兼容。
- 数据库变更：加字段与改类型等迁移方案需要验证双向兼容路径。
- 灰度发布：验证灰度期发现问题时流量切回旧版本的行为。
- 故障预案：线上故障时以最快恢复为目标，回滚优于现场定位。
- 会话与缓存：确认回滚后缓存里的新格式数据不会让旧代码崩溃。
回滚要素与风险
| 要素 | 验证点 | 风险 |
|---|---|---|
| 代码回退 | 旧包可部署、启动正常 | 依赖新接口导致启动失败 |
| 数据库 | 迁移可逆向或保持兼容 | 结构改动不可逆丢失数据 |
| 缓存 | 旧代码容忍新格式数据 | 反序列化异常批量报错 |
| 消息队列 | 新格式消息旧消费者可解析 | 消费卡死或丢弃消息 |
| 配置开关 | 开关切回后行为符合旧逻辑 | 开关状态残留不一致 |
扩展与收缩两步走：先兼容再加功能，最后清理旧结构，才有从容回滚的窗口。
不可逆变更要单独评估：涉及数据删除与类型转换的迁移，回滚意味着数据丢失，必须有备份与恢复演练。
演练要真实：只在文档里推演步骤不算数，真正的演练会在启动脚本和权限上暴露问题。