发布前需要 go/no-go 决策、冒烟验证和回滚方案时…

用证据驱动的 go/no-go 清单、快速冒烟测试、分阶段发布、预定义回滚标准和部署后验证来决定是否发布并安全发布。

适用场景

解决思路

1. 先检查 `.agents/qa-project-context.md`；若存在则直接使用并跳过其中已回答的问题，只补充询问缺失信息。
2. 询问发布频率和谁做 go/no-go 决策，以决定清单重量级。
3. 询问是否有 release train 时间表，还是临时发布。
4. 询问 dev 到 production 之间有哪些环境（staging、pre-prod、canary）。
5. 询问当前 go/no-go 流程是什么、是否已文档化。
6. 询问是否回滚过、回滚耗时多久，以判断回滚是否真实可用。
7. 询问上次发布事故及根因，以及当前是否有阻塞发布的 bug。
8. 询问是否具备回滚能力以及回滚耗时。
9. 询问能否做 staged/canary 部署。
10. 询问是否有 feature flags 以及如何管理，决定用 flag 还是基础设施级发布。
11. 询问监控告警是否到位，数据库迁移是否可逆。
12. 询问发布期间和发布后谁 on-call。
13. 询问如何通知干系人、是否有发布沟通频道。
14. 询问 release notes 如何生成。
15. 坚持发布信心来自证据而非感觉：列出并检查所有 CI 流水线绿色、staging 冒烟测试通过、性能预算达标、无未解决 P0/P1。
16. 如果无法指向数据，则判定未就绪。
17. 把冒烟测试当作最后一道安全网，而不是唯一安全网；若它是你和生产之间唯一防线，视为上游流程问题。
18. 用分阶段发布缩小爆炸半径：可 canary、按百分比、按 ring。
19. 在发布前定义回滚标准，并相对于基线；将触发条件绑定 DORA 目标。
20. 把每次发布当学习机会：跟踪顺利/缓慢/压力点并持续改进流程。
21. 使用 go/no-go 清单模板并按上下文调整；每项必须有证据而非“我检查过”。
22. 将完成的清单存为版本化制品（如 `RELEASE-<version>.md` 或受跟踪 issue），使签核可审计。
23. 自动检查必须通过：所有 CI 流水线绿色（单元、集成、E2E、类型检查、lint）。
24. 自动检查必须通过：staging 上冒烟测试套件通过，关键用户旅程在 staging 验证。
25. 自动检查必须通过：本发布无未解决 P0/P1 bug（按 milestone/label 过滤 issue tracker）。
26. 自动检查必须通过：性能预算达标，API 响应时间与 bundle size 在阈值内；前端发布跑 Lighthouse CI，API/后端-only 发布跳过 Lighthouse。
27. 自动检查必须通过：安全扫描干净，`npm audit` / Snyk / Dependabot 无 high/critical 漏洞。
28. 自动检查必须通过：API 契约测试通过，公共 API 无破坏性变更。
29. 自动检查必须通过：视觉回归测试通过，无意外视觉变更。
30. 自动检查必须通过：无障碍检查通过，axe-core 扫描无新增违规。
31. 手动检查：审查 feature flags，记录本发布启停哪些 flag，并确认生产 flag 状态。
32. 手动检查：为新功能配置监控和告警（错误率、延迟、业务指标）。
33. 手动检查：回滚计划已文档化并在 staging 演练过。
34. 手动检查：数据库迁移已测试；测试 forward migration，若 schema 变更可逆则验证 backward migration。
35. 手动检查：审查第三方依赖变更，检查新增/升级外部依赖的破坏性变更。
36. 手动检查：准备 release notes，更新 changelog，写干系人摘要。
37. 手动检查：指定 on-call 工程师，确认其可用并了解发布内容。
38. 手动检查：沟通计划就绪，干系人知道发布发生，支持团队已了解变更。
39. 手动检查：确认无冲突发布，其他团队不同时部署。
40. 手动检查：确认部署窗口，不在高峰流量或周末前部署（除非持续部署）。
41. 风险评估：分类变更范围：小（配置、文案）、中（新功能、重构）、大（架构变更、迁移）。
42. 风险评估：估算爆炸半径，即出错时可能影响多少百分比用户。
43. 风险评估：评估回滚复杂度，能否 <5 分钟回滚，回滚是否需要数据迁移。
44. 设计冒烟测试只覆盖关键用户旅程；若它们失败，应用根本性损坏。
45. 典型冒烟套件 5-8 个测试：应用健康（首页加载、200、无 JS 控制台错误）。
46. 典型冒烟套件：认证（有效凭据登录，建立会话）。
47. 典型冒烟套件：核心工作流（主要价值动作可用，如创建文档、提交表单、加购或完成购买）。
48. 典型冒烟套件：数据读取（关键数据正确加载，如 dashboard 填充、搜索返回结果、产品页加载）。
49. 典型冒烟套件：支付/交易（如适用，用测试凭据完成支付流程）。
50. 典型冒烟套件：API 健康（主要 API 端点返回有效响应且 schema 正确）。
51. 典型冒烟套件：导航（关键导航路径可用，如 deep link、redirect、menu item）。
52. 典型冒烟套件：错误处理（无效路由显示用户友好错误页，404）。
53. 冒烟测试不包含：边界情况（放回归测试）。
54. 冒烟测试不包含：视觉完美（放视觉回归测试）。
55. 冒烟测试不包含：性能基准（放性能测试）。
56. 冒烟测试不包含：穷尽表单验证（放单元/集成测试）。
57. 保持冒烟套件快速：目标整个套件 <5 分钟。
58. 尽可能并行运行测试。
59. 用 API 调用而非 UI 交互做 setup（通过 API 创建测试用户，而不是走注册表单）。
60. 跳过非关键断言（不检查精确文案，检查元素存在）。
61. 使用专用测试账号和预创建数据（不要每次从零创建数据）。
62. 避免不必要等待，使用智能等待（等待元素，而不是 `sleep(3000)` / `waitForTimeout`）。
63. staging 冒烟：跑完整套件（全部 5-8 个测试）。
64. staging 冒烟：可使用测试支付提供商。
65. staging 冒烟：可用即将发布的 feature flag 配置测试。
66. staging 冒烟：可测试数据库迁移。
67. production 冒烟：跑 staging 的子集（3-5 个测试）。
68. production 冒烟：使用合成测试账号（明确标注，不影响 analytics）。
69. production 冒烟：绝不使用真实支付交易（用 sandbox 模式或跳过）。
70. production 冒烟重点：应用加载、认证可用、核心读操作可用、API 有响应。
71. post-deployment 冒烟：部署完成后立即运行（60 秒内）。
72. post-deployment 冒烟：与 production 冒烟相同。
73. post-deployment 冒烟：任何失败触发告警并开始回滚评估。
74. 记住 staging 不是 production：数据量、流量模式、第三方配置、基础设施规模不同；因此需要 production 和 post-deployment 冒烟作为补充。
75. 分阶段发布阶段：Canary 1% 流量，15-30 分钟，捕捉崩溃、异常、明显失败。
76. 分阶段发布阶段：Early adopters 10% 流量，1-2 小时，验证错误率、延迟、业务指标。
77. 分阶段发布阶段：Partial rollout 25-50% 流量，2-4 小时，确认规模稳定。
78. 分阶段发布阶段：Full rollout 100%，之后监控 24 小时；基于 flag 的发布可加 25% 步骤。
79. 每阶段提升前监控错误指标：HTTP 5xx 错误率不高于基线。
80. 每阶段提升前监控错误指标：异常数量不高于基线。
81. 每阶段提升前监控错误指标：日志中无新错误类型。
82. 每阶段提升前监控性能指标：P50 和 P95 延迟可接受（相对基线，而非绝对上限）。
83. 每阶段提升前监控性能指标：超时错误不增加。
84. 每阶段提升前监控性能指标：数据库查询时间稳定。
85. 每阶段提升前监控业务指标：转化率不下降。
86. 每阶段提升前监控业务指标：用户参与度（页面浏览、动作）稳定。
87. 每阶段提升前监控业务指标：收入/交易量正常（如适用）。
88. 每阶段提升前监控基础设施指标：CPU 和内存正常。
89. 每阶段提升前监控基础设施指标：队列深度或消息积压不增加。
90. 每阶段提升前监控基础设施指标：新日志不导致磁盘问题。
91. 定义自动晋升规则；每个 gate 组合错误率上限、相对基线的延迟上限、稳定窗口，以及更高阶段的业务指标 guardrail。
92. 使用参考 `references/rollout-automation.md` 获取 canary→10%→50%→100% 晋升规则集。
93. Feature flag 渐进发布：部署新代码到 100% 但 flag 关闭。
94. Feature flag 渐进发布：先对内部用户启用 flag（dogfooding）。
95. Feature flag 渐进发布：对 1% 用户启用（等价 canary）。
96. Feature flag 渐进发布：逐步提升 10%、25%、50%、100%。
97. Feature flag 渐进发布：全量发布稳定 1 周后移除 flag。
98. 了解 flag 发布优势：回滚更快（翻转 flag）、无需基础设施变更、可定向用户群。
99. 了解 flag 发布劣势：代码复杂度（分支逻辑）、陈旧 flag 成技术债、无法捕捉基础设施问题。
100. 若平台提供原生 canary 分析（如 LaunchDarkly Guarded Rollouts、Statsig Auto-tune、Flagger），优先使用，而不是手写 rollout-policy YAML。
101. 鉴于厂商变动，优先使用 OpenFeature 兼容 SDK（CNCF 规范），使 flag 工具可替换。
102. 发布 AI/LLM 功能：在 AI Configs 平台、自定义数据集或 feature-flag JSON 中固定 prompt template 版本和 model ID。
103. 发布 AI/LLM 功能：在 flag 后发布 prompt/model 组合，先内部，再 1%、10% 等。
104. 发布 AI/LLM 功能：按 cohort 观察 eval 指标（hallucination rate、jailbreak success rate、cost per request），而不仅是错误率。
105. 发布 AI/LLM 功能：设置成本护栏，当模型每请求成本飙升时 budget circuit breaker 优雅降级（fail open）。
106. 发布 AI/LLM 功能：设置 kill switch，单个 flag 禁用 AI 路径并路由到确定性 fallback 或“功能不可用”状态，并在 staging 测试。
107. 参考 `ai-system-testing` 获取 prompt 级 eval 测试模式，参考 `testing-in-production` 获取 canary 指标设计。
108. 在部署前定义自动回滚触发阈值，触发时自动开始回滚；阈值相对测量基线，非绝对上限。
109. 自动回滚触发：5xx 错误率 >2x 基线持续 5 分钟 → 自动回滚。
110. 自动回滚触发：P95 延迟 >3x 基线持续 5 分钟 → 自动回滚。
111. 自动回滚触发：健康检查连续 3 次失败 → 自动回滚。
112. 自动回滚触发：移动端崩溃率 >0.5% → 自动回滚。
113. 自动回滚触发：错误预算 1 小时内燃烧 >50% → 自动回滚。
114. 手动回滚触发：客户报告关键问题，多位用户报告同一问题。
115. 手动回滚触发：数据完整性担忧，有损坏或错误数据证据。
116. 手动回滚触发：发现安全漏洞，正在被利用或高严重性 CVE。
117. 手动回滚触发：监控盲点，意识到无法监控新功能的关键指标。
118. 手动回滚触发：on-call 工程师判断；on-call 工程师始终有权触发回滚。
119. 回滚流程 Step 1 决定（<2 分钟）：确认是自动还是手动触发；若手动，检查是否满足回滚标准；满足则继续，不辩论。
120. 回滚流程 Step 2 执行（<5 分钟）：优先 kill switch；翻转受影响功能的专用 kill-switch flag；它与完整代码回滚不同，禁用单个能力而无需重部署；每次发布前在 staging 测试 kill switch，未测试的开关不算开关。
121. 回滚流程 Step 2：Feature flag 回滚，禁用新代码路径的 feature flag；当两者都存在时比 kill switch 慢（rollout flag 与 kill switch 是不同关注点）。
122. 回滚流程 Step 2：代码回滚，回退到上一个部署（重新部署上一 image/artifact）；用于问题不只限于单个 flagged 功能时。
123. 回滚流程 Step 2：数据库回滚，如适用运行 backward migration；若迁移不可逆，跳过并单独处理数据。
124. 回滚流程 Step 2：缓存失效，若旧版本会提供陈旧/错误数据，清理 CDN 和应用缓存。
125. 回滚流程 Step 3 验证（<5 分钟）：运行生产冒烟测试。
126. 回滚流程 Step 3：验证错误率回到基线。
127. 回滚流程 Step 3：检查回滚后的版本正确服务。
128. 回滚流程 Step 4 沟通（<10 分钟）：使用回滚公告骨架通知发布频道。
129. 回滚流程 Step 4：若影响用户，更新 status page。
130. 回滚流程 Step 4：向支持团队简报。
131. 回滚流程 Step 5 调查（下一个工作日）：做根因分析。
132. 回滚流程 Step 5：写一个本可捕获该问题的回归测试。
133. 回滚流程 Step 5：若缺少检查项，更新 go/no-go 清单。
134. 回滚流程 Step 5：安排修复并重新发布。
135. 使用回滚公告骨架：Subject: [Rollback] v{version} — {date} {time}；Status: ROLLED BACK；Reason: 一行原因（如 error rate 4x baseline within 8 min）；Impact: 谁受影响、多久；Current state: Running previous version v{prev_version}；Next steps: Root cause investigation: {owner}，Fix ETA: {estimate or 'investigating'}。
136. 迁移不可回滚时数据考虑：Forward-fix，在当前（有问题的）版本上部署修复而不是回滚。
137. 迁移不可回滚时数据考虑：Dual-write，迁移期间同时写旧/新 schema；回滚时丢弃新写入。
138. 迁移不可回滚时数据考虑：Shadow migration，后台迁移、验证、再切换；回滚只需停止切换。
139. 迁移不可回滚时数据考虑：Point-in-time recovery，从备份恢复数据库（最后手段，会丢失备份后变更）。
140. 部署后立即验证（0-15 分钟）：生产冒烟测试通过。
141. 部署后立即验证：错误率等于或低于部署前基线。
142. 部署后立即验证：错误追踪器中无新异常类型。
143. 部署后立即验证：健康检查端点返回 healthy。
144. 部署后立即验证：关键页面加载正确，手动抽查 2-3 个页面。
145. 短期验证（15 分钟-2 小时）：合成监控确认所有关键路径工作。
146. 短期验证：错误率趋势平稳或下降（不是上升）。
147. 短期验证：P50 和 P95 延迟在预期范围。
148. 短期验证：支持工单量不增加。
149. 短期验证：业务指标（转化、收入、注册）正常。
150. 短期验证：无内存泄漏或资源耗尽趋势。
151. 中期验证（2-24 小时）：夜间批处理任务成功完成（如适用）。
152. 中期验证：其他区域醒来时无时区相关问题。
153. 中期验证：邮件/通知投递正常。
154. 中期验证：第三方集成正常工作。
155. 中期验证：无逐渐性能退化。
156. 避免反模式“在 staging 上能跑”：staging 不是生产；用生产冒烟测试和分阶段发布补充 staging 验证。
157. 避免反模式“没有回滚计划”：文档化回滚流程，每季度演练，计时，做成清单而非部落知识。
158. 避免反模式“周五下午部署”：尽早在一周/一天部署；若必须周五，中午前部署并加监控。
159. 避免反模式“因为流水线绿就跳过冒烟测试”：CI 用测试环境测试数据；冒烟验证部署应用在生产配置、数据、基础设施下工作；冒烟不可协商；慢则提速，flaky 则修复，绝不跳过。
160. 避免反模式“大爆炸发布而非增量”：累积 6 周变更会更多破坏、更难定位、风险更高、回滚更久、压力更大；修复为更小更频繁发布，若不能持续部署，目标每周或双周小变更集。
161. 避免反模式“无部署后验证”：部署后走人，问题无人观察；修复为安排人监控 dashboard 30-60 分钟，设置合理阈值告警，运行部署后冒烟。
162. 避免反模式“回滚厌恶”：总想向前热修；修复为先回滚再调查；可用的旧版本优于损坏的当前版本。
163. 避免反模式“feature flag 堆积”：用 flag 安全发布但从不移除；修复为平台级陈旧检测而非日历提醒；用 GrowthBook stale-flag detection（代码引用）、LaunchDarkly archive flow 或 Flagsmith flag age telemetry 发现 N 周未触碰代码路径的 flag；配合季度审查，归档超阈值 flag 或记录 owner + 保留原因。
164. 避免反模式“canary 告警说谎”：自动回滚接上噪声大、迟到、部分聚合的指标；修复为像测试一样度量 canary 告警的假阳率和假阴率；运行 shadow 期，告警发布决策但不实际回滚；对比 ground truth 两周；只有假阳率低于容忍度后才提升为自动回滚。
165. 避免反模式“双边系统用 switchback 实验”：标准 A/B 在市场、网约车、广告拍卖等共享状态下 treatment 影响 control 时失败；修复为 switchback 设计，在短窗口（分钟到小时）让整个系统在 control/treatment 间交替；Statsig Switchback experiments（Feb 2026）可自动化常见场景；不要因损坏的 A/B 结果阻塞发布，改用正确设计重跑。
166. 部署完成后立即运行验证，最小检查优先；Health endpoint: `curl -s https://your-app.com/health | jq .`。
167. 用一条命令检查响应时间和状态：`curl -o /dev/null -s -w 'HTTP %{http_code} in %{time_total}s\n' https://your-app.com`。
168. 用 Sentry CLI 检查部署后新错误，应为空：`sentry-cli issues list --project your-project --query 'firstSeen:>15m'`。
169. 用 Datadog 比较服务部署前后 5xx 数量，必须不增加。
170. 验证通过标准：health 返回 `healthy`，状态 200 且在延迟预算内，Sentry 查询无新 issue，部署后 5xx 数量等于或低于部署前基线。
171. Done when：go/no-go 清单每项有证据并作为版本化制品存储（如 `RELEASE-<version>.md` 或受跟踪 issue），由指定 approver 带时间戳签核。
172. Done when：冒烟测试套件在 staging 对 release candidate 运行，全部通过（exit code 0）。
173. Done when：回滚标准记录为具体的相对基线阈值，且回滚流程至少在 staging 演练过一次。
174. Done when：分阶段发布计划定义流量百分比、每阶段晋升标准、每阶段 guardrail 指标。
175. Done when：部署后验证命令已运行并通过（health 200、无新 Sentry issue、5xx 等于或低于基线）。
176. 参考 `references/rollout-automation.md` 获取自动 canary→10%→50%→100% 晋升标准和部署后验证命令片段。
177. 参考 `references/communication-templates.md` 写发布或回滚公告：填空式发布和回滚模板。

适用边界 · 注意事项

• 不适用于在发布过程中应用安全发布技术本身（flags、canary、dark launch）；这些用 `testing-in-production`。
• 不适用于发布后持续运行的定时探针；这些用 `synthetic-monitoring`。
• 不适用于从生产遥测设计新测试；这些用 `observability-driven-testing`。