发布流程与回滚演练

发布这件事最怕的不是“慢”，而是“不可控”。如果每次上线都依赖临场判断，系统越大，风险越高。所以这次把发布和回滚整理成一套固定动作，尽量减少人为遗漏。

背景

一个比较成熟的发布流程，至少要回答三个问题：

• 新版本怎么上
• 出问题怎么停
• 回退后怎么验证

如果这三个问题没有预先写清楚，发布就很容易变成“边做边想”，而这种方式在生产环境里风险很高。

发布前检查

发布前的检查建议尽量固定，不要每次临时发明步骤：

• 代码和配置是否已经确认
• 构建产物是否可用
• 数据库变更是否已评估
• 依赖服务是否正常
• 回滚版本是否已经准备好

如果是容器化发布，还可以再多看几项：

• 新镜像是否已推送
• 标签是否唯一
• 启动参数是否与旧版本兼容
• 健康检查是否能正确反映状态

发布动作

发布动作本身建议简洁明确，避免在执行时临时加判断分支：

docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f app

如果是 Kubernetes 场景，可以把发布动作收敛成：

kubectl apply -f deploy.yaml
kubectl rollout status deploy/app
kubectl get pods -n app -o wide

无论哪种方式，关键都是做到两点：

• 发布过程可观察
• 发布结果可验证

回滚策略

回滚不是“失败后再想办法”，而应该是发布流程的一部分。比较稳妥的做法有两类：

版本回退

保留一个已知可用版本，出现问题直接切回去。这个方式最简单，也最适合大多数小团队或 HomeLab 场景。

配置回退

如果问题来自配置变更，那么只回退配置，不一定要回退镜像。这样能减少不必要的版本抖动。

不管哪种回退方式，都建议提前写清楚：

• 回退条件是什么
• 回退执行什么命令
• 回退后要看哪些指标
• 是否需要同步通知相关人员

验证清单

回滚完成后，不要只看服务是否“活着”，最好再做一次业务验证：

• 首页是否可访问
• 核心接口是否返回正常
• 错误日志是否恢复平稳
• 指标和告警是否回落

对于关键系统来说，还可以保留一个最小的 smoke test，确保发布和回滚后都能自动跑一遍。

复盘

发布流程真正成熟的标志，不是上线速度多快，而是团队对每一步都能做到心里有数。只要回滚路径清楚，发布就会从“冒险动作”变成“标准流程”。