发布日执行

发布日的小时级剧本 — 谁做什么、何时监控、什么触发回滚、如何沟通状态。

为什么

发布日把数月工作压缩到几个高风险小时，没有书面剧本团队是反应而非执行。运行手册给每个动作指派负责人和钟点：09:00 部署、09:05 冒烟测试、09:30 公告、10:00 监控峰值。这消除了"我以为你在看 Sentry"的故障 — 没人认领关键任务。它还预先决定回滚触发条件 — 具体错误率或注册下降 — 让决策在冷静时做，而非 11:00 慌慌时做。有运行手册的团队 30 分钟发布完，剩下时间学习；没有的团队整天救火，永远到不了公告。

何时使用

在目标发布日、发布前清单全绿之后。从 T-0（部署时间）开始运行手册，跑到 T+4h（发布后稳定）。

如何做

1. T-30 分钟：最终 go/no-go 会议 — 确认清单全绿、回滚负责人在岗、沟通负责人就绪、状态页为绿
2. T-0：部署到生产（wrangler pages deploy），在运行手册频道记录 SHA
3. T+2 分钟：对生产跑自动冒烟测试（Playwright/Cypress）；任何关键旅程失败则立即回滚
4. T+5 分钟：看 Sentry 错误率和 Cloudflare 仪表盘 10 分钟；错误率 > 1% 或 5xx > 0.5% 则触发回滚
5. T+15 分钟：发发布公告（博客 + 社交 + 邮件 + Product Hunt 如适用）；沟通负责人确认每个渠道上线
6. T+30 分钟：监控注册率、服务器负载、支持收件箱；值班工程师看仪表盘，支持负责人看收件箱
7. T+1 小时：第一次状态站会（15 分钟）— 复盘指标、决定是否需要热修、有降级则更新状态页
8. T+2 小时：第二次站会 — 此时发布峰值已可见；注册 > 目标且错误 < 阈值则宣布发布成功
9. T+4 小时：解散作战室；值班转回正常排班；24 小时内写发布日复盘

示例

# 发布日运行手册 — ez4code v2.0
日期：2026-10-05  作战室：#launch-warroom

## 角色
部署：@dev-lead  冒烟：@qa  监控：@sre
沟通：@marketing  支持：@support-lead  回滚负责人：@cto

## 时间线
09:00 T-30  Go/no-go：全绿 ✓
09:30 T-0   部署 SHA a1b2c3d → 生产
09:32 T+2   冒烟测试：12/12 旅程通过 ✓
09:35 T+5   Sentry 0.02%，5xx 0% — 阈值内 ✓
09:45 T+15  公告：博客上线、Twitter 已发、邮件已发、PH 已提交
10:00 T+30  注册：47（目标 30），负载 0.3 CPU，0 支持工单
10:30 T+1h  站会：正轨，无需热修
11:30 T+2h  注册：189，错误 0.03% → 发布成功
13:30 T+4h  解散；复盘安排在 2026-10-06

## 回滚触发
错误率 > 1% 持续 5 分钟  或  注册 < 目标 50% 持续 15 分钟
回滚命令：wrangler pages deploy dist_astro --branch=prev
决策：@cto（可达：Slack + 电话）

常见问题

⚠无指定回滚负责人 — 指标变红时三人争论是否回滚，用户持续撞 bug；预先指派一个有权限和命令的人。
⚠冒烟测试通过前就公告 — 营销推文 09:00 发出但部署 09:01 弄坏注册；顺序必须是部署 → 验证 → 公告，绝不公告 → 部署。
⚠只看部署仪表盘不看支持收件箱 — 用户在支持报 bug 比 Sentry 出现早 10 分钟；支持负责人是你最快的错误探测器。
⚠无作战室 — 团队散在 Slack 私信里没人有全貌；一个含所有角色的单一频道（或物理房间）是协调发布的唯一方式。

最佳实践

✓把运行手册写成钟点文档而非任务列表 — "09:30 部署"无歧义，"准备好就部署"不是；钟点强制决策并立即暴露滑期。
✓预先排好公告内容（博客草稿、社交帖、邮件）到调度工具，沟通负责人在 T+15 点一个按钮，而非在压力下撰写。
✓把回滚触发定义为数值阈值而非感觉 — "错误率 > 1% 持续 5 分钟"任何看仪表盘的人都能判定；"看起来不好"不能。
✓发布前 2 天做一次彩排 — 部署到 staging URL，走完整个运行手册并计时；彩排会暴露冒烟测试要 8 分钟而非 2 分钟。