1. Rollback vs Rollforward：别把“撤退”当成唯一解
当线上出事，你通常有两条路：
- Rollback（回滚）：回到上一套已知好版本（known-good bundle）。
- Rollforward（前滚）：快速修复缺陷，用一个更正版本继续向前（有时更安全）。
什么时候更偏向前滚？
- 已经做了不可逆的数据变更（或回滚会引入更大一致性风险）
- 安全漏洞需要“修复并补洞”，而不是退回到旧漏洞
- 回滚成本太高（需要长时间停机）而前滚可以快速止血
- 已经做了不可逆的数据变更（或回滚会引入更大一致性风险）
- 安全漏洞需要“修复并补洞”，而不是退回到旧漏洞
- 回滚成本太高（需要长时间停机）而前滚可以快速止血
2. 回滚决策树：先止血，再归因，再选择策略
事故现场最怕“讨论哲学”。你需要一个决策树把团队从混乱拉回到可执行的步骤。
图 1：回滚决策树。先止血（冻结发布/开关止损），再根据数据与兼容性选择回滚或前滚。
3. 数据决定一切：Expand/Contract 给你“可回滚窗口”
只要涉及数据库或持久化状态，回滚就会变得困难：新版本写入的新字段、改变的数据语义、迁移后的索引与约束，都会让旧版本无法读取或产生错误逻辑。 所以成熟团队会把数据变更拆成两个阶段：
- Expand：只做向后兼容的扩展（加字段、加表、双写、加索引但不移除旧能力）。
- Contract：在旧版本不再需要时再清理（删字段、删表、移除旧代码路径）。
要点：Expand 阶段是你的“回滚保险丝”。只要还没进入 Contract，你通常还能安全回滚（因为旧版本仍然能读写旧路径）。
图 2：Expand/Contract 时间线。Expand 阶段设计“可回滚窗口”，Contract 阶段再做破坏性清理。
4. Hotfix 通道：更少步骤，但更强控制
hotfix 的目标是“快速止损”，但它常常把团队带入另一个坑：为了快，把治理全删了，结果是更快地引入第二个事故。 正确的 hotfix 通道应该是：步骤更少，但控制更强。
4.1 hotfix 的最小流程（建议落地成模板）
- 触发条件：明确什么算“紧急”（SLO 破坏、核心路径不可用、安全漏洞）。
- 权限模型：最小授权 + 双人原则（至少两人审批或两人密钥）。
- 变更范围：只允许最小修复，禁止“顺手重构”。
- 验证策略：最小必要测试集 + 关键回归（别全跑，但也别裸奔）。
- 发布策略：优先小比例金丝雀 + 强止损；或直接回滚 bundle 先止血。
- 审计证据链：issue/工单、审批记录、制品 digest、发布标记、影响范围。
图 3：hotfix 通道不是“删步骤”，而是“缩路径 + 加控制”。它必须更可审计、更可止损。
5. 最小落地清单（把“能救火”变成“可持续救火”）
- 预置回滚：上一套 bundle 永远可用；回滚演练常态化。
- 数据兼容策略：默认向后兼容；迁移用 expand/contract 拆阶段。
- 止损能力：kill switch、冻结发布、限流、降级必须可一键执行。
- hotfix 治理：双人原则、最小权限、最小变更、审计链路完整。
- 复盘闭环：把这次事故的“触发条件、缺失门禁、误判指标”变成规则与自动化。
你现在应该能回答：
1) 我们回滚时回滚的对象是什么？是否能回到上一套已知好组合？
2) 当前数据变更是否允许回滚？如果不允许，我们的前滚策略是什么？
3) hotfix 通道是否做到“更快但更可控”？证据链是否完整？
1) 我们回滚时回滚的对象是什么？是否能回到上一套已知好组合？
2) 当前数据变更是否允许回滚？如果不允许，我们的前滚策略是什么？
3) hotfix 通道是否做到“更快但更可控”？证据链是否完整？