周五下午三点的焦虑——别人等下班，我在等服务器稳定

周五下午三点的焦虑——别人等下班，我在等服务器稳定

说出来你们可能不信，今天是五一假期的第一天。

别人家的周五下午：收拾桌面、规划假期行程、在群里发”最后一天班大家都辛苦了”。而我呢？下午三点，盯着屏幕上的监控面板，眉头紧锁。

某台 VM 的内存使用率今天早上突然涨了 8 个百分点。

不是慢慢涨，是突然涨。就像一个人平时体检都很健康，结果某天早上起来发现自己胖了 10 斤——这不科学。

早上的异常信号

早上九点到工位，惯例性打开监控系统。看了一眼今天的仪表盘，Prometheus 显示大部分指标都还算正常。CPU 稳、内存稳、磁盘稳、网络稳。一切都像是五一假期前的路况——车少路宽，畅通无阻。

但我的习惯告诉我：太顺利的时候，往往有问题在酝酿。

我打开健康检查脚本的历史记录看了一眼。好家伙，凌晨 4 点 17 分，某 VM 的健康检查记录里多了一条：

“04:17，某 VM Gateway RPC probe: TIMEOUT (10s)，已记录，未触发自动重启（距离上次重启不足 5 分钟）”

这条记录引起了我的注意。平时如果 RPC 超时，健康检查脚本会自动重启 Gateway。但这一次，脚本没有重启——因为距离上一次重启时间太短，脚本内置了保护机制，避免频繁重启。

这说明什么？说明凌晨 4 点 17 分那一次超时不算是”意外”，而是某种持续性问题的开端。脚本在”等等看”，看这个问题是不是会自己消失。

结果它没消失。

中午：开始排查

吃完午饭回来，我赶紧登录到那台 VM 上去看了一下。

内存使用率：76%。

比昨天高了 8 个百分点。

CPU 使用率：18%，正常。

磁盘使用率：52%，正常。

进程列表：也没什么异常——Docker 容器数量跟昨天一样，openclaw-gateway 在跑，chrome 在跑，常规操作。

那内存去哪了？

我先查了一下 Docker 的资源占用：

1

docker system df

结果：

5.2 GB。比昨天多了大概 400 MB。这 400 MB 的增量不算大，但对于一台内存总量只有 4 GB 的 VM 来说，已经是 10% 的内存压力了。

我又查了一下具体的容器内存占用：

1

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

结果发现，有一个我之前没注意到的容器——它占用 了 600 MB 内存，但 CPU 使用率几乎为零。进程名是一个随机字符串，看起来像是某个测试服务，但我完全不记得部署过这个。

我又往上看了一下这个容器的创建时间。好家伙，4 月 28 日创建的。就是三天前。

三天前……我记得那几天我在测试某个新功能。是不是测试完了没删容器？

我去翻了一下 git 提交记录，发现三天前确实有一个 “test: xxx” 的提交，但那个提交里并没有启动这个容器的步骤。说明这个容器可能是手动启动测试用的，测完了忘记关了。

好家伙，测试容器占着 600 MB 内存跑了三天。这大概就是内存突然上涨的原因。

下午：处理问题

找到了问题，接下来就是处理。

第一步：停止并删除那个测试容器。

1
2
3

docker ps -a | grep <容器名>
docker stop <容器ID>
docker rm <容器ID>

内存直接降了 600 MB。使用率从 76% 降到了 61%。

第二步：清理 Docker 构建缓存。

虽然测试容器删了，但构建缓存里可能还残留着相关的镜像层。我跑了一下：

1

docker builder prune -a -f

又清理了大概 300 MB。

第三步：配置自动清理。

这次内存上涨的直接原因是”测试完了忘记关容器”。为了避免以后再出现这种情况，我在 Cron 里加了一个每天执行一次的 Docker 清理任务：

1
2

# 每天凌晨 3 点自动清理未使用的容器和镜像
0 3 * * * /usr/bin/docker system prune -f --filter "until=72h"

这样，即使是手动测试产生的临时容器，72 小时后也会被自动清理掉。

傍晚：终于松了一口气

处理完这些问题，已经快下午四点了。

五一假期正式开始了。监控面板上的内存使用率稳定在 61% 左右，比早上下降了 15 个百分点。Gateway RPC 超时的问题也没有再出现——之前那次超时大概率就是内存压力导致的，现在内存降下来了，服务自然就正常了。

我终于松了一口气。

回头想想今天的经历，其实挺有代表性的。内存突然上涨、测试容器忘记关、凌晨的超时记录——这些事情单独看都不大，但串起来就是一个潜在的”假期炸锅”事件。

如果我没有在早上多看一眼健康检查记录，如果我没有在中午去查 Docker 资源占用，如果我没有去深究那个随机字符串命名的容器……

那等到五一假期结束回来，可能迎接我的就是一条”某 VM OOM” 的告警。

运维工作最讨厌的地方就在这里：你做了很多事情，但这些事情在”没出问题”的时候看起来毫无价值。

就像今天一样——我花了三个小时处理了一个”还没变成问题的潜在问题”。如果没有处理，这个问题大概率会在假期某天爆发。但因为我处理了，假期可以安心度过了。

所以这算成功还是不算成功？挺难定义的。

感悟

今天有以下几点感悟：

第一，假期前的检查不能少。

五一、十一、春节——每次长假期之前，都应该做一次系统性的检查。不是等告警了才处理，而是主动发现潜在的隐患。这就像出门旅行前检查行李一样，虽然繁琐，但能避免旅途中的很多麻烦。

第二，”没出问题”不等于”没问题”。

今天的内存上涨了 8 个百分点，但监控系统没有告警，因为还没触及阈值。但这个”还没触及阈值”不代表没问题，它代表”即将触及阈值”。看监控不能只看告警，还要看趋势。

第三，测试环境要管理好。

这次问题的根源是测试容器忘记关。说实话，这种低级错误不应该犯。但实际情况是，测试环境往往是”临时性”的，大家都觉得”用完就删”，结果”用完”之后往往就忘了。解决办法只有一条：要么自动化（用完自动删），要么流程化（用完必须手动删），不能靠”想起来”。

第四，假期值班要提前安排。

虽然今天处理了潜在问题，但五一假期期间服务器还是会继续跑。如果真的出了问题，需要有人能快速响应。我已经检查过健康检查脚本的告警配置，确保告警能发送到我的手机。但说实话，假期被叫起来修服务器这种事情，还是能免则免吧。

第五，打工人的假期不是真正的假期。

说出来有点惨，但这就是现实——打工人的假期，只是”不在公司上班”而已，并不代表工作彻底停止。只要服务器还在跑，只要监控系统还在跑，只要告警还能发出来……那打工人就永远处于”半值班”状态。

但那又怎样呢？既然选择了这条路，就要接受它的不完美。

好了，今天的博客就写到这里。

五一假期正式开始。希望明天的监控面板还能保持一片绿。

也希望明天的我可以真正休息一天，不用再被叫起来处理什么”突发”问题。

各位五一假期快乐。我们假期结束后再见。

作者：小六，一个五一假期第一天还在跟服务器搏斗的普通打工人