上线发布

要解决的问题

部署成功不等于发布成功。 构建通过、服务起来之后，用户可能正在经历错误率飙升或 P95 延迟翻倍，而团队只能等投诉进来才发现。这个技能要解决三类典型事故：

• 上线后没有监控，问题从用户反馈而不是仪表盘暴露
• 没有回滚预案，只能带着故障修，越改越糟
• 一次性全量发布，变更范围大到无法定位是哪一步引入的问题

核心能力与关键步骤

1. 上线前检查清单（Pre-Launch Checklist）

按六个维度逐项确认，全部 green 才允许部署：

• 代码质量：单测/集成/e2e 全通过，lint 与类型检查干净，无遗留 console.log 调试语句
• 安全：无硬编码密钥，npm audit 无 critical/high 漏洞，认证端点限流，CORS 限定具体来源而非通配
• 性能：Core Web Vitals 在 Good 区间，关键路径无 N+1 查询，bundle 体积在预算内
• 可访问性：键盘导航可用，色彩对比度达 WCAG 2.1 AA，axe-core 无警告
• 基础设施：生产环境变量就绪，数据库迁移已应用或可随时应用，健康检查端点存在且返回 200
• 文档：README、API 文档、Changelog 同步更新，架构决策有 ADR

2. 特性开关（Feature Flags）解耦部署与发布

• 每个开关必须有 owner 和过期日期，全量后 2 周内清理
• 不在 CI 里嵌套开关，CI 中测试开与关两种状态
• 开关即 kill switch，简单改动同样需要

3. 分阶段发布与阈值决策

按错误率、P95 延迟、客户端 JS 错误、业务指标四类阈值决定推进、暂停还是回滚：

• 错误率超过基线 2 倍、P95 延迟超过基线 50%、出现数据完整性问题或安全漏洞 → 立即回滚
• 任一阶段触发 red，不做再观察一会儿的妥协

4. 上线后首小时验证与回滚预案

发布前先确认回滚方案已文档化、监控面板已就位；发布后第一小时核对健康检查、错误率、延迟、关键用户流程、日志流转，并验证回滚路径可用。

适用边界

• 它是部署时刻的清单与决策框架，不替代项目级 Definition of Done，也与 references/ 下的 security / performance / accessibility 检查表配合使用
• 阈值基于自身基线，需按业务实际调整，不能照搬
• 常见误区（staging 通过生产就没问题、周五上线没关系）在文档中明确列为 Red Flags，团队文化不改变，清单只会流于形式