回退与应急预案是什么
回退与应急预案定义变更失败时的止损路径：谁有权决定回退、多久未恢复就触发回退、按什么步骤回退、回退后如何验证。它的取向是先恢复服务、再排查根因，把损失控制在前端时间盒内。方案的价值取决于是否事前演练，纸面回退计划在真实故障里经常不可执行。
基本信息
| 四大要素 | 回退决策人、时间盒、回退步骤、验证点 |
|---|---|
| 核心原则 | 优先恢复服务，再定位根因 |
| 前置要求 | 高风险变更实施前验证回退可用性 |
| 不可回退场景 | 数据库结构变更、已发出的事件消息、外部已生效的合同数据 |
| 记录要求 | 回退动作与现场证据保留，供复盘使用 |
典型使用场景
- 版本发布后关键业务指标异常，需在用户投诉量放大前止损
- 数据库变更执行一半出现锁等待，需要判定继续还是中止
- 配置中心推送错误参数，导致大范围服务行为异常
- 灰度阶段发现新逻辑对特定用户群不兼容，需要定向回滚
- 基础设施升级引发兼容问题，需要恢复到升级前镜像
时间盒示例
时间盒示例
# 时间盒把回退决策从情绪判断变成事前约定
发布后 15 分钟：关键指标异常 → 暂停推进，禁止继续放量
30 分钟仍未定位：执行回退，不再纠缠原因
# 回退不等于结束：恢复服务和保留证据同等重要
回退后：验证核心功能恢复，保留日志与现场镜像供复盘
# 每次回退都要形成结论，否则下次还会踩同一个坑
复盘：记录触发原因、判定依据、耗时，更新应急预案回退与修复的前置判断
| 判断项 | 回退更快 | 修复更快 |
|---|---|---|
| 故障范围 | 影响面广且持续扩散 | 局限在单一分支或单一租户 |
| 根因明确度 | 原因不明，靠猜 | 已定位到具体配置或代码行 |
| 回退代价 | 版本切换、镜像回滚 | 回退会丢数据或破坏结构 |
| 用户影响 | 核心链路不可用 | 边缘功能降级可接受 |
回退方案未经演练不可假设可用：数据库迁移、消息格式变更、外部接口对接类变更常常无法简单回退，这类变更需要灰度、双写或前向修复作为替代方案。