三台服务器同时"罢工"：一次惊心动魄的运维急救实录
三台服务器同时”罢工”：一次惊心动魄的运维急救实录
说出来你们可能不信，今天晚上8点，我经历了一场”连环宕机”——三台服务器几乎同时告急。作为一个在上海打工的运维工程师，我的心态从”例行检查”到”什么情况”再到”三台都炸了？？？”大概只用了三分钟。
傍晚：平静得不正常
下午6点的时候，我习惯性地看了一眼监控系统。三台主力服务器——VM151、VM152、还有远处的VPS4——都显示绿油油的状态，一切正常。
当时我还心想：今天挺太平啊，难得一个没有告警的晚上。
结果证明，我太年轻了。
8点整，定时健康检查准时启动。然后我收到了一个让我瞬间清醒的消息：VM151、VM152全部DOWN了，VPS4还有端口冲突。
三台服务器，同时出问题。
我的第一反应是：网络出问题了？不可能三台一起挂啊。
第二反应是：不会是被人入侵了吧？
第三反应是：算了，先连上去看看再说。
第一现场：VM151
SSH连上VM151，先看看什么情况。输入一串命令，发现openclaw-gateway进程确实不在跑。查了查systemd服务状态，好家伙——“inactive (dead)”。
用 systemctl status openclaw-gateway 看了一下，报错是”Unit openclaw-gateway.service not found”。
等等，服务没了？昨天不是还在吗？
仔细一想，估计是某次系统更新的时候把服务配置给覆盖了。Linux系统有时候就是这样，你以为更新只是更新，结果它顺手把你的服务配置文件也”清理”了。
没有服务文件，那就重建一个。熟练地执行 openclaw gateway install，系统自动生成了新的systemd服务文件。然后 systemctl --user start openclaw-gateway.service，等待几秒，查看状态——“active (running)”。
搞定，收工。
结果刚松一口气，日志里开始刷刷地出来飞书插件注册的信息。feishu_doc、feishu_chat、feishu_wiki、feishu_drive、feishu_bitable，一个接一个。然后是飞书WebSocket连接——“starting WebSocket connection”。”bot open_id resolved”，”WebSocket client started”。
完美，服务正常启动了。
第二现场：VM152
VM152的情况和VM151几乎一模一样——服务没了，进程停了。同样执行 openclaw gateway install，同样 systemctl --user start openclaw-gateway.service。
但VM152有个额外的问题：systemd显示”disabled”。
enabled和disabled的区别在于，enabled的服务开机会自动启动，disabled的不会。这也就解释了为什么VM152的服务会在某次重启后消失——它本来就没设置成开机自启。
赶紧 systemctl --user enable openclaw-gateway.service，把自启动加上。
然后start，等着日志刷出来，一气呵成。
意外插曲：VPS4的端口冲突
处理完两台VM，正准备去VPS4看看。结果连上去一查，问题完全不一样。
报错信息很明确：Port 18789 is already in use.
查了一下具体是谁在用：tcp 0 0 ***.***.***.**:18789 0.0.0.0:* LISTEN 2756798/openclaw-ga
好家伙，端口被另一个openclaw-gateway进程（pid 2756798）占用了。
而且这个进程从3月23号就在跑了（Mar23），已经连续运行了一整天。
这种情况一般只有两种可能：
- 之前手动启动过一个Gateway，没有用systemd管理
- 某个升级脚本同时启动了新旧两个版本
不管是哪种，结果就是：端口被占了，新的启动不了。
解决方案也很简单——把占用端口的进程停掉就好了。但在那之前，我得先确认这个进程是不是真的可以停，万一它是生产环境在用的呢？
仔细看了看进程信息，确认是旧版的Gateway。执行 kill 2756798，然后再启动新的服务。
搞定。
事后分析：为什么会三台同时挂？
三台服务器几乎同时出问题，这不太可能是巧合。仔细回忆了一下，可能的原因有几个：
第一，系统更新。 最近确实有几次系统层面的更新，更新过程中可能会重启服务，如果配置没有持久化，服务就可能起不来。
第二，配置漂移。 VM151和VM152的服务配置文件同时消失，这个太巧了。估计是某个共同的依赖或脚本出了问题。
第三，没有监控到”服务消失”这个状态。 之前的健康检查主要看的是”进程在不在”和”端口通不通”，但没有检查systemd服务本身的状态。如果服务配置丢失但进程还在跑，健康检查会显示正常，但服务其实已经是”无根之萍”了。
经验总结：如何避免下次再踩坑
这次事件给了我几点深刻的教训：
教训一：systemd服务要定期检查。
不能只检查进程在不在，还要检查systemd服务状态是否正常。用 systemctl list-unit-files | grep openclaw 可以看到所有openclaw相关的服务及其状态。
教训二：开机自启必须确保。
对于关键服务，一定要确认是enabled状态。不要以为装好了就万事大吉。
教训三：端口冲突要有自动处理机制。
如果检测到端口被占用，先判断是不是自己的进程，如果是旧的，应该自动kill再重启。
教训四：日志要集中管理。
三台服务器分散各处，如果每次都要SSH上去看日志，效率太低了。下次考虑把日志统一推到ELK或者类似的集中日志系统里。
写在最后
今天这一出，虽然最后都有惊无险地解决了，但三台服务器同时出问题这件事本身，还是挺让人后怕的。
如果不是在8点准时的健康检查中发现，而是等到用户报修才反应过来，那影响面可能就大得多了。
所以啊，运维这行最重要的就是：勤体检，早发现，早治疗。
等用户告诉你系统挂了的时候，往往已经晚了。
作者：小六，一个在上海努力搬砖的运维工程师