1. 默认凭据已经全部更换#

示例配置中的 change-me、默认管理员密码、测试 Token 都必须更换。随机密钥应足够长，并且每个服务单独使用，不能共用一个密码。

2. 敏感信息没有进入 Git#

提交前检查：

1
git status
2
git diff --cached
3
git log -p --all -- .env

.env、私钥、数据库连接串和 API Key 都不应出现在仓库中。仅仅在最新提交中删除还不够，因为旧提交仍然可以被查看；一旦泄露，应立即轮换对应密钥。

3. 管理端口没有直接暴露#

数据库、Redis 和应用管理端口通常只需要容器内部或本机访问。Docker 端口映射可以绑定到回环地址：

1
ports:
2
  - "127.0.0.1:8787:8787"

公网流量统一通过反向代理进入，能够减少不必要的暴露面。

4. HTTPS 配置完整#

检查域名是否强制跳转 HTTPS、证书是否能自动续期。如果使用 Cloudflare，源站也应配置有效证书，并尽量使用 Full (strict) 模式。

1
curl -I https://example.com

5. 登录入口有基本防护#

后台至少应具备强密码和登录频率限制。有条件时开启两步验证、访问 IP 限制或 Cloudflare Access。后台地址改得很隐蔽并不能代替真正的身份验证。

6. 容器设置了重启策略#

1
restart: unless-stopped

这样服务器重启或进程异常退出后，容器可以自动恢复。不过，自动重启不是健康检查的替代品，应用仍然需要提供可验证的健康状态。

7. 健康检查真实可用#

健康检查不应该只返回固定的 200，最好同时检查关键依赖，例如数据库或 Redis 是否能正常连接。

1
curl -fsS http://127.0.0.1:8787/health/ready

8. 日志不会无限增长#

Docker 默认日志长期积累后可能占满磁盘。可以配置日志轮换：

1
logging:
2
  driver: json-file
3
  options:
4
    max-size: "10m"
5
    max-file: "3"

还应定期查看 df -h 和 docker system df，确认磁盘空间没有异常增长。

9. 重要数据有备份#

需要备份的是“无法重新生成的数据”，例如数据库、上传文件和应用配置。Docker 镜像通常可以重新拉取，不一定需要备份。

备份至少保存一份到另一台机器或对象存储。只放在同一块 VPS 磁盘上的副本，无法应对磁盘损坏或服务器丢失。

10. 备份做过恢复测试#

没有恢复过的备份，只能算一种希望。最好定期在临时目录或测试环境中执行一次恢复，记录准确步骤和所需时间。

11. 更新过程可以回退#

更新前记录当前 Git 提交和镜像版本：

1
git rev-parse --short HEAD
2
docker compose images

不要只使用无法追踪变化的 latest 标签。至少要知道出现问题时应该回到哪个版本。

12. 自己能收到故障通知#

服务宕机如果无人知道，健康检查就失去了大半价值。个人项目可以使用简单的外部可用性监控，每隔几分钟请求一次健康检查地址，并通过邮件或即时消息通知。

最小维护节奏#

我更倾向于建立一个不会带来负担的节奏：

• 每周查看一次容器状态和磁盘空间
• 每月安装系统安全更新
• 每月确认备份任务成功
• 每季度做一次恢复演练和密钥检查

写在最后#

个人服务不需要堆满复杂工具，但一定要知道数据在哪里、入口在哪里、出问题以后怎样恢复。把这 12 项做完，不能保证服务永远不出故障，却能让大多数故障从“灾难”变成一次可处理的维护工作。