Skip to content
返回维护与 LTS

回滚计划

让每次升级可即时回滚 — 使你敢于激进升级的安全网。

为什么

无法回滚的升级是赌公司事件，所以团队回避升级 — 这累积债务。回滚计划把升级从单向门变双向门：若 staging 或金丝雀显示回归，你秒级回滚下周再试。关键洞察是回滚必须在你需要前排练过；未排练的回滚在凌晨 3 点失败，因为旧镜像被 GC、DB 迁移不可逆、feature flag 被删。每次发布在 staging 排练使回滚成反射而非研究项目。

何时使用

每次大版本升级部署前。把回滚排练作为升级 PR 完成定义的一部分在 staging 做。

如何做

1. 保留旧镜像：部署升级前把当前生产镜像打 :prev 标签
2. DB 变更：只发前向兼容迁移（expand-contract），使旧镜像在新 schema 上仍工作
3. 在 feature flag 后或以金丝雀（10% 流量）部署升级
4. 观察黄金信号（错误率、p95 延迟、关键业务指标）10 分钟
5. 任一信号超阈值退化则回滚：kubectl rollout undo（或关 flag）
6. 排练：在 staging 部署升级后立即回滚 — 确认应用仍工作
7. 在升级 PR 描述中写明回滚命令，值班不必临场发明

示例

# 升级部署前给旧镜像打标签
docker tag registry/app:current registry/app:prev
docker push registry/app:prev

# 以金丝雀部署升级
kubectl set image deployment/app app=registry/app:upgraded
kubectl rollout status deployment/app  # 等金丝雀

# 错误率飙升则 <30 秒回滚
kubectl rollout undo deployment/app

# Feature-flag 回滚（即时，无需重新部署）
# 在 flag 系统中：
curl -X POST https://flags/api/v1/flags/use-react-18 -d '{"enabled":false}'

# 在 staging 排练（升级 PR 的 CI 作业）：
#   1. 部署 :upgraded 到 staging
#   2. 跑冒烟测试
#   3. kubectl rollout undo
#   4. 再跑冒烟测试 — 必须仍通过

常见问题

  • ⚠需要时旧镜像已被 GC — 回滚失败因为制品没了。
  • ⚠DB 迁移随升级跑了且不可逆 — 代码可回滚但 schema 卡住。
  • ⚠回滚从没排练，凌晨 3 点值班发现命令错了或 flag 被硬编码删了。

最佳实践

  • ✓始终把旧镜像打 :prev 标签并在升级部署后保留至少 24 小时。
  • ✓用 expand-contract DB 迁移使旧代码版本在新 schema 上仍工作 — 回滚无需 DB 还原。
  • ✓把回滚排练作为每个升级 PR 的 CI 门控：部署、undo、重测 — 回滚失败则升级不发。