Files
quyun-v2/docs/rollback_runbook.md

2.5 KiB
Raw Blame History

Rollback Runbook (Pre-Prod & Prod)

1. Scope

适用于 quyun_v2 发布失败或高风险回归时的回滚流程:

  • 应用版本回滚backend / frontend
  • 数据库变更回退策略
  • 验证与放行标准

2. Rollback Triggers

满足任一条件可触发回滚:

  1. /healthz/readyz 连续失败(超过 5 分钟)
  2. 登录/下单/支付/关键查询主路径不可用
  3. 错误率显著升高且无法在 15 分钟内修复
  4. 数据异常写入风险被确认

3. Preconditions

  • 可访问上一个稳定版本制品(镜像 tag / 前端产物)
  • 可访问最近一次有效备份(见 backup/restore runbook
  • 有发布人 + 审批人在线

4. Application Rollback

4.1 Backend 回滚

  1. 确认目标回滚版本(上一个稳定 tag
  2. 回滚部署到该版本(不修改配置与 secret
  3. 验证:
curl -f -sS http://127.0.0.1:18080/healthz
curl -f -sS http://127.0.0.1:18080/readyz
  1. 执行业务冒烟:登录、订单查询、审计日志查询。

4.2 Frontend 回滚

  1. 回滚 portal/superadmin 到上一个稳定产物。
  2. 清理 CDN/网关缓存(若启用)。
  3. 验证页面主路径:
    • /t/<tenantCode>/
    • /t/<tenantCode>/me/orders
    • /super/

5. Database Rollback Strategy

原则:优先应用回滚,避免直接回退 schema

5.1 可逆迁移场景

  • 若本次 migration 明确提供 down 语义且已验证,可执行受控回退。

5.2 不可逆迁移场景

  • 不执行 destructive down。
  • 采用:
    1. 应用回滚到兼容版本
    2. 若数据已损坏,执行“备份恢复到新库 + 切换”

6. Command Checklist (Example)

# 1) 标记回滚窗口开始

# 2) 回滚应用版本(按部署平台执行)

# 3) 健康检查
curl -f -sS http://127.0.0.1:18080/healthz
curl -f -sS http://127.0.0.1:18080/readyz

# 4) 关键业务验证
# (登录 / 核心查询 / 核心写操作)

# 5) 标记回滚完成

7. Post-Rollback Verification

必须记录:

  1. 回滚前后版本号
  2. 健康检查结果
  3. 关键业务结果
  4. 未恢复项(若有)
  5. 是否需要数据修复

8. Communication

  • 5 分钟内通知相关方“已触发回滚”
  • 15 分钟内同步“回滚结果 + 当前风险”
  • 24 小时内输出 RCA 与修复计划

9. Evidence Requirement

归档路径:docs/release-evidence/<date>.md

最少包含:

  • 触发原因
  • 执行步骤与时间线
  • 校验结果healthz/readyz + 业务流)
  • 最终结论(成功/失败/部分恢复)