上线出问题不可怕，可怕的是出问题之后不知道怎么办。一个完整的发布流程，要能回答三个问题：发什么、怎么发、出问题怎么退。
一、发布前：清单与确认
- 变更内容清单：改了哪些功能、影响哪些模块
- 数据库变更：脚本、执行顺序、是否可回滚
- 配置变更：环境变量、开关、第三方配置
- 依赖检查：新版本是否依赖未上线的其他服务
- 备份确认：发布前的备份是否完成且可用
二、灰度策略
| 方式 | 适用 | 注意 |
|---|---|---|
| 按用户比例 | 面向公众的系统 | 先小比例，观察核心指标 |
| 按节点分批 | 多实例部署 | 逐台替换，随时可停 |
| 功能开关 | 新功能上线 | 开关状态要记录，避免长期遗留 |
| 内部先行 | 内部系统 | 先开放给小范围用户试用 |
三、回滚：必须提前准备好
- 回滚触发条件要写明确（错误率、响应时间、功能不可用）
- 回滚操作要有步骤卡片，值班人员照着能做
- 数据变更的兼容性：新版本写入的数据，旧版本能否读出
- 明确谁有权决定回滚
回滚决策要快
犹豫的时间就是故障时间。建议约定一个明确的判断标准（如核心功能不可用超过 5 分钟即回滚），让值班人员不必等审批。
四、值班与沟通
- 发布期间安排值班人员，明确联系方式
- 建立发布沟通渠道，发布进展与异常及时同步
- 涉及用户可感知的变更，提前准备对外说明口径
五、发布后复盘
发布完成后 24 小时内做一次简短回顾：有没有意外、哪一步慢了、清单要不要补项。发布流程的成熟度，是靠一次次复盘打磨出来的。
#上线发布#灰度回滚#发布值班#软件事业部
