升级之后，我的服务开始半夜反复自杀
我这人对「自动」这两个字有执念。软件能自动升级，我绝不手动。结果上周我手贱点了一次升级，然后我的 AI 服务开始半夜反复自杀。
我这人对「自动」这两个字有执念。软件能自动升级，我绝不手动。
上周我手贱点了一次升级。然后我的 AI 服务，开始半夜反复自杀。
白天也好不到哪去——你发消息它不回，过十分钟自己又活了。像极了那种「已读不回但朋友圈照发」的朋友。
我花了一整天查，凶手有三个。
第一个凶手：一个慢了 570 倍的「体检」
服务每次冷启动，都要先给自己做个完整性检查。听起来挺健康——但它在启动时独占了主线程，整整 8 到 10 分钟。
这十分钟里：不写日志、端口不监听、健康检查全挂。从外面看，就是一具尸体。
而真正要命的是我这个「聪明人」的反应：看它十分钟没动静，就去重启它。一重启，启动进度清零，重新再等十分钟。越救越慢。
后来我把同一个检查单独跑了一遍：0.87 秒。同一个检查，在服务里跑要 8 到 10 分钟。570 倍的差距。
教训：服务没回应，不等于它死了。可能只是在忙。
第二个凶手：一个「已经关掉」的插件
我在日志里翻到一句话，看了三遍才懂：
shutdown did not complete cleanly（关机没关干净）
原因是一个叫 Discord 的插件。我在配置里明明把它关掉了——但我关的是「通道」，不是「插件」。插件还活着，关机时它有个任务没跑完，硬拖了 5 秒超时，于是整个关机流程被判失败。
关机不干净 → 重启就不干净 → 状态没保存好 → 下次启动更慢。
教训：「关掉通道」不等于「关掉插件」。 一个没用的插件，会在你最不想被打扰的时候拖你后腿。
第三个凶手：一个「好心」的自动回滚
升级失败时，系统会自动滚回旧版本。听起来很安全对吧？
问题是：新版跑过之后把数据库升级了。数据库只能往前走，不能往回退。滚回旧版的服务，打开新版升级过的数据库——读不了，直接拒绝启动。
所谓「安全回滚」，把一个能跑的系统，变成了一个起不来的系统。
教训：自动回滚不是免费的。 有状态的服务，回滚前必须先想清楚「状态能不能退」。
三个凶手抓完，服务现在稳了。我把它们写在便签上贴屏幕边：
- 启动慢 ≠ 死了，别急着重启
- 关通道 ≠ 关插件
- 有状态的东西，回滚要留后路
还有一条更宏观的：「自动」能省事，但省不了理解。 你享受了多少自动，就得为它可能的失败兜多少底。
（如果你也在折腾本地 AI / 自动化，这三条大概能帮你少熬一个通宵。）
（姊妹篇：我的 AI 半夜又死了，这次我决定查个明白）