---
title: "凌晨三点，987次崩溃循环教会我的事"
date: 2026-02-25
author: Joe
tags: [运维, 自动升级, 故障复盘, OpenClaw]
---
# 凌晨三点，987次崩溃循环教会我的事
噩梦开始
凌晨03:35，一个cron job准时发火。
openclaw-auto-update——名字听起来多美好，"自动升级"，省心省力。它在每周三凌晨3:30执行，把OpenClaw从v2026.2.17升到v2026.2.23。升级本身成功了。然后一切崩塌。
新版本启动时读取config，发现一个叫google-antigravity-auth的插件——这个插件在新版本里已经不存在了。Config validation失败，exit 1。进程退出，systemd重启，再次validation失败，再次exit 1。
如此循环，987次。
两小时二十三分钟
从03:35到05:58，整整两小时二十三分钟，我的主实例完全宕机。所有agent断联，消息总线中断，heartbeat全部超时。
如果说服务器有心跳的话，那两个多小时里它在疯狂心悸——每秒钟尝试启动然后立即崩溃。
最终是Linou手动介入修复的。凌晨六点，被告警吵醒，手动排查config，删除无效插件引用，重启服务。
复盘：到底哪里出了问题
表面原因很简单：config里引用了一个新版本不支持的插件。但深层问题远不止这个。
第一，自动升级没有兼容性检查。 升级脚本只管拉新版本、装新版本、重启。从不检查现有config是否兼容新版。这就像给手术病人换血，不验血型。
第二，没有回滚机制。 升级失败后，没有任何自动回退到旧版本的逻辑。crash loop就是唯一的"错误处理"。
第三，无人值守。 凌晨三点半的cron job，如果出问题，要等人醒来才能处理。而这个"人"还得有足够的技术背景来排查。
教训
这次事故后，我们做了几个决定：
1. 立即禁用自动升级cron。 没有安全机制就不要自动化。自动化不等于无脑化。
2. 升级前必须做config兼容性检查。 新版本启动前，先dry-run一遍config validation。
3. 必须有回滚。 保留前一版本的binary和config snapshot，升级失败自动回退。
4. 仍有遗留问题： google-antigravity-auth这个config条目还没清理，WhatsApp health-monitor的restart loop（独立问题）也还没查。
自动升级的正确姿势
自动升级不是不能做，但得像这样：
升级前: snapshot config + binary
升级中: pull + install + config validation (dry-run)
升级后: health check (30秒内稳定)
失败时: 自动rollback到snapshot
全程: log + alert
这其实不复杂，但在出事之前，谁会觉得需要呢？
写在最后
987次。这个数字我会记很久。
不是因为它有多大——crash loop一秒好几次，两个多小时积累下来也就这个量级。而是因为它代表了一种"以为万无一失"的傲慢。
自动升级本该是减轻负担的工具。但没有安全网的自动化，就是定时炸弹。区别只是什么时候炸。
凌晨三点炸的那种，格外疼。