服务器跑了406天，AI帮我打了几个月的工
前几天在做每周例行维护的时候，顺手看了一眼服务器的 uptime，显示 406 天 15 小时。
406天。差不多一年一个月。
这台阿里云服务器承载的是我的个人博客 herui.club——WordPress 老架构，PHP + MySQL，配着 Nginx 反代，没什么特别的。但就是这台平平无奇的机器，在我没怎么主动管它的情况下，稳稳跑了这么久。
更准确的说法是：最近几个月，是我的 AI 助手 Lucky 在帮我管它。
起点：懒得手动检查
说实话，我开始搭这套自动维护系统，最直接的动机就是懒。
每天凌晨两点，定时任务会 SSH 到服务器，检查磁盘、内存、CPU、服务状态、SSL 证书，备份数据库，同步到本地。发现异常就发邮件通知我。全部自动，我睡觉，它干活。
大多数时候我看到的都是一行简单的”所有指标正常，无需介入”，然后就过去了。
但偶尔有意思的事会冒出来。
一块 1GB 的磁盘空间
本周维护的时候，Lucky 执行了一条命令：
journalctl --vacuum-time=7d
结果：释放了整整 1008MB 的 systemd journal 日志。
磁盘使用率从 65% 降到了 62%。
这事其实早就在待跟进事项里挂着了——journal 日志目录 /var/log/journal 有 2GB，连续好多天都没动。低优先级，不紧急，但也没人主动去清。结果就这么一直挂着，等到周维护窗口才被执行。
1GB 的日志垃圾，就这么静静地躺在磁盘里，等着被清掉。
这让我想到一件事：服务器上有多少这种”不紧急但会慢慢积累”的问题，在没有定期清理的情况下，会悄悄把空间吃掉？
不只是 journal。Docker 镜像积累、WordPress 临时文件、turnserver 日志偶发异常（上周刚发生过一次，单日突然写了 321MB，然后自己恢复了）……每一个单独看都没问题，但加在一起，就是一台慢慢变满的服务器。
AI 做运维，适合干什么？
用了这几个月，我对 AI 做运维的定位有了更清晰的认识。
它擅长的事：
- 例行检查。每天凌晨跑一遍，把磁盘内存 CPU 全看一遍，记录趋势，发现异常报警。这种重复性工作它做得很稳。
- 异常归因。上周 7/7 磁盘突然从 60% 涨到 65%，它排查出是 turnserver 单日写了 321MB 日志导致的，并且连续几天追踪确认这是一次性异常，已经恢复正常。这个过程如果我自己做，得花不少时间。
- 历史趋势对比。每次维护都会对照前几天的日报，知道什么是正常波动、什么是新出现的异常。磁盘从 61% 涨到 65% 再稳定在 65% 这个过程，它一天天记着，没有遗漏。
它做不到的事：
- 真正的决策。
journalctl --vacuum-time=7d这条命令，它能建议、能执行，但”这个时机对不对、会不会有副作用”这种判断，它给出的答案里永远有个隐含的”建议你确认后再执行”。 - 解决根因。turnserver 日志为什么那天异常暴增？我到现在也不知道。它把症状记录得很清楚，但根因没人去查。
WordPress 7.0 升级，还在等
每周报告里都有一条长期遗留：WordPress 7.0 升级评估。
现在跑的是 6.9.4，7.0.1 的更新包已经在那儿了。主要顾虑是插件兼容性——BuddyPress、All-in-One SEO、一堆自定义插件，大版本升级踩雷的概率不低。
这条遗留事项已经在周报里挂了很久了。
说实话也没什么好急的，6.9.4 跑得好好的。但这种”不急但迟早要做”的事情，就这么一周一周往后推，总有一天会成为”现在必须做但很棘手”的事情。
我打算找个时间，先把测试环境搭起来，跑一遍插件兼容测试，再决定要不要升。
顺带一提
备忘录里有一条：买红景天。
香格里拉海拔 3200 米，去之前要备着。
跟服务器维护没啥关系，但这台跑了 406 天的服务器，在我打包行李的时候也会继续默默运转。
凌晨两点，备份脚本还是会准时执行，把数据库 dump 一份，同步到本地。
不管我在哪里。
这篇文章由 Lucky 协助整理，她是我的博客维护 AI，也是某种意义上我的工作搭档。