生产环境（prod mode）有活跃用户时，如何安全更新服务器代码？

1. 用灰度/蓝绿部署把影响锁在小范围 #

• 灰度发布：先把更新后的代码部署到10%以内的服务器，只放少量流量进去跑。观察1-2小时，确认支付、CRUD操作都正常，再逐步扩量到全量服务器。就算新版本出问题，也只会影响小部分用户，不会搞砸整个支付业务。
• 蓝绿部署：同时维护两套一模一样的生产环境，旧版本在蓝环境，新版本先部署到绿环境，自己先测一遍全链路没问题。然后直接切流量到绿环境，要是出问题，一键切回蓝环境，用户几乎感觉不到中断。

2. 数据库变更绝对要稳 #

• 但凡改数据库结构，必须向前兼容：先上能同时适配新旧表结构的代码，再执行数据库变更。比如加字段就直接加，别先改代码再动数据库，不然旧代码会报错。
• 支付核心表（订单、流水、账户）变更前，必须做全量离线备份，备份文件别存在生产机房，防止机房挂了连备份都没了。绝对不能直接删字段、改主键，要删的话，先等所有代码都不依赖这个字段了，再慢慢删。

3. 支付链路单独加保险 #

• 支付请求必须幂等：新版本要完全兼容旧版本的幂等逻辑，比如用订单ID或者请求唯一标识当幂等键，重复请求直接返回之前的结果，防止用户点多了重复扣款。
• 部署期间可以暂时关掉非核心支付功能，比如满减、优惠券这类营销活动，只留基础支付流程，减少异常场景。
• 支付回调必须有重试机制+全量日志：就算部署期间回调失败，也要自动重试3-5次，而且所有回调的请求、响应都要打日志，出问题能快速定位。

4. 回滚预案必须提前备好 #

• 旧版本的部署包要提前存在本地，确保能在5分钟内完成回滚。部署前要把Nginx路由、数据库配置这些关键参数记下来，回滚时要同步恢复。
• 回滚后第一时间核对支付流水和订单状态，确保数据是一致的，别因为回滚搞出账实不符的问题。

5. 部署全程盯紧监控和验证 #

• 实时盯着核心指标：支付成功率、接口响应时间、错误率，设置告警阈值，一旦超标立刻停发布，切回旧版本。
• 安排专人做全链路人工验证：从下单、支付、回调到订单状态更新，亲手走一遍，确保新版本没问题，别光靠自动化测试。
• 所有日志都要保留：服务器日志、数据库操作日志、支付网关日志，至少存7天，事后排查问题用。

6. 选低峰期动手 #

• 先统计自己业务的低峰时段，比如凌晨2-5点，这个时候在线用户最少，支付请求也少，就算出问题，影响的用户数最少，处理起来也从容。

内容的提问来源于stack exchange，提问作者Sachin Shah