回退方案要解决什么
迁移切换的风险不在「切过去」，而在「退不回来」。可用的回退方案必须写清四件事：触发条件（什么指标超标就退）、数据回滚点（备份与增量在哪）、入口切换方式（DNS、VIP、负载均衡怎么切回）、时限（多久没通过就必须退）。写完之后至少完整演练一次，否则预案只是纸面承诺。
基本信息
| 四要素 | 触发条件、数据回滚点、入口切换方式、时限 |
|---|---|
| 数据侧 | 切换前落一次全量基线，源端保持只读或持续同步 |
| 入口侧 | DNS、VIP、负载均衡与客户端配置的切换方式 |
| 演练要求 | 切换前完整演练一次并记录步骤与耗时 |
| 执行要求 | 按预案指定角色执行，避免临时找人 |
典型使用场景
- 业务系统信创迁移的切换窗口前准备回退预案
- 演练回退流程，测量真实耗时是否落在窗口内
- 确认备份与数据库转储确实存在且可恢复
- 梳理 DNS TTL、定时任务、消息队列消费位点等易漏点
- 切换当天按预案客观判定继续还是回退
回滚点与入口自查
回滚点与入口自查
ls -lh /backup/full-*.tar.gz /backup/db-*.sql.gz # 回滚点文件是否就绪
df -h /backup /data # 回滚所需空间是否足够
dig +short app.example.com # 入口解析现状
rsync -avn /data/ /backup/data/ | tail -5 # 演练模式核对增量差异（-n 不实际写入）
# 触发条件示例（按业务实际调整并写入预案）：
# 1) 核心接口错误率持续 10 分钟高于 5%
# 2) 数据对账不一致且 30 分钟内无法定位
# 3) 关键功能不可用且没有临时绕行方案容易漏掉的恢复点
| 对象 | 漏掉的后果 | 检查方式 |
|---|---|---|
| DNS 与 TTL | 切换快、回退慢，缓存仍指向新环境 | 切换前调低 TTL 并确认生效 |
| 定时任务 | 回退后任务重复执行或任务全停 | 核对两侧的 crontab 与调度平台 |
| 消息队列位点 | 切换期间的写入数据丢失 | 确认消费位点与未消费积压 |
| 应用配置 | 回退后配置仍指向新环境地址 | 列配置清单逐项核对 |
只备份不演练，回退时才会发现账号、带宽、依赖包、证书之类细节缺失；演练记录（步骤、耗时、卡点）要作为预案附件归档，供切换当天直接照做。
切换窗口内源端要保持只读或持续同步：回退是回到源端，如果期间有新写入而没同步过去，这部分数据无论如何都找不回来。