回滚与前滚怎么选
发布后出问题的两条路径：回滚到上一版本恢复服务，或前滚发布修复版本；选择依据是恢复速度、数据兼容性与根因清晰度。通用顺序是先恢复服务再决定修复方式，事故中犹豫时间越长影响面越大。回滚也不是免费选项：数据与依赖的兼容性要先验证，否则旧版本可能引发二次故障。
基本信息
| 回滚 | 恢复快、确定性高；受数据库与状态兼容性制约 |
|---|---|
| 前滚 | 适合根因明确、修复量小的场景，保留新功能 |
| 决策顺序 | 先恢复服务，再决定修复方式 |
| 约束 | 破坏性的数据变更通常无法纯回滚 |
| 演练 | 两条路径都要提前演练，事发时按流程执行 |
典型使用场景
- 未知根因：先回滚止血，再复盘定位。
- 根因明确：一行配置或小修复，直接前滚。
- 数据变更已发生：评估迁移与兼容，纯回滚可能再次故障。
- 灰度环境：前滚修复验证后逐步放量。
- 发布窗口受限：回滚优先保持服务可用。
决策速记
决策速记
服务不可用 → 先止血：能回滚就回滚
只是功能小缺陷 → 评估前滚修复窗口
数据已不兼容 → 前滚修复或按迁移预案处理场景判据
| 场景 | 优先 |
|---|---|
| 服务不可用 | 回滚（能回则回） |
| 小缺陷、可快速修 | 前滚修复 |
| 不可逆数据变更 | 前滚加迁移预案 |
回滚前确认依赖兼容：旧版本读取新结构的数据可能再次故障。
决策时限先定好：事故等级对应多久内必须做出回滚或前滚决定，避免无限讨论。
复盘产出双清单：根因修复项与流程改进项分开记录，下次事故才有参照。