灰度发布与回滚预案
「全量发布后发现问题再回滚」是把用户当测试员。灰度发布把风险控制在一个可控的小比例里。
灰度的常见维度
按风险递增的顺序：
- 内部员工 / 测试流量：零外部影响验证基本功能；
- 按比例：5% → 20% → 50% → 100%，观察核心指标每个阶梯停留 15-30 分钟；
- 按用户特征：新用户先行（无历史数据包袱）、特定地域、白名单用户；
- 按接口：读接口先灰度，写接口最后。
# Nginx 按权重分流到新旧版本
split_clients "${remote_addr}" $backend_upstream {
5% app_v2;
* app_v1;
}
灰度期间看什么
不要盯着服务器指标看灰度效果，要看业务指标对比：新旧版本的下单成功率、转化率、平均耗时。两版本的指标差才是发布引入的变化。需要一个明确的「中止标准」，例如：
任一阶梯内，新版本下单成功率低于旧版本 1 个百分点，立即回滚。
回滚预案的要素
- 触发条件：谁有权宣布回滚（值班工程师即可，不等复盘）；
- 执行路径：一键脚本或明确的操作序列，演练过、耗时可测；
- 数据回滚：最难的部分。发版前确认新代码的数据库变更是否向后兼容（可加列不可删列），必要时准备数据修正脚本；
- 缓存与队列：回滚后新版本写入的缓存、发出的消息如何处理，事先想清楚。
回滚演练：每季度至少一次在测试环境完整走一遍回滚流程。没演练过的回滚预案，执行成功率接近于猜。
发布检查单（精简版）
□ 变更内容与影响面已评审
□ 数据库变更向后兼容（不删列、不改类型）
□ 核心指标有对照监控
□ 回滚命令已写在值班手册
□ 灰度阶梯与中止标准已约定
发布系统的成熟度，不看功能多炫，看两点：回滚要多少分钟、灰度比例可调到多细。这两项做到了，发布就从「提心吊胆的时刻」变成「日常操作」。