API 半夜挂了我却不知道，这次让我补上最基本的监控意识

这次故障最扎心的地方，不是 API 挂了，而是它挂了很久，我却完全不知道。

直到早上的定时邮件没来，我才意识到问题已经不是“小波动”，而是服务从半夜开始就一直在反复崩溃重启。对一人公司来说，这种静默失败比大红报错更危险，因为没人会替你盯。

所以这篇想把事情说清楚：故障到底怎么发生、为什么 systemd 重启了七千多次都没把它救回来、以及我后来补的健康检查为什么虽然土，但很有必要。

僵尸进程

fuser 8080/tcp 一看，有个Python进程卡在那儿。这个进程不知道什么时候启动的，可能是上次服务重启没清理干净，也可能是我手动测试时忘关的。

kill 掉它，重启服务，systemctl 终于显示 active (running)。

curl 一下 API，返回 {"status": "ok"}。

搞定。

但问题来了

从日志看，这个服务大概从凌晨就开始反复崩溃重启。也就是说，当天的定时采集脚本大概率跑失败了——数据采不进来，报告生成不了，我这边啥也不知道。

一个人搞这些东西，最怕的就是这种”静默失败”。没人值班，没人报警，等你发现的时候已经亏了好几个小时。

现在我给 API 加了个简单的健康检查，每天采集前先验证一下服务是不是活着的。不算什么高大上的方案，但至少不会再出现”挂了一整天没人知道”的情况。

一人公司的运维现实

之前在公司里，基础设施有专门的团队盯着。挂了有人值班电话，有告警群，有值班日志。

现在一个人，什么都是自己来。服务器、数据库、定时任务、CI/CD……每一层都可能出问题，而且大多数时候你不会第一时间知道。

没有银弹。能做的就是多加几个检查点，多留几条后路，然后接受”偶尔会挂”这个现实。

毕竟又不是什么金融系统，挂几个小时，天塌不了。