| 回滚 | 恢复快、确定性高；受数据库与状态兼容性制约 |
|---|---|
| 前滚 | 适合根因明确、修复量小的场景，保留新功能 |
| 决策顺序 | 先恢复服务，再决定修复方式 |
| 约束 | 破坏性的数据变更通常无法纯回滚 |
决策速记
决策速记
服务不可用 → 先止血：能回滚就回滚
只是功能小缺陷 → 评估前滚修复窗口
数据已不兼容 → 前滚修复或按迁移预案处理回滚前确认依赖兼容：旧版本读取新结构的数据可能再次故障。
回滚与前滚修复（Rollback vs Fix Forward）
发布后出问题时有两条路径：回滚到上一版本恢复服务，或前滚发布修复版本；选择依据是恢复速度、数据兼容性与根因清晰度。
易错点
- 事故中边排查边犹豫：决策时间拉长，影响面扩大
- 假设回滚总能成功：未验证旧版本与当前数据、配置的兼容性
数据来源与参考
- Google SRE Book《Release Engineering》
- Martin Fowler《BlueGreenDeployment》相关讨论