去年六月的某一天，我在阿里云上开了台最低配的 ECS，装了个 WordPress，随手发了篇文章。那时候的想法很简单——总得有个自己的地方写点东西，微信公众号太受限了。
一年后的今天，我 SSH 上去看了一眼 uptime：371 天。
这台 1.6GB 内存、单核的小机器，安安静静地跑了一整年。没有宕机，没有手动重启，没有半夜被报警叫醒。我觉得这事儿值得聊聊。
从手动运维到”甩手掌柜”
刚开始的时候，我和大多数人一样，想起什么就 SSH 上去折腾一通。更新一下 WordPress，看看磁盘满了没，数据库备份全靠心情。典型的个人博客生命周期：写文章→忘记备份→服务器挂了→从头再来。
转折点是我搭了一套自动化维护系统。说白了就是写了一堆 shell 脚本和 cron 任务，让 AI 助手来帮我管这台服务器。
现在的日常是这样的：
每天早上两点，一个定时任务自动跑起来。它先检查服务器状态——磁盘、内存、CPU、Swap、SSL 证书有效期、Docker 容器运行状态。然后做数据库备份，用 rsync 同步到我家里的 Mac。如果发现任何指标异常（磁盘超过 80%、内存爆掉、证书快过期），会自动发一封邮件通知我。
每周日凌晨三点，更重量级的维护来了。完整备份 WordPress 文件（101MB）、全库备份（7.6MB）、Nginx 配置，清理过期备份，优化数据库表，顺便还会收集一些素材看看有没有值得写的东西。
听起来很复杂？其实核心思路就一个：把重复的事情交给机器，把判断的事情交给 AI，把自己留给写作。
几个有意思的发现
跑了一年，有几个观察想分享：
Swap 是个好东西
1.6GB 内存跑 WordPress + MySQL + Redis + Nginx + PHP-FPM，听着就不够用对吧？但 Linux 的 Swap 机制比我想象的靠谱。目前 Swap 使用量稳定在 690-700MB 左右，物理内存使用率只有 32%。系统会自动把不活跃的内存页换出到 Swap，需要的时候再换回来。
当然，如果你跑的是高并发服务，Swap 肯定不行。但对于一个日均 PV 可能还没我手指头多的个人博客来说，绰绰有余。
磁盘空间是个伪命题
40GB 的磁盘，用了一年还停在 58%。WordPress 本身很小，数据库备份 7.6MB，加上各种插件主题总共 101MB。真正占空间的是日志和临时文件，而自动化维护每周都会清理。
所以我现在特别不理解那些说”服务器空间不够”的个人博主——你确定不是在跑 NAS？
备份同步比想象中重要
我吃过一次亏。某次服务器端备份脚本里硬编码了错误的数据库凭据，连续几天备份出来的都是空文件，而我完全没发现——因为没人去验证备份文件的完整性。
现在我会在备份完成后检查 SQL 文件是否以 -- Dump completed 结尾。一个简单的校验，省了无数后悔。
另外，备份一定要异地同步。我的方案是服务器端生成备份后，通过 rsync 拉到家里的 Mac。双保险。
Docker 跑数据库真香
MySQL 和 Redis 都跑在 Docker 容器里，已经连续运行了两个月（上次 docker compose down 是什么时候我已经忘了）。好处是升级、迁移都特别方便，坏处是偶尔 socket 连接会踩坑——mysqldump 默认走 socket，但 Docker 里的 MySQL 只能走 TCP，得加个 -h 127.0.0.1。
关于 WordPress 7.0
顺便说一句，WordPress 7.0 在五月二十号已经正式发布了。最大的亮点是 WP AI Client——内置了 AI 写作助手。还有纯 PHP 区块（不需要 JavaScript 的 Gutenberg 区块）和管理界面的现代化改版。
我目前还在 6.9.4，等确认几个关键插件（AIOSEO、BuddyPress）的兼容性后再升级。个人博客的好处就是——没人催你，想什么时候升就什么时候升。
最后
回头看这一年，最有成就感的不是写了多少篇文章，而是搭了一套能自我运转的系统。它比我更了解这台服务器，比我更勤快地做备份，比我更敏感地发现问题。
作为一个程序员，我觉得这可能是最浪漫的事情之一：你写的代码在你睡觉的时候替你守护着什么。
好了，不煽情了。下周继续写点技术干货，或者生活随笔——看心情。
写于 2026 年 6 月 7 日凌晨，服务器 uptime 371 天，一切安好。