需要安全发布并验证回滚时用：用功能开关、渐进发布、金丝雀…

在发布过程中通过功能开关、金丝雀/渐进发布、护栏指标、生产冒烟测试和暗发布来安全验证生产环境，并确保回滚可验证。

适用场景

解决思路

1. 避免在没有功能开关、没有对比基线、没有已验证回退路径的情况下直接发布到 100% 用户。
2. 先检查 `.agents/qa-project-context.md`；若存在，把它作为上下文，跳过其中已回答的问题。
3. 盘点功能开关系统：是否有平台（LaunchDarkly、Statsig、GrowthBook、Unleash、Flagsmith、Harness FME、自定义、无），如何管理（看板、配置文件、环境变量），能否按用户/百分比/分组定向，当前活跃开关数量及清理流程。
4. 盘点发布能力：能否只发布到一部分流量（金丝雀基础设施、加权路由、功能开关），部署和回滚各需多久，是否有蓝绿或滚动部署，能否按地区/用户群/百分比路由流量。
5. 盘点监控成熟度：现有可观测性（APM、日志、错误跟踪、指标），是否有错误率/延迟/业务指标看板，告警阈值是否合理，能否实时比较金丝雀与基线指标。
6. 盘点生产访问与安全：谁有生产访问权、是否有审批流程、是否有专用生产测试账号、能否在不影响真实用户数据的情况下在生产执行操作、是否有生产事故响应流程。
7. 将生产视为最终测试环境：不要只依赖 staging 近似生产，要验证真实数据量、流量、第三方集成、基础设施差异和用户行为，但必须安全进行。
8. 控制爆炸半径：每个生产测试先回答“出错会影响多少用户”，并通过功能开关、金丝雀部署、流量拆分把影响面从 100% 缩小到 1% 或更低。
9. 始终准备并验证回滚：测试前确定、测试并确保回滚机制足够快；“关闭开关”是好的回滚方案，“重新部署上一版本”可接受，“到时候再想”不是方案；未触发过的回滚只是假设。
10. 把监控作为前置条件：无法实时测量错误率、延迟和业务指标就不能做生产测试；先补齐监控缺口。
11. 保证生产测试非破坏性：不得破坏真实用户数据、给真实用户发通知、扣真实付款方式，或产生需要手工清理的副作用；必须使用合成账号、测试开关和隔离资源。
12. 功能开关测试：对每个带开关的功能同时测试 ON 和 OFF 两种状态；flag-off 路径就是回滚路径，必须无损。
13. 使用 `setFeatureFlag(name, true|false, { userId: TEST_USER_ID })` 驱动 ON/OFF 两条路径的测试；参考 `references/patterns.md` 中的完整 ON/OFF 测试对。
14. 测试开关生命周期：Created → Targeting internal users → Canary (1%) → Partial (10-50%) → Full (100%) → Cleanup (removed)，并验证每个阶段。
15. 内部阶段：功能对内部账号可用且对外部用户隐藏。
16. 金丝雀阶段：flag-on 与 flag-off 队列的指标可比较。
17. 部分发布阶段：在规模下没有性能退化。
18. 全量阶段：所有用户分群都正常工作。
19. 清理阶段：移除开关后的代码行为与 flag-on 一致。
20. 清理陈旧开关：每周 CI job 查询开关提供方，找出 100% 已发布且超过 14 天的开关，作为代码清理候选。
21. 清理陈旧开关时，移除开关分支逻辑并仅保留启用路径；只移除开关不移除死代码等于只做了一半清理。
22. 开关组合测试：多个开关交互时，只测试真正重要的组合，不要测试全部 2^N 组合。
23. 聚焦影响同一用户流程的开关（例如 `new-checkout`、`express-pay`、`discount-engine-v2` 都触及 checkout），挑选关键组合：全开、一个代表性混合状态、全关/全旧。
24. 参考 `references/patterns.md` 获取组合测试循环。
25. 渐进发布：在手写 `rollout-policy` YAML 前，先检查平台是否已有原生金丝雀分析：LaunchDarkly Guarded Rollouts、Statsig Auto-tune、Argo Rollouts AnalysisRun、Flagger、Harness Continuous Verification；有则优先使用，因为与指标和回滚机制集成更便宜。
26. AI 功能发布：把模型变体和 prompt 作为开关值，加入成本护栏和 kill switch；LaunchDarkly AI Configs / AgentControl 是文档化路径；完整模式见 `release-readiness`。
27. 金丝雀阶段：Canary 1% 流量，保持 15-30 分钟，检查错误率、崩溃率、异常。
28. 早期采用者阶段：10% 流量，保持 1-2 小时，检查延迟 P95、转化率。
29. 部分发布阶段：50% 流量，保持 2-4 小时，检查所有护栏和业务指标。
30. 全量阶段：100% 流量，监控 24 小时，检查长尾问题和批处理任务兼容性。
31. 自动推进和回滚：定义机器可检查的进阶条件，包括 `hold_duration` 和指标条件（`error_rate_5xx < 0.5%`、`latency_p95 < 500ms`、`crash_rate == 0`）。
32. 自动回滚在护栏被突破时触发，无需人工批准：`error_rate_5xx > 2x_baseline for 5m`、`latency_p99 > 3x_baseline for 5m`、`crash_rate > 0.1% for 2m`，并通知 on-call。
33. 用错误预算燃烧率（error-budget burn rate）做门禁，而不只是原始倍数，以捕获仍会打爆 SLO 的缓慢燃烧。
34. 参考 `references/rollout-policy.md` 获取完整推进 YAML、回滚触发器和 SLO 门禁配置。
35. 验证回滚确实触发：自动回滚触发不等于事故已解决；回滚后不要宣布“已恢复”，除非确认系统真的回来了。
36. 回滚确认第 1 步：对生产重新运行健康检查冒烟测试（`GET /api/health` 返回 `healthy` 和上一个 `version`）。
37. 回滚确认第 2 步：查询开关平台确认开关已关闭（或部署平台确认正在服务上一个构建），不要假设。
38. 回滚确认第 3 步：确认护栏指标回到基线——错误率、P99 延迟和崩溃率回到部署前窗口内。
39. 回滚确认第 4 步：确认回滚通知到达 on-call（Slack/PagerDuty），让事故有人负责。
40. 只有以上四项全部成立，回滚才算验证通过；参见 Verification。
41. 生产冒烟测试：每次部署后立即运行，作为流水线阶段（不只是部署前 CI）。
42. 冒烟测试验证核心功能在生产配置、数据和基础设施下工作：`/api/health` 检查、使用合成凭据的认证流程、核心数据加载、搜索。
43. 为冒烟测试配置 `retries: 1` 和 `timeout`，避免一次不稳定运行在首次波动时阻塞流水线。
44. 参考 `references/patterns.md` 获取完整的 `production-smoke.spec.ts`。
45. 合成用户账号：必须能与真实用户明确区分，使用保留邮箱模式 `smoke-test+{env}@yourcompany.com`、`is_synthetic = true` 标记，并从分析、计费和邮件营销中排除。
46. 通过 admin API 创建合成账号，优先使用短时 OIDC / workload-identity token，而不是长期密码。
47. 参考 `references/patterns.md` 获取完整约定。
48. 非破坏性断言：生产冒烟测试必须只读，不写；无法避免写入时，在 fixture teardown 中清理，使清理无论测试通过或失败都运行。
49. 不要在 `test()` 体内调用 `test.afterEach()`；Playwright 在 describe/file 作用域注册 hook，测试中途注册不会安排 teardown，并抛出 `test.afterEach() can only be called in a describe block`，导致数据泄漏。
50. 使用自动清理 fixture：记录创建的资源 ID，并在 teardown 删除；一次性脚本可用 `try/finally`。
51. 参考 `references/patterns.md` 获取基于 fixture 的 create-verify-cleanup 模式。
52. 护栏指标：错误类别—HTTP 5xx 速率，对比部署前基线，>2x baseline for 5 min 告警。
53. 错误类别—未处理异常数，对比部署前基线，出现任何新异常类型即告警。
54. 延迟类别—P50 响应时间，对比部署前基线，>1.5x baseline 告警。
55. 延迟类别—P95 响应时间，对比部署前基线，>2x baseline 告警。
56. 延迟类别—P99 响应时间，对比部署前基线，>3x baseline 告警。
57. 业务类别—转化率，对比 7 天平均值，下降 >5% 告警。
58. 业务类别—每会话收入，对比 7 天平均值，下降 >10% 告警。
59. 客户端类别—移动端崩溃率，对比上一版本，增加 >0.1% 告警。
60. 客户端类别—JavaScript 错误率，对比部署前基线，>2x baseline 告警。
61. 基础设施类别—CPU 利用率，绝对阈值，持续 >80% 告警。
62. 基础设施类别—内存利用率，绝对阈值，持续 >85% 告警。
63. 基线比较：金丝雀指标应与运行上一版本的控制组比较，而不是只与历史数据比较。
64. 比较方法从好到差：1) 金丝雀 vs 控制组：拆分流量并实时比较（最好）；2) 前后对比：部署后指标对比部署前窗口（好）；3) 历史对比：对比上周同一时间（可接受用于趋势）；4) 绝对阈值：固定阈值无视基线（脆弱）。
65. 统计显著性：业务指标（转化、收入）小样本会产生噪声，得出结论前等待统计显著性。
66. 最小样本量：错误率 1,000 请求；延迟 500 请求；转化率 5,000 会话；崩溃率 10,000 次应用启动。
67. 经验规则：如果 1% 流量下 30 分钟内无法达到显著性，则提高到 5% 或延长保持窗口。
68. Dark launch 流量影子：把传入请求复制到新服务；比较响应但不把新响应返回给用户。
69. 请求流：User → Load Balancer → Production Service（返回响应给用户）；同时 Shadow Service 处理请求、记录结果、丢弃结果。
70. 影子比较内容：响应状态码——shadow 应与 production 匹配。
71. 影子比较内容：响应体——做语义等价 diff（忽略 timestamp、ID）。
72. 影子比较内容：延迟——shadow 不应显著更慢。
73. 影子比较内容：错误率——shadow 不应产生更多错误。
74. 并行执行：对迁移（新数据库、新算法、新服务），在生产同时运行旧路径和新路径；旧路径返回用户结果，新路径异步运行、记录差异并丢弃结果。
75. 跟踪匹配率，目标切换前达到 99%+ 匹配。
76. 影子发布时间线：第 1 周部署 shadow 并开始比较，预期 <50% 匹配。
77. 第 2 周修复不匹配，匹配率应升至 90%+。
78. 第 3 周匹配率稳定在 99%+，处理剩余边缘情况。
79. 第 4 周切换：shadow 成为主路径，旧路径成为 shadow。
80. 第 5 周在稳定 1 周后移除旧路径。
81. 反模式修复：无监控就做生产测试——先验证能实时看到错误率、延迟和关键业务指标，并在第一次测试前设置告警。
82. 无回滚计划——每个生产测试或发布都要有文档化回滚机制，执行时间 <5 分钟（关闭功能开关、上一部署、流量重路由），并有验证步骤确认系统确实恢复。
83. 破坏性生产测试——使用标记为测试数据的合成账号；支付和邮件使用 sandbox 模式；在 fixture teardown 中清理；如果无法非破坏性，就不要放在生产。
84. 只在成功时清理——把 teardown 放在 auto-cleanup fixture 或 `finally` 块，使通过和失败都运行。
85. 用生产测试替代预生产——维护可用的预生产环境；生产测试只验证只有生产能验证的内容：真实流量、真实数据量、真实第三方集成。
86. 金丝雀无比较——始终把金丝雀指标与基线比较，使用并排看板或自动金丝雀分析工具（Kayenta、Argo Rollouts analysis）。
87. 陈旧功能开关——每个开关创建时设置过期日期；全量发布 +2 周稳定后移除开关和死分支；跟踪开关年龄并在超过过期时告警。
88. 验证回滚路径：在首次生产使用前证明回滚确实会触发；未触发过的回滚只是假设。
89. 验证第 1 步：在 staging 触发护栏——在接入相同 `automatic_rollback` 策略的 staged rollout 上注入失败（例如强制 `error_rate_5xx` 超过 `2x_baseline`，或让健康检查连续失败 3 次），确认回滚动作在 `for:` 窗口内触发。
90. 验证第 2 步：确认恢复状态——重新运行健康检查冒烟测试并断言 `status === 'healthy'` 和上一个 `version`；查询开关平台/部署，确认正在服务上一个构建，不要假设。
91. 验证第 3 步：确认指标恢复——错误率、P99 延迟、崩溃率回到部署前窗口内。
92. 验证第 4 步：确认通知已发出——回滚告警到达 on-call 渠道（Slack/PagerDuty）。
93. 验证第 5 步：冒烟测试已接入流水线——对 staging 运行部署 job，确认部署后冒烟阶段执行并门禁推进；`npx playwright test production-smoke.spec.ts` 退出 0。
94. 如果第 1-4 步无法在 staging 演示，则回滚未验证，发布未就绪。
95. Agent 快捷方式：使用 LaunchDarkly、GrowthBook、Unleash、Flagsmith、Statsig、Harness FME 的 vendor MCP servers，让 AI agent 在这些检查中直接翻转开关和读取发布指标，而不是手工操作看板。
96. 完成条件：功能开关发布计划要文档化，包含明确百分比步骤（1% → 10% → 50% → 100%）和每个阶段命名的护栏指标。
97. 完成条件：配置金丝雀分析自动通过/失败标准，使推进和回滚决策不需要手工比较指标。
98. 完成条件：生产冒烟测试作为每次部署的流水线阶段运行（不只是 CI 预部署），并且该阶段对生产退出 0。
99. 完成条件：回滚触发条件已定义、文档化，并在首次生产使用前通过 Verification 的 staging dry-run 演示正确触发（护栏触发 → 回滚触发 → 确认恢复状态和指标）。
100. 完成条件：生产测试数据策略已文档化，说明使用合成用户还是匿名化真实用户，以及如何从分析和计费中排除。
101. 参考文件：`references/rollout-policy.md` 包含完整推进条件 YAML、自动回滚触发器和错误预算/SLO 门禁配置。
102. 参考文件：`references/patterns.md` 包含 flag ON/OFF 与组合测试、`production-smoke.spec.ts` 测试套件、合成账号约定，以及基于 fixture 的非破坏性 create-verify-cleanup 模式。

适用边界 · 注意事项

• 不适用于发布完成后持续运行的定时探针/SLA 监控；这类需求使用 `synthetic-monitoring`。
• 不适用于根据生产遥测设计新测试；这类需求使用 `observability-driven-testing`。
• 不应用于替代预生产测试；如果 staging 坏了，应先修 staging，而不是把生产当作唯一可用环境。