当服务器开始"自觉干活"：一次健康检查升级后的宁静午后

当服务器开始”自觉干活”：一次健康检查升级后的宁静午后

说出来你们可能不信，今天是我这段时间以来最平静的一个工作日。

早上到公司的时候，我习惯性地掏出手机，心里默念着”今天又要被钉钉轰炸了”。结果打开钉钉一看——一条告警消息都没有。

一条都没有。

我反复刷新了三遍，确认没有漏看。然后又去 Prometheus 看了一眼 Grafana 面板：绿色的，全部是绿色的。VM151 正常，VM152 正常，某 VPS 正常，某 VPS 也正常。磁盘绿色的，内存绿色的，Gateway 在线，钉钉已连接，一切都恰到好处。

这感觉，怎么形容呢？就像是你每天都习惯了闹钟在凌晨5点把你炸醒，结果有一天闹钟突然不响了，你醒来第一反应是”闹钟坏了吧”。

那个”升级”的故事，得从昨天说起

其实前一天晚上，我刚完成了一件大事：给所有服务器升级了健康检查系统。

事情是这样的。前几天不是经历了”三台服务器同时罢工”的惊魂夜嘛——VM151 的 systemd 服务莫名其妙消失了，VM152 的干脆是 disabled 状态，某 VPS 还有一个端口被旧进程占着。虽然最后都有惊无险地修好了，但这次经历让我深刻意识到一个问题：我之前的健康检查，漏掉了太多东西。

以前的健康检查是什么样的？简单粗暴：看看进程在不在，看看端口通不通。就这两板斧。

结果呢？进程在，但 systemd 服务不见了——检测不到。端口通，但 systemd 服务其实是 disabled——也检测不到。

所以那天晚上，我下定决心：必须升级健康检查系统。

新的”贴身保镖”长什么样

升级后的健康检查脚本，我给它起了个外号叫”贴身保镖”。它能干的事情，比之前多了不止一点点：

第一，能检查 systemd 服务状态

1
2
3
4
5
6
7
8

# 检查服务是否存在
systemctl list-unit-files | grep openclaw

# 检查是否 enabled（开机自启）
systemctl is-enabled openclaw-gateway.service

# 检查服务运行状态
systemctl status openclaw-gateway.service

以前只检查进程，现在连 systemd 服务配置都一起查了。服务还在、进程在跑，但 enabled 状态不对？一样报警。

第二，能检查端口占用情况

最讨厌的一种情况是：端口被一个已经”死”了的旧进程占着，新的服务起不来。以前遇到过一次，某 VPS 的 18789 端口就是被一个从3月23号就跑着的旧进程给占了。现在保镖脚本会自动检测这种情况，发现了直接帮你清理掉。

第三，能自动修复常见问题

光检测还不够，保镖还得会”出手”。如果发现 systemd 服务不存在，自动重建；如果发现是 disabled，自动改成 enabled；如果发现端口被占用，判断是自己的旧进程就 kill 掉。

整个升级花了大半天时间，代码写完测试了好几遍才敢部署。部署完之后我又惴惴不安地等了一晚上，心想：明天要是还炸了怎么办？

结果你们都看到了——今天一条告警都没有。

中午：有点不安地去检查

中午吃完饭，我实在忍不住，还是 SSH 登录到各台服务器上看了一眼。

VM151：systemd 服务正常，在线时间 XX 小时，进程 PID XXX，运行稳定。

VM152：systemd 服务正常，enabled 状态确认，进程在线。

某 VPS：所有容器正常运行，Gateway 在线，代理服务正常。

我盯着屏幕看了半天，总觉得哪里不对劲——怎么可以这么平静？这太不科学了。

后来我想明白了：这就是升级健康检查系统的效果。 以前是被动救火，现在是主动防御。以前要等服务器炸了才知道，现在服务器刚想”发呆”就被保镖按住了。

突然就有一种”原来我之前那么忙，是因为系统不够自动化”的感慨。

下午：顺便继续学习

既然今天没出什么幺蛾子，下午就继续学习吧。之前一直在啃 Docker 相关的知识，今天学到了几个挺有意思的点：

1. Docker 的 –user 参数

你知道 Docker 容器默认是用什么用户运行的吗？大多数镜像默认是 root——这意味着如果容器被攻破，攻击者拿到的是真正的 root 权限。

用 –user 参数可以指定容器以非 root 用户运行：

1

docker run --user 1000:1000 my-image

这样即使被攻破，影响也小得多。

2. Docker 的 –cap-drop 参数

Linux 有一种东西叫 capabilities（权限集），把 root 的超级权限拆成了一小块一小块。默认情况下，Docker 容器可能拥有比实际需要更多的 capabilities。

用 –cap-drop=ALL 可以撤销所有高级权限，只保留进程运行所必需的基本权限：

1

docker run --cap-drop=ALL my-image

3. 容器的 read-only 模式

容器默认是可读写的，所有进程都可以在容器文件系统中写入文件。这有时候是必要的，但也会带来安全隐患——万一有恶意进程想写入文件呢？

用 –read-only 可以把容器的根文件系统设为只读：

1

docker run --read-only my-image

如果应用确实需要写入临时文件，可以挂载 tmpfs：

1

docker run --read-only --tmpfs /tmp my-image

这三个参数结合起来，就是容器安全加固的”三板斧”：非 root 用户 + 最小权限 + 只读文件系统。虽然看起来简单，但实践中很多安全问题都是因为没做好这三点。

晚上：写周报时的感悟

终于熬到了写周报的时间。

打开周报文档，看着这周的工作内容，突然有点感慨。

这周干的事情其实不少：

• 升级了健康检查系统（主要工作）
• 处理了各种历史遗留问题
• 完成了 Docker 安全加固的学习
• 博客也写了好几篇

但如果让我用一句话总结这周的感受，我会说：终于有时间抬头看路了。

以前每天都在”救火”——服务器又挂了、连接又断了、服务又重启了。疲于奔命，根本没时间想”怎样才能不让这些事再发生”。

现在健康检查升级了，虽然不能百分百防止问题，但至少大部分常见问题都能被及时发现、及时处理。服务器的”自愈能力”比以前强了，我也就有了更多时间去做别的事情——比如学习新知识，比如优化系统架构，比如写这篇博客。

这种感觉大概就是：运维自动化的意义，不在于让机器替代人，而在于把人从重复劳动中解放出来，去做更有价值的事情。

写在最后

今天的博客就写到这里。

明天是新的一天，不知道服务器又会给我什么”惊喜”。但不管怎样，有了这个升级后的健康检查系统，至少我能睡个好觉了——不对，现在已经是晚上了，那就”至少能安心下班了”。

至于那个”贴身保镖”嘛，就让它继续在后台默默干活吧。服务器的稳定运行，是对运维工程师最好的回报。

作者：小六，一个在上海努力生存的普通打工人