部署不是终点 —— 上线后自动体检 + 冲突 / 残留自动清理

把项目推上线、健康检查变绿、域名能打开 —— 大多数部署工具到这里就画句号了。但真实的服务器不是无菌实验室:它往往同时跑着你好几个项目,还有以前留下的东西。上线那一刻没报错,不代表整台服务器是干净的。

上线之后,问题往往出在「别处」

我们自己拿产品反复上线、更新真实项目时,反复撞到三类「部署成功了、服务器却不对劲」的情况:

• 端口 / 域名串台:同一台机器上多个项目,A 项目的域名被 B 项目的旧 nginx 配置占着,或两个项目抢同一个端口 —— 你的请求被路由到了别人的进程。
• 组件起不来:多组件应用里 api 崩了、web 还活着,健康检查只看其中一个就误报「成功」,真打开是 502。
• 删了部署、没清干净:一个早就删掉的旧部署,pm2 里的进程没注销,还在一个已经不存在的目录里反复 npm start —— 每隔几百毫秒崩一次、被 autorestart 再拉起。我们真机巡检时逮到过一个重启了 90 多万次的残留进程,白烧 CPU,谁都没发现。

把「体检 + 清理」做进产品

先说我们不做什么:我们没有做 7×24 监控告警系统 —— 那需要常驻 agent 长期盯着你的应用,不是我们想替你背的东西。我们做的是更克制的一件事:每次上线后,顺手给服务器做一次体检。

巡检(只读,不动服务器)

经产品自己的 SSH 通道(和部署同一条,不额外给谁开权限)只读采集服务器实况:谁在监听哪个端口、每个域名的 nginx 实际反代到哪、pm2 进程清单与各自的工作目录。再和「你这个项目期望的域名 → 端口」比对,产出一份冲突清单。

• 域名没指向你的组件 / 指错端口 → 标出来
• 你的端口被别项目进程占着 → 标出来
• 某组件 errored / 反复重启 → 自动拉它的崩溃日志尾,把 502 的根因(Prisma 连不上库、缺启动产物等)直接给你
• 某进程的工作目录已经不存在 → 判定为「删了部署却没注销」的残留孤儿

清理(改服务器 —— 必须你确认)

巡检全程只读。要不要清,是另一步、你说了算。确认后产品才会动手:把你的端口避让到真实空闲的高位端口、删掉占着你域名的串台 vhost、注销那些崩溃的残留孤儿进程。

这里有一条不退让的边界:清理只动「属于你这个项目」的东西 —— 端口避让只改你的描述符,vhost 只删占你域名又不是你产物的,孤儿进程只注销工作目录带着你项目标识的。同机别人的应用,一根头发都不碰。

上线成功后,自动跑一遍

这套体检不用你记得去点。版本更新(Update)成功上线后,产品会自动跑一次,把异常清单随「上线信息卡」一起交给你 —— 服务器干净就告诉你干净,有问题就列出来、附上一键清理的入口。报告给你、由你拍板,绝不替你静默处理。

上线只是开始。让「上线之后服务器到底干不干净」这件事,也变成产品替你看一眼的事。