回滚预案要写清三件事
升级就有失败的可能，回滚预案至少要写清三件事：什么情况下回滚、谁决定回滚、怎么回滚。触发条件要具体（启动异常、核心功能异常、性能明显下降、兼容问题），决策人与操作人要提前指定，旧镜像、旧配置备份与 Console 通道要提前准备到位。
基本信息
| 触发条件 | 启动失败、核心功能异常、性能明显下降、兼容问题 |
|---|---|
| 资源准备 | 旧版本镜像 + 配套配置备份 + Console 通道 |
| 时效要求 | 明确回滚决策时间点与决策人 |
| 演练 | 至少在测试环境完整做过一次 |
典型使用场景
- 升级窗口内出现启动异常，需要快速决策
- 新版本引入功能缺陷，影响业务可用性
- 升级后性能下降超过可接受范围
- 变更评审要求提供回退方案
- 复盘升级事故时核对预案是否被执行
回滚要点
回滚要点
# 1. 触发条件满足 → 由指定决策人确认回滚
# 2. 停止业务接入或切到备机，避免带业务状态回退
# 3. 通过 Console 或降级流程恢复旧版本镜像
# 4. 恢复与旧版本配套的配置备份，重启后验证
# 5. 业务验证通过后，复盘升级失败的根因回滚要素
| 要素 | 缺失时的后果 |
|---|---|
| 旧版本镜像 | 无处可回，只能等厂商支持或重建环境 |
| 配套配置备份 | 新旧配置混用，行为不可预期 |
| Console 通道 | 网络中断后失去本地管理入口 |
| 决策人与时限 | 现场无人拍板，业务中断时间被拉长 |
回滚演练（至少在测试环境完整做过一次）能显著降低现场压力，也能提前暴露缺少的资源。
回滚时忘记恢复配套配置版本，新旧配置混用可能引出比升级失败更严重的问题。
回滚判决要设时间上限：例如升级后核心功能在三十分钟内未恢复即触发回滚，避免在现场反复尝试中把业务窗口耗完。