生产发布前检查、功能开关灰度发布与可回滚上线：在首次上线…

适用于准备部署到生产、需要预发布清单、设置监控、规划分阶段 rollout 或制定回滚策略的场景。

适用场景

解决思路

1. 所有测试通过（unit、integration、e2e）。
2. 构建成功且无 warnings。
3. Lint 和 type checking 通过。
4. 代码已 review 并 approved。
5. 没有应在发布前解决的 TODO 注释。
6. 生产代码中没有 console.log 调试语句。
7. 错误处理覆盖预期失败模式。
8. 代码或版本控制中没有 secrets。
9. 生态依赖审计（`npm audit`、`pip-audit`、`cargo audit` 等）没有 critical 或 high 漏洞。
10. 所有面向用户的端点有输入验证。
11. 认证和授权检查到位。
12. 配置安全 headers（CSP、HSTS 等）。
13. 认证端点有 rate limiting。
14. CORS 配置为具体 origins（不是 wildcard）。
15. Core Web Vitals 在 Good 阈值内。
16. 关键路径没有 N+1 queries。
17. 图片优化（压缩、响应式尺寸、懒加载）。
18. Bundle size 在预算内。
19. 数据库查询有合适的 indexes。
20. 静态资产和重复查询配置 caching。
21. 所有交互元素支持 keyboard navigation。
22. 屏幕阅读器能传达页面内容和结构。
23. 颜色对比度满足 WCAG 2.1 AA（文字 4.5:1）。
24. 模态框和动态内容的 focus management 正确。
25. 错误消息具有描述性并关联到表单字段。
26. axe-core 或 Lighthouse 中没有 accessibility warnings。
27. 生产环境变量已设置。
28. 数据库迁移已应用（或准备好应用）。
29. DNS 和 SSL 已配置。
30. CDN 为静态资产配置。
31. Logging 和 error reporting 已配置。
32. Health check endpoint 存在并能响应。
33. README 已更新任何新的 setup requirements。
34. API 文档是最新的。
35. 为任何架构决策写了 ADRs。
36. Changelog 已更新。
37. 用户文档已更新（如适用）。
38. 通过 feature flag 发布以解耦 deployment 和 release：查询 `getFeatureFlags(userId)`，如果 `flags.taskSharing` 为真则返回新功能 `TaskSharingPanel`，否则返回现有默认行为 `null`。
39. feature flag 生命周期第 1 步：DEPLOY with flag OFF，代码进入生产但保持不激活。
40. feature flag 生命周期第 2 步：ENABLE for team/beta，在生产环境做内部测试。
41. feature flag 生命周期第 3 步：GRADUAL ROLLOUT，5% → 25% → 50% → 100% 用户。
42. feature flag 生命周期第 4 步：MONITOR at each stage，观察错误率、性能、用户反馈。
43. feature flag 生命周期第 5 步：CLEAN UP，全量发布后移除 flag 和 dead code path。
44. 每个 feature flag 有 owner 和 expiration date。
45. 全量发布后 2 周内清理 flags。
46. 不要嵌套 feature flags，避免指数级组合。
47. 在 CI 中测试 flag 的两种状态（on 和 off）。
48. 分阶段 rollout 第 1 步：DEPLOY to staging，在 staging 环境运行完整测试套件，手动 smoke test 关键流程。
49. 分阶段 rollout 第 2 步：DEPLOY to production（feature flag OFF），用 health check 验证部署成功，检查 error monitoring 没有新错误。
50. 分阶段 rollout 第 3 步：ENABLE for team（内部用户 flag ON），团队在生产使用该功能，24 小时 monitoring window。
51. 分阶段 rollout 第 4 步：CANARY rollout（5% 用户 flag ON），监控错误率、延迟、用户行为，比较 canary 与 baseline 指标，24-48 小时 monitoring window，只有所有阈值通过才推进。
52. 分阶段 rollout 第 5 步：GRADUAL increase（25% -> 50% -> 100%），每一步同样监控，能随时回滚到之前百分比。
53. 分阶段 rollout 第 6 步：FULL rollout（所有用户 flag ON），监控 1 周，清理 feature flag。
54. rollout 决策阈值-错误率：在 baseline 的 10% 以内则 Advance green；高于 baseline 10-100% 则 Hold and investigate yellow；超过 baseline 2 倍则 Roll back red。
55. rollout 决策阈值-P95 latency：在 baseline 的 20% 以内则 Advance green；高于 baseline 20-50% 则 Hold and investigate yellow；高于 baseline 50% 则 Roll back red。
56. rollout 决策阈值-Client JS errors：没有新错误类型则 Advance green；新错误低于 0.1% sessions 则 Hold and investigate yellow；新错误高于 0.1% sessions 则 Roll back red。
57. rollout 决策阈值-Business metrics：中性或正向则 Advance green；下降低于 5% 可能是 noise 则 Hold and investigate yellow；下降超过 5% 则 Roll back red。
58. 以下情况立即 roll back：错误率比 baseline 增加超过 2 倍。
59. 以下情况立即 roll back：P95 latency 增加超过 50%。
60. 以下情况立即 roll back：用户报告问题激增。
61. 以下情况立即 roll back：检测到数据完整性问题。
62. 以下情况立即 roll back：发现安全漏洞。
63. 监控 application metrics：错误率（总量和按 endpoint）、响应时间（p50、p95、p99）、请求量、活跃用户、关键业务指标（conversion、engagement）。
64. 监控 infrastructure metrics：CPU 和 memory utilization、数据库 connection pool usage、磁盘空间、网络延迟、队列深度（如适用）。
65. 监控 client metrics：Core Web Vitals（LCP、INP、CLS）、JavaScript errors、客户端视角 API error rates、页面加载时间。
66. 在客户端设置带 reporting 的 ErrorBoundary：在 `componentDidCatch(error, info)` 中调用 `reportError(error, { componentStack: info.componentStack, userId: getCurrentUser()?.id, page: window.location.pathname })`。
67. 客户端 ErrorBoundary 出错时渲染 `ErrorFallback`，并通过 `onRetry` 重置错误状态。
68. 在服务端错误处理 middleware 中调用 `reportError(err, { method: req.method, url: req.url, userId: req.user?.id })`。
69. 服务端向用户返回 500 和通用错误结构（如 `{ error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' } }`），不要暴露内部信息。
70. 发布后第一小时检查 health endpoint 返回 200。
71. 发布后第一小时检查 error monitoring dashboard 没有新错误类型。
72. 发布后第一小时检查 latency dashboard 没有 regression。
73. 发布后第一小时手动测试关键用户流程。
74. 发布后第一小时验证 logs 正在流动且可读。
75. 发布后第一小时确认 rollback 机制有效（如可能做 dry run）。
76. 使用错误预算作为发布门禁：预算剩余 > 20% 则正常发布并密切监控。
77. 预算剩余 0–20% 则只做 slow rollouts，不做 high-risk changes。
78. 预算耗尽则 freeze feature work，全力关注 reliability。
79. 预算重置则恢复正常节奏，并固化恢复预算的修复。
80. canary 期间 high burn rate（消耗预算快于 baseline 节奏）是 hold 信号，按 elevated error rate 同等处理。
81. 每次部署前写回滚计划，包含 Trigger Conditions：错误率 > 2x baseline、P95 latency > [X]ms、用户报告 [specific issue]。
82. 回滚步骤：如适用先禁用 feature flag。
83. 回滚步骤：或部署上一版本：`git revert <commit> && git push`。
84. 回滚后验证：health check、error monitoring。
85. 回滚后沟通：通知团队已 rollback。
86. 数据库注意事项：写明 migration [X] 是否有回滚，如 `npx prisma migrate rollback`。
87. 数据库注意事项：写明新功能插入的数据是 preserved 还是 cleaned up。
88. 回滚时间目标：feature flag < 1 分钟。
89. 回滚时间目标：redeploy previous version < 5 分钟。
90. 回滚时间目标：database rollback < 15 分钟。
91. 参考项目级 Definition of Done：`../../references/definition-of-done.md`。
92. 参考安全预发布检查：`../../references/security-checklist.md`。
93. 参考性能预发布检查：`../../references/performance-checklist.md`。
94. 参考可访问性验证：`../../references/accessibility-checklist.md`。
95. 参考告警规则和 SLO 相关阈值：`observability-and-instrumentation`。
96. 反驳“staging 能跑生产就能跑”：生产有不同数据、流量模式和边缘情况，部署后必须监控。
97. 反驳“不需要 feature flags”：每个功能都受益于 kill switch，即使简单变更也可能破坏东西。
98. 反驳“监控是 overhead”：没有监控只能从用户投诉发现问题，而不是 dashboard。
99. 反驳“以后再加监控”：发布前就要加，看不到就无法 debug。
100. 反驳“rollback 是承认失败”：rollback 是负责任的工程，发布坏功能才是失败。
101. 反驳“错误率看起来正常，继续发布”：检查 burn rate，而不只是当前错误率；即使单项阈值绿色，消耗预算快于 baseline 也是 hold 信号。
102. 红旗：没有 rollback plan 就部署。
103. 红旗：生产没有 monitoring 或 error reporting。
104. 红旗：big-bang releases（一次性全上，没有 staging）。
105. 红旗：feature flags 没有 expiration 或 owner。
106. 红旗：部署后第一小时没人监控。
107. 红旗：生产环境配置靠记忆而不是代码。
108. 红旗：周五下午发布。
109. 红旗：error budget 耗尽但 feature work 照旧继续。
110. 部署前验证：预发布清单完成（所有部分绿色）。
111. 部署前验证：feature flag 已配置（如适用）。
112. 部署前验证：rollback plan 已文档化。
113. 部署前验证：monitoring dashboards 已设置。
114. 部署前验证：团队已通知部署。
115. 部署后验证：health check 返回 200。
116. 部署后验证：error rate 正常。
117. 部署后验证：latency 正常。
118. 部署后验证：关键用户流程可用。
119. 部署后验证：logs 正在流动。
120. 部署后验证：rollback 已测试或确认 ready。
121. 每个已发布服务验证：有 error budget policy，知道预算低于 20% 和耗尽时采取什么行动。

适用边界 · 注意事项

• 不适用于纯本地原型、一次性实验或没有生产用户、生产流量和生产数据影响的项目。
• 如果团队没有能力或权限配置监控、错误上报、feature flag 或部署回滚，不应直接套用完整发布流程。
• 当变更完全不可逆且没有数据库或基础设施回滚路径时，不应按本经验直接发布，需要先设计补偿或迁移方案。