我为什么把“自动化部署”当成了救命稻草

早些年，我们团队发布靠的是“人肉三连”：本地 mvn package 打 jar 包，用 FTP 工具拖到服务器上，然后 SSH 上去 ps -ef | grep java 找到进程，kill 掉，再 nohup java -jar 启动。整套动作行云流水，一个服务五分钟搞定。我一度觉得这比搞什么 Jenkins、K8s 实在多了——直到那次“黑色星期五”。

那天要同时发三个服务，我负责其中两个。发第一个时一切顺利；发第二个时，FTP 传文件传到一半网络闪断，jar 包只传了 60%，我没注意，直接 kill 了旧进程，启动了残缺的新 jar。结果服务起不来，报错 ClassNotFoundException。我慌了，赶紧从本地重新传，传完启动，发现启动是启动了，但配置读的是测试环境的——因为我本地 application.yml 里 spring.profiles.active 写的是 test，忘了改。改完再重启，好家伙，数据库连接池配的是 5，生产流量一进来直接打满，接口全超时。

那次发布从晚上 8 点搞到凌晨 1 点，三个服务先后出问题，运营在群里连环追问，我手心全是汗。事后复盘，所有问题都指向一个根因：发布过程依赖人的操作，而人会紧张、会手滑、会忘事。

从那以后，我铁了心推自动化部署，哪怕被运维同事嫌“事儿多”，也要搞。现在回头看，这条路走对了，而且带来的好处远不止“不用手动传文件”。

一、流水线即文档：发布步骤不再存在“老师傅脑子里”

以前发布靠 wiki 上写的一堆步骤，但 wiki 常年不更新，新来的同学照着做必踩坑。自动化之后，发布流程全写在 CI/CD 配置文件里（Jenkinsfile 或 .gitlab-ci.yml），谁改了流程，Git 历史清清楚楚。新人要发布，点一下按钮就行，不用问“第一步干啥、第二步干啥”。

我们的流水线现在长这样：

1. 拉代码 → 2. Maven 编译打包 → 3. 跑单元测试 → 4. 构建 Docker 镜像（镜像 tag 用 Git Commit ID）→ 5. 推送镜像仓库 → 6. 部署到 K8s（滚动更新，健康检查通过才切流量）

每一步都自动化，没有人工干预点。这意味着：同样的代码，在任何环境、任何时间，发布结果完全一致。

二、环境一致性：镜像就是“一次构建，到处运行”

以前最头疼的是环境差异：测试环境能跑，生产跑不了，因为 JDK 版本差了个小版本，或者少了个系统依赖。容器化之后，镜像里打包了应用+运行时+依赖，测试用的镜像和生产用的镜像是同一个。你测试通过的那个镜像，直接部署到生产，不可能出现“环境不一样”的问题。

有个细节很关键：镜像构建要在 CI 里做，而不是在开发本地。以前有人本地 docker build，结果他本地装了某个私有仓库的证书，镜像里带了进去，CI 环境没有，部署就失败。现在统一在 CI 机器上构建，环境干净，结果可复现。

三、回滚从“半小时”到“30 秒”

自动化部署之前，回滚意味着：找到上一个版本的 jar 包（希望你还留着），FTP 传上去，kill 进程，启动。如果改了配置，还得把配置也回滚。整套操作快则 10 分钟，慢则半小时。

现在 K8s 部署，回滚就是一条命令：kubectl rollout undo deployment/order-service。30 秒内流量切回旧版本，用户甚至感知不到。而且回滚的是整个镜像，包括代码和配置，不会出现“代码回滚了但配置没回滚”的尴尬。

四、发布门禁：让机器替你把最后一道关

我们在流水线里加了几道“门禁”，不通过就不让发：

• 单元测试覆盖率：低于 60% 直接阻断（后来调到了 70%）。
• SonarQube 扫描：新增代码的 Bug 和漏洞数必须为 0。
• 镜像安全扫描：用 Trivy 扫基础镜像的 CVE，高危漏洞必须修。
• 人工审批：生产环境部署前，必须有一个资深同学点“Approve”。

这些门禁不是为了卡人，是为了把问题拦截在发布之前。以前是“发了再发现问题”，现在是“有问题根本发不出去”。

一个心态上的变化

以前我觉得自动化部署是“运维的事”，跟开发无关。现在明白：谁写的代码，谁就该负责把它安全送到生产。你不能把代码一扔，说“部署是运维的事，出了问题也是他们没弄好”。你最了解你的代码需要什么环境、什么配置、什么依赖，这些知识应该编码进流水线里，而不是存在某个人的脑子里。

如果你现在的团队还在用 FTP + SSH 手动发布，真的建议从最小的一步开始：先把 mvn package 放到 CI 里跑，再把 Docker 镜像构建加进去。不用一步到位，但每一步都让你离“睡安稳觉”更近一点。

毕竟，周五晚上谁想守在电脑前盯着 nohup.out 呢？