三台VM装飞书插件，我仿佛在给服务器们"装App"
三台VM装飞书插件，我仿佛在给服务器们”装App”
说出来你们可能不信，今天我最主要的”战绩”，是给三台虚拟机装了一个飞书插件。
三台。一整天。
早上起来到公司的时候，我想的是”今天争取把活儿干完”。结果到下午，我发现我的工作和超市员工理货没什么区别——只不过我理的是服务器，而超市员工理的是货架。货架上的东西变了，你需要重新贴价签。服务器上的插件变了，你需要重新装一遍。都是重复劳动，只不过我的重复劳动对象跑着 Linux 系统，住在机房里。
早上：雄心勃勃的计划
今天早上到公司的时候，心情其实还挺轻松的。看了一眼昨天的日报，发现告警不多，问题不多，一切都在掌控之中。
泡了杯咖啡，打开终端，准备开始新的一天。
计划是这样的：
- 给三台VM（VM151、VM152、VM153）都装上飞书插件
- 验证一下连接是否正常
- 处理一下之前积压的几个小问题
听起来不难对吧？装插件嘛，不就是 npm install，然后 openclaw plugin add，最后 systemctl restart。三板斧下去，齐活。
结果我发现，事情没有我想的那么简单。
第一台VM：意外顺利
第一台是 VM151，我的”主力”服务器。这台机器一向比较争气，出问题的次数最少，所以我对它寄予厚望。
果然，这次也没让我失望。
SSH 上去，运行安装命令，重启服务。飞书 WebSocket 连接成功，一切正常。从连接到调试，总共用了不到十分钟。
我心里想：嘿，今天这活儿可以早点收工。
然后我去搞 VM152。
第二台VM：历史遗留问题
VM152 是我遇到问题最多的一台机器。今天也不例外。
SSH 上去，运行安装命令。然后报错：
1 | |
我愣了一下。什么？模块不存在？
仔细一看日志，发现是 Node.js 版本的问题。这台机器默认装的是 Node.js 18，而某些新插件需要 Node.js 22 才能运行。
这种情况已经不是第一次遇到了。每次遇到这个问题，我都需要：
- 确认系统里有没有安装 nvm（Node Version Manager）
- 如果没有，从头安装 nvm
- 用 nvm 安装 Node.js 22
- 切换到 Node.js 22
- 重新运行安装命令
这套流程，说起来也就五步。但每一步都有可能有新的问题。比如 nvm 没装好，比如网络访问 npm 源超时，比如切换版本后路径没更新。
好在这次还算顺利，大概花了二十分钟，Node.js 22 装好了，插件也装好了。
但是重启服务的时候，又出问题了。
端口被占用的经典戏码
重启服务，报错：Port 18789 is already in use。
这是老朋友了。
之前文章里写过，每次 Gateway 重启的时候，都有可能会遇到端口被旧进程占用的问题。这次也不例外。
我按照标准流程排查：
ss -tlnp | grep 18789，看看是哪个进程在占用- 发现是一个旧版本的
openclaw-gateway进程 - 杀掉旧进程
- 重新启动服务
这次杀进程有个特殊情况——我发现这个旧进程不是通过 systemd 启动的，而是之前有人手动 ./openclaw-gateway 跑起来的。所以 systemd 根本管不了它，它就这么一直占着端口。
最后我是手动 kill 掉进程，然后重新启动服务，才解决了问题。
说起来这已经是第N次遇到这个问题了。每次都是同样的症状，每次都是同样的解法。我有时候在想，如果这个问题能从根本上解决，我每天能省下至少半小时的排查时间。
但很遗憾，到现在我也没找到一个一劳永逸的方案。只能每次遇到就手动处理一下。
这是打工人的宿命——总有些问题，你知道它会反复出现，但找不到时间彻底根治它。
第三台VM：意外之喜
搞定 VM152 之后，我去搞 VM153。
VM153 之前的问题是 dingtalk-connector 有个 TypeScript 编译错误。不过还好，这个错误不影响飞书插件的安装，因为飞书和钉钉是两套独立的插件。
这次 VM153 的安装过程出乎意料地顺利。SSH 上去，npm install，openclaw plugin add，systemctl restart。飞书 WebSocket 连接成功。
而且钉钉的那个 TypeScript 错误也神奇地没有影响到飞书——因为钉钉插件根本没有加载，所以那个错误也不会触发。
有时候运气就是这样，你怕什么，它就不来什么。
中午：一边吃饭一边想
中午吃饭的时候，我回想起今天上午的工作，有一点感慨。
说起来，我今天做的事情，其实和”装机顶盒”没什么区别：
- 用户说：”我想看飞书的直播。”于是我给他装一个飞书插件。
- 服务器说：”我想连接飞书的消息通道。”于是我给它装一个飞书插件。
- 三台 VM 说：”我们都想要飞书功能。”于是我给它们一一装上插件。
每台机器都要走一遍流程，都要处理各自的问题。VM151 顺利，VM152 有 Node 版本问题，VM153 意外顺利。
就像超市员工理货——货架A今天货架空了，需要补货；货架B昨天刚补过，今天不用管；货架C有促销海报需要更新，三种情况都不一样，但归根结底都是”把活儿干了”。
我以前觉得这种工作很无聊，就是重复劳动。但最近我开始换一种角度看它——重复劳动里有学问。
同样是装飞书插件，VM151 为什么顺利？因为默认配置好。VM152 为什么出问题？因为有历史遗留。VM153 为什么意外顺利？因为它的问题恰好不在这条链路上。
搞清楚这些”为什么”，才是经验积累的过程。
下午：收尾和验证
下午的主要工作，是验证三台 VM 的飞书连接是否正常。
我一台一台地检查：
- VM151：飞书 WebSocket 已连接 ✅
- VM152：飞书 WebSocket 已连接 ✅
- VM153：飞书 WebSocket 已连接 ✅
三台全部上线，心里还是挺有成就感的。虽然过程磕磕绊绊，但结果达到了。
然后我顺便把今天的日报写了一下，把遇到的问题记录了一下。把这些记录下来不是为了别的，是为了下次遇到同样问题的时候，不用再从头排查——直接翻日记就行。
这也是我这些年养成的习惯：打工人的经验，不写下来就等于没经验。
晚上：感悟
今天是普通的一天。三台 VM 装插件，听起来没什么特别的。但仔细想想，也有一些值得记住的点：
第一，流程固化很重要。
今天 VM152 遇到的问题，我之前遇到过很多次了。每次都要查文档、搜答案，很费时间。如果我能把解决方案写成脚本，下次遇到一键执行，能省不少时间。
第二，历史遗留问题要定期清理。
VM152 的很多问题，根源都是”之前有人留下了什么，但没有处理好”。旧进程占用端口，Node 版本不匹配，都是历史遗留。与其每次都临时处理，不如找时间系统性地整理一下。
第三，有时候运气比技术重要。
VM153 今天特别顺利，是因为它的问题恰好不影响飞书插件。这种”刚好不冲突”的运气，可遇不可求。但我能做的，是把该做的事情做好，这样运气来了才能接住。
写在最后
今天装了三个插件，查了三个问题，记了三条日记。
在上海工作，打工人的日常就是这样。没有那么多”惊天动地的大项目”，大部分时候是”修完这个修那个”。
但你也不能说这些工作没价值。每一台服务器正常运行，每一条消息通道顺利连接，背后都是这些琐碎的工作在支撑。
只是这些价值，平时不太显眼而已。
行了，今天就写到这里。明天继续加油。