# 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. 验证：

```bash
curl -f -sS http://127.0.0.1:18080/healthz
curl -f -sS http://127.0.0.1:18080/readyz
```

4. 执行业务冒烟：登录、订单查询、审计日志查询。

### 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)

```bash
# 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 + 业务流）
- 最终结论（成功/失败/部分恢复）