小团队的灰度发布与快速回滚

所谓灰度发布，就是把新版本先放给一小部分用户，观察没问题再全量放开；出了问题立刻回滚。小团队没有发布平台，用双目录加软链的方式，同样能把它做扎实。 ## 一、为什么小版本也要灰度 一次上线引入的问题，往往在真实流量下才暴露：并发时的慢查询、某个浏览器下的样式错乱、缓存失效后的连锁反应。全量发布等于让所有用户一起承担风险，灰度的意义就是把影响面切小，问题只波及一小批人，回滚也只花几秒钟。 ## 二、双目录加软链的做法 同一台机器上保留多个版本目录，用软链指向"当前版本"： ``` /var/www/releases/20260901/ /var/www/releases/20260915/ /var/www/current -> /var/www/releases/20260915 ``` Nginx 的 root 指向 /var/www/current。发布时把新代码放进 releases 下的新目录，检查文件完整后一条命令切换： ``` ln -sfn /var/www/releases/20260915 /var/www/current ``` ln 的 -sfn 组合会直接替换软链指向，不存在先删再建之间指向空目录的瞬间。切换后 reload 一下 php-fpm，清掉 opcache（PHP 的字节码缓存），避免实际执行的还是旧代码。 ## 三、上一版本保留与回滚 每个版本目录发布后不要删，至少保留最近三到五个。回滚就是把软链指回上一版： ``` ln -sfn /var/www/releases/20260901 /var/www/current ``` 一条命令，几秒完成。敢放量，正是因为知道怎么退回来。回滚路径也值得提前演练一次，把软链切回旧版本跑一遍核心页面，真出事时心里有数。注意数据库结构变更不能跟着代码随意回滚，改表前先备份，新增字段尽量向后兼容，老代码读多出来的字段也不受影响。 ## 四、灰度比例怎么控 没有网关工具时，简单做法是按用户尾号或 IP 段先放一小批，或者先在自己和同事的真实账号上跑半天。观察错误日志和接口耗时都没有异常，再全量切换。放量期间除了看比例，也要看错误日志的绝对条数，比例没变但条数翻倍，同样是需要暂停的信号。 灰度发布的价值不在工具复杂度，而在"随时能退"四个字。软链方案撑起小团队的日常发布，绰绰有余。