稳健发布上线

要解决的问题

功能进生产时，真正难的不是把代码推上去，而是发布之后能否快速判断它是否已经坏了、坏到什么程度、能否安全退回。很多团队只有一条部署流水线，缺少发布前检查、开关策略、渐进流量和回滚阈值，导致小改动也会放大成线上事故。这个技能把发布当作工程问题处理：让每次上线 可逆、可观测、渐进。

它如何工作

• 发布前按六域检查：代码质量、安全、性能、可访问性、基础设施、文档逐项核验。例如安全要求 npm audit 无高危、CORS 限定源、安全头如 CSP/HSTS 配置；性能要求 Core Web Vitals 达到 “Good”、关键路径避免 N+1、查询有索引与缓存。
• 用特性开关解耦部署与发布：先关旗部署，代码在生产但不激活；再团队/beta 开启；随后按 5%、25%、50%、100% 渐进；每个阶段都有 owner、过期日与监控。
• 执行分级发布序列：staging 全测与冒烟后进入生产，先查健康检查端点与错误监控，再团队内测、canary 对比基线，最后逐步扩大流量；每步都可回退到上一比例。
• 按阈值决定回滚：错误率高于基线 2 倍、P95 延迟超过基线 50%、客户端出现新 JS 错误、用户反馈骤增或发现数据完整性/安全问题时，立即回滚。
• 补齐可观测与验证：应用、基础设施、客户端三层监控都要能看错误率、延迟、资源、Core Web Vitals 与业务指标；前端用错误边界上报且不向用户暴露内部细节，服务端统一返回 {error:{code,message}}。发布后首小时验证健康端点 200、日志流动、关键流程可用，并确认回滚机制仍有效。

适用边界

适合首次部署生产、重大变更、数据/基础设施迁移、开启 beta 或有用户影响的高风险发布。不适合纯本地验证、无用户影响的内部实验。不要把它当成替代 CI、监控或数据库迁移工具；它更像发布负责人的判断框架，具体实现仍取决于项目栈与组织流程。