“基础设施”这个词通常让人想到机房、集群、负载均衡。但对一个人维护的个人站点来说，真正的基础设施要朴素得多：它是一组让你在半年不碰之后，仍然能说清楚“东西在哪、怎么跑、坏了怎么办”的东西。
我把自己实际在维护的部分列成了十项。它们不是理论清单，而是我这两年陆续补上的；每一项都对应过一次具体的麻烦。
十项基础设施
| 项目 | 最低要求 | 我现在的做法 | 检查频率 |
|---|---|---|---|
| 域名与 DNS | 知道在哪里注册、解析指向哪 | 注册商 + 两条 A/CNAME 记录 | 每年续费前 |
| 服务器 | 能远程登录、能重装 | 一台低配云服务器 + 快照 | 每月 |
| TLS 证书 | 到期前能续、能部署 | 自动申请与续期，失败告警 | 每周（自动） |
| 备份 | 至少一份异地、可恢复 | 每日增量 + 每周全量 + 季度演练 | 每日/每季度 |
| 监控告警 | 站点挂了能知道 | 五分钟一次可用性检测 | 持续 |
| 日志 | 出问题能查、磁盘不会满 | 统一目录 + logrotate | 每月 |
| 文档 | 换机器能照着做 | 一页部署文档 + 一页恢复文档 | 每季度 |
| 变更记录 | 知道最近改了什么 | Git 提交 + 一页变更日志 | 每次变更 |
| 账号与密钥 | 不共用、可轮换 | 独立账号、密钥文件限权 | 每半年 |
| 预算 | 知道一年花多少 | 一张固定支出表 | 每年 |
这张表里没有一项是“高级”的。它们更像家里的配电箱、灭火器和备用钥匙：平时想不起来，出事时决定你能不能快速恢复。
最容易被忽略的两项
第一项是文档。 我曾经自信地认为“都在我脑子里”。直到有一次换服务器，我在新机器上花了三个小时才想起证书的续期脚本放在哪个目录、定时任务用的是哪个用户。那三个小时里，我翻遍了旧机器的 /etc、/home 和 shell 历史。
现在我只有两页文档：一页写“怎么从零部署”，一页写“出问题怎么恢复”。文档不追求完整，只追求“半年后的我照着能做出来”。每次变更后如果文档没更新，我会把它当成一次未完成的变更。
第二项是变更记录。 Git 记录了代码差异，但很多变更不在代码里：改了 Nginx 配置、调了防火墙、换了证书、升级了系统。这些如果没有记录，故障时就会变成“我记得好像改过什么”。
我的做法很土：在仓库里放一个 CHANGELOG.md，只写日期、改了什么、为什么改、怎么回滚。三行就够，但三个月后非常有用。
监控不是越多越好
我见过有人给个人博客配了十几个告警：CPU、内存、磁盘、连接数、5xx、证书、DNS、备份、构建失败。结果是每天收到一堆通知，最后全部静音。
我现在只保留四类告警：
- 站点连续两次不可用；
- 磁盘超过 85%；
- 备份连续两天失败；
- 证书剩余不足 14 天。
其他的指标照常采集，但不主动通知。告警的价值在于“值得半夜起来看”，不是“证明我在监控”。
每季度一次的检查
每季度我会花一个小时，按清单过一遍：
- 恢复一个备份文件，确认能打开；
- 手动续期一次证书，确认流程没坏；
- 看一遍磁盘和日志增长趋势；
- 检查域名和服务器到期时间；
- 更新文档里过时的路径和命令；
- 算一下今年的固定支出。
这个习惯坚持了两年。它没有让我“不出故障”，但让我在故障发生时少了很多手忙脚乱。
清单不是目的
列清单容易，维护清单难。这张表真正的作用不是让我“显得专业”，而是把那些容易被忘记的事，变成有固定时间点的事。
个人站点最大的风险从来不是流量太大，而是维护者停下来之后，系统变成一团没人能解释的东西。基础设施的意义，就是让它在被放下一段时间之后，还能被重新捡起来。