为什么不直接全量
新版本一旦有 bug，全量上线等于瞬间影响所有用户，回滚也来不及。渐进式发布把风险摊小，出问题只波及一小撮。
灰度发布
按流量比例逐步放量：先 1% 内部用户，观察指标正常再 5%、20%、100%。任何一步异常就停手回退。适合验证真实流量下的行为。
蓝绿部署
同时跑两套环境：蓝（旧）接流量，绿（新）就绪后，把路由一秒切到绿。出问题切回蓝即可，用户几乎无感。代价是要两份资源。
回滚比上线更重要
- 保留上一版：蓝绿天然有备份，灰度要能一键缩回 0%；
- 看指标再放量：错误率、延迟、转化率异常立即停止；
- 数据库向后兼容：新代码读旧表结构，回滚才不崩。
实战案例：三次发布翻车
- 切换时连接被掐断：直接摘除旧环境，长连接与未完成请求全断。应先停新流量、等待在途请求结束，再下线旧环境。
- 灰度按机器而不是按用户：同一用户在不同实例间来回切换，看到新旧两版界面甚至状态错乱。灰度应按用户或请求标识做一致性路由。
- 数据库变更不可回滚：代码能回滚，字段却已删除，回滚后立即报错。应采用“先兼容后清理”的扩张—收缩策略：先加字段并双写，稳定后再删旧字段。
常见问题（FAQ）
蓝绿与金丝雀有什么区别？蓝绿是两套完整环境整体切换，回滚最快但资源翻倍；金丝雀先放少量流量验证，更省资源、观测更细。灰度比例怎么定？从 1%–5% 起步，盯错误率与延迟，稳定后逐级放大。怎么快速回滚？保证产物可追溯到具体版本，并让数据库变更向后兼容。需要功能开关吗？需要，开关能在不重新部署的情况下关闭新功能，是发布风险的第二道闸。
发布前的准备与发布后的验证
发布策略解决的是“出问题时如何快速恢复”，真正决定成败的是发布前后的准备工作。
- 可观测性先于发布：灰度必须有指标可看。至少要有新版本的成功率、延迟分位数与关键业务指标，并能按版本维度切分。看不到差异的灰度等于没有灰度。
- 变更清单与回滚点：每次发布列清楚改了什么、依赖哪些数据变更、回滚时会遇到什么障碍。数据库变更与配置变更通常比代码更难回滚，应单独标注。
- 自动化验证：灰度期间自动对比新旧版本的核心指标，超过阈值立即停止放量。人工盯着看容易在关键时刻错过信号。
- 回滚演练：回滚路径必须演练过，而不是等出事当天第一次执行。演练会暴露数据不兼容、配置未同步与镜像未归档等隐藏问题。
- 发布窗口与环境隔离：避开业务高峰，并确保灰度流量可控、可终止；共享环境的变更要排队执行，避免互相干扰造成误判。
与团队流程的配合
技术手段之外，发布节奏与责任分工同样重要：谁决定停止放量、谁负责回滚、出现问题向谁同步，都应在发布前明确。把决定权交给一个清楚的人，比事后开会讨论更快也更可靠。
小团队的最小可行方案
并非所有团队都需要完整的灰度体系。若资源有限，至少应做到三点：产物可追溯并可一键回滚、发布前后有核心指标对比、变更与配置一并纳入版本控制。做到这三点，绝大多数发布事故都能在几分钟内恢复。