关于 launch-runbook
面向网站、产品和重大版本发布的技术栈无关型技能，将准备、切换、验证和稳定阶段纳入统一运行手册，并明确角色、回滚条件与沟通安排。
主要功能
- 01四阶段发布计划
- 02含负责人和验证的切换步骤
- 03回滚条件与流程
- 04角色分工与沟通安排
- 05首周稳定性检查
适用场景
- 01协调跨团队产品发布
- 02规划网站迁移
- 03准备可复用的部署运行手册
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/launch-runbook确认已加载。
附带文件README.mdreferences/runbook-template.md
详细介绍
发布操作手册
规划并执行网站、产品或重大版本的发布。操作手册是所有人在发布当天都会使用的文档。不依赖特定技术栈。
此技能用于发布活动。发布前 QA 请使用 qa-testing。发布后事故处理请使用 incident-response。
适用场景
- 发布新网站或进行重大重新设计
- 从一个平台迁移到另一个平台
- 发布重大产品或功能
- 协调跨团队发布
- 为定期部署编写操作手册
不适用场景
- 发布前测试（使用
qa-testing） - 发布后事故响应（使用
incident-response） - 发布后复盘（使用
after-action-report）
必需输入
- 发布范围（要发布什么）
- 发布窗口（日期、时间、时长）
- 团队（角色、值班轮班安排）
- 回滚标准（何时中止）
- 沟通计划（谁在何时向谁传达什么）
框架：4 个阶段
发布分为四个阶段。操作手册涵盖全部四个阶段。
阶段 1：发布前（T-30 天至 T-1 小时）
在发布窗口开始前，确认所有事项均已准备就绪。
T-30 天：
- 锁定最终范围
- 确认跨团队承诺
- 安排发布前 QA
- 起草沟通计划
T-7 天：
- 完成发布前 QA
- 解决所有严重和主要问题
- 测量性能基线
- 记录并测试回滚流程
- 降低 DNS TTL（如果发布涉及 DNS 变更）
T-1 天：
- 举行最终的继续/中止会议
- 确认角色
- 设置沟通渠道
- 备份当前生产环境状态
T-1 小时：
- 团队成员齐聚共享沟通渠道
- 验证工具和访问权限
- 在预发布环境进行最终冒烟测试
阶段 2：切换（T-0）
正式发布。按顺序执行各步骤，并明确负责人和验证方式。
标准切换步骤：
- 向内部团队宣布开始
- 启用维护模式（如适用）
- 执行最终数据库迁移（如适用）
- 将代码部署到生产环境
- 确认部署完成且无错误
- 在生产环境运行冒烟测试
- 切换 DNS（如适用）
- 确认 DNS 已传播
- 关闭维护模式
- 在生产环境运行完整冒烟测试
- 向内部团队宣布发布完成
- 开始监控窗口
每个步骤都应包含：
- 负责人
- 前置条件
- 操作
- 验证
- 预计耗时
- 回滚流程
阶段 3：验证（T+0 至 T+24 小时）
确认发布状态正常。
首小时内：
- 关键用户流程正常运行（结账、注册、登录）
- 错误率未激增
- 性能处于预期范围内
- 分析追踪正常触发
- 邮件和通知正常工作
首个 24 小时内：
- 关键业务指标未出现回退
- 错误模式未持续累积
- Core Web Vitals 保持稳定
- Search Console 未显示严重问题（如与 SEO 相关）
阶段 4：稳定（T+24 小时至 T+7 天）
监控后续情况。
- 逐日追踪错误率
- 逐日追踪性能
- 将关键业务指标与基线对比
- 处理发现的非阻塞问题
- 规划 AAR（行动后报告）
角色与职责
发布时应明确分配角色。角色含糊不清是发布混乱最常见的原因。
| 角色 | 职责 |
|---|---|
| 发布负责人 | 负责操作手册。决定继续或中止。决定回滚。 |
| 部署操作员 | 执行技术部署步骤。 |
| QA 负责人 | 执行验证测试并确认各里程碑。 |
| 沟通负责人 | 发布内部更新，管理对外沟通。 |
| 值班工程师 | 在发布期间及之后待命处理问题。 |
| 利益相关方代表 | 代表业务利益相关方批准发布。 |
对于小团队，一个人可以承担多个角色。但每个角色的职责仍应明确。
回滚标准
在上线前定义。提前做出决策比在压力下做决定容易。
自动回滚触发条件：
- 错误率超过正常水平的 X%
- 关键用户流程（已定义）中断
- 数据库完整性问题
- 部署后发现安全漏洞
酌情回滚触发条件：
- 性能下降超过 Y%
- 关键业务指标显著下降
- 面向客户的错误模式
**决策权限：**上线负责人决定是否回滚。预先指定上线负责人无法到场时代行职责的人选。
沟通计划
内部渠道
- **主要上线频道：**仅供上线团队使用的实时聊天频道
- **状态频道：**面向更广泛内部人员的更新
- **战情室：**高风险上线时可选的视频通话
上线期间的更新频率
- 切换期间每 15 分钟一次
- 验证阶段每小时一次
- 稳定阶段每天一次
外部沟通
- **面向客户的公告：**提前起草，在确认成功这一里程碑时按计划发布
- **状态页面：**如对用户造成任何影响，主动更新
- **支持团队：**提前说明上线内容、常见问题和升级处理路径
工作流
- **提前 30 天编写操作手册。**明确范围、顺序、角色、回滚标准和沟通计划。
- **测试回滚流程。**未经测试的回滚只是寄希望于成功，而非可靠流程。
- **开展桌面演练。**与完整团队一起逐步演练操作手册，找出缺漏。
- 在上线前 48 到 72 小时降低 DNS TTL（如果上线包含 DNS 变更）。
- **上线当天：**逐步执行操作手册。每一步都验证通过后再继续。
- **监控。**关注第一小时、第一天和第一周的情况。记录所有值得注意的事项。
- 在上线后 1 到 2 周内安排 AAR。
失败模式
- **操作手册由一人编写，未经评审。**单一视角会遗漏各种场景。
- **没有经过测试的回滚方案。**等到需要回滚时才发现它无法使用。
- **步骤描述含糊。**只写“部署到生产环境”，却不说明使用哪个工具、哪条命令、哪个环境。
- **每项操作后没有验证步骤。**错误会持续蔓延。
- **沟通脱节。**团队不知道正在上线，或不知道上线已成功。
- **在周五下班前上线。**或在节假日前上线。这会缩短可用于响应问题的时间。
- **为赶日期而跳过上线前 QA。**问题会在上线当天暴露。
- **上线疲劳。**长时间上线且没有休息会导致错误。多日上线时应规划休息轮班。
- **前 24 小时没有值班人员。**必须确保有人可以联系到。
输出格式
默认输出：位于 launch-runbook-[project].md 的 Markdown 操作手册，以及配套检查清单。
结构：
- 上线元数据（内容、时间、人员）
- 角色和职责
- 上线前检查清单（T-30、T-7、T-1、T-1 小时）
- 切换顺序（编号步骤、负责人、验证）
- 回滚流程
- 回滚标准（自动和酌情）
- 沟通计划
- 验证检查清单（第一小时、第一天）
- 稳定计划（第一周）
- 联系人（升级处理路径、值班人员）
参考文件
references/runbook-template.md- 可填写的操作手册模板，包含切换顺序示例。
评论
支持 Markdown