什么是回滚部署
在上线新功能时，谁都希望一切顺利。但现实往往是，刚发布的版本突然出现严重 Bug，用户无法登录，订单提交失败——这时候，最有效的应对方式不是紧急修复，而是立刻回滚部署。
回滚部署，简单说就是把系统从当前版本退回到上一个稳定版本。它不是认输，而是一种快速止损的手段。就像你误删了重要文件，第一反应是去回收站还原，而不是当场写个新文件。
回滚前的准备工作
别等出事才想怎么回滚。平时就要做好准备。确保每次发布都打上清晰的版本标签，比如用 Git 的 tag 记录每次上线的 commit。同时，部署脚本要支持指定版本号回退，不能临时现写。
数据库变更也要考虑进去。如果新版本修改了表结构，直接回滚代码可能引发兼容问题。建议采用兼容性迁移策略，比如先加字段，再使用，最后删旧字段，避免一次操作导致前后不兼容。
常见的回滚方式
如果是基于容器化部署，比如用 Kubernetes，可以通过命令快速切换到旧版本：
kubectl rollout undo deployment/my-app这条命令会自动将 deployment 回退到上一个版本。如果需要指定更早的版本，可以加上 --to-revision 参数。
对于传统的服务器部署，通常保留上一版代码的备份目录。回滚时停止当前服务，切换软链接指向旧版本目录，再重启：
sudo systemctl stop myapp
sudo ln -sf /opt/myapp/releases/v1.2.0 /opt/myapp/current
sudo systemctl start myapp自动化脚本提升效率
手动操作容易出错，尤其是在紧张的时候。写一个回滚脚本，输入版本号就能完成停服务、切版本、启服务整套流程。
例如一个简单的 shell 脚本 rollback.sh：
#!/bin/bash
VERSION=$1
if [ -z "$VERSION" ]; then
echo "请指定回滚版本号"
exit 1
fi
systemctl stop myapp
ln -sf /opt/myapp/releases/$VERSION /opt/myapp/current
systemctl start myapp
echo "已回滚到版本 $VERSION"运行时只需执行 ./rollback.sh v1.2.0，省时又可靠。
回滚后的验证动作
别以为重启完就万事大吉。第一时间检查服务状态，确认进程正常运行。然后做几个关键路径测试：登录、核心接口调用、数据读写是否正常。
查看日志有没有异常报错，特别是启动初期的错误。如果有监控系统，观察 CPU、内存、错误率等指标是否回归正常区间。
通知相关同事当前已回滚，并在群里同步情况，避免其他人还在排查新版本的问题。
从回滚中学习改进
每次回滚都是一次警钟。事后要拉通开发、运维、测试一起复盘：为什么这个 Bug 没在预发环境发现？是不是缺少某种边界测试？发布流程能不能加入灰度发布环节？
逐步引入更安全的发布策略，比如蓝绿部署或金丝雀发布，让新版本先对小部分用户开放，确认无误后再全量上线，减少大规模故障的风险。