《服务半夜挂了，是自检脚本把它拉起来的》

前几天早上查服务状态，发现接口中转服务没响应。第一反应是进程是不是又退出了，查了一圈发现不是进程的问题——是服务的启动配置丢了，系统里找不到它，重启命令根本无从下手。

这台机器之前有个毛病：运行环境偶尔会把系统配置目录整个换掉，换完里面是空的。启动配置就放在那里面，跟着一起没了。服务本身没坏，二进制、凭证、启动脚本都在，就是没人能把它拉起来。

好在之前写过一个自检脚本，每 15 分钟跑一次，发现服务没响应就动手修：先把启动配置的链接重建好，再重启服务，起来之后还要验两项——鉴权能不能通、模型列表接口能不能正常返回，两项都通了才算修好。那天早上就是这个脚本走完了全套，服务恢复了，我只是在日志里看到了它干活的记录。

这次的教训和上次部署时不一样。上次是部署方案要先看环境允不允许，这次是：光会启动不够，还得会自愈。机器上跑的东西，配置丢了、进程挂了都是迟早会遇到的事，指望人半夜起来手动修不现实；自检加自动修复，再加修完之后的真实验证，比单纯写个启动脚本更顶用。

也要老实交代两点：第一，自愈修的是症状，配置目录会被清空这个根因还在，下次再遇到还是同一套修复流程；第二，凭证目录到现在还是空的，还没登录任何一家模型厂商，服务能跑、模型还用不上，登录那一步还没做。

回头看，折腾到这一步，判断标准其实很简单：服务活着不算数，请求能通才算数；人不在的时候能自己爬起来，才算真的稳。