Docs / Runbooks / 回滚 runbook

回滚 runbook

升级/部署失败时把代码与数据恢复到上一可用状态。

source=manual · owner=biz-dev · lastVerified=2026-11-07 · version=1.0

什么时候回滚

满足任一条件即回滚，不要在现场继续「边修边试」：

• verify 失败且 15 分钟内无法定位；
• 升级后核心页面/接口 5xx 持续；
• migration 造成数据错误或不可逆变更；
• 安全/凭据事件需要立即回到已知安全版本。

1. 先止血

1. 在控制台/状态页确认影响范围（实例、域名、版本、授权状态）。
2. 停止继续升级/重试；记录当前 Version ID、错误码、发生时间。
3. 如果问题是新版本引入，保留现场日志（wrangler tail），不要先清空。

2. 代码回滚

# 查看最近部署
pnpm exec wrangler deployments list --env <env>

# 回到上一个可用版本（按 wrangler 当前版本语法）
pnpm exec wrangler rollback <previous-version-id> --env <env>

# 或重新部署上一版本产物
git checkout <previous-version>
./deploy.sh <env> build
./deploy.sh <env> deploy

回滚后立即跑：

./deploy.sh <env> verify
curl -sS https://<domain>/api/health

3. 数据回滚（谨慎）

D1 migration 默认只向前；不要假设 down() 一定安全。

• 先确认 migration 是否破坏性（删表/删列/改类型）；
• 有备份：按 wrangler d1 import / 平台备份流程恢复到新库，再切 binding；
• 无备份：停止写入，联系平台架构师评估，不要手工改生产表结构。

BIZ 平台的 20261107_125714_plan_i18n 这类含 DROP COLUMN 的迁移，

执行前必须先导出备份；down() 只是辅助，不替代备份。

4. 回滚后核对

• /api/health 200，migrationCount 与回滚目标一致；
• 首页/定价/控制台/CRM/工单入口可打开；
• 授权 pull 正常，订单/工单无重复或丢失；
• 通知 outbox 不积压（如启用邮件）。

5. 复盘与记录

记录：触发条件、回滚版本、数据恢复方式、影响时长、根因、后续修复项。 若回滚涉及数据恢复，必须通知客户并给出下一次升级窗口。