上线巡检该查什么：10 项检查与一条告警链路

#背景

上线后最危险的状态不是 500，而是半坏：

• 缓存目录忽然不可写 → 页面变慢，但没人报错；
• 备份任务三个月前就失败了 → 直到需要恢复时才发现；
• 管理员口令还是安装时的默认值 → 扫描器一晚上就能试出来；
• 磁盘 92% 满 → 再过两天会话文件写不进去，全站登录失效。

这些都不会主动告诉你。所以要做两件事：把检查固化成一个命令，把异常推到你会看到的地方。

#十项检查

php vabora health

  [ok   ] 安装状态 已完成安装（storage/install.lock）
  [ok   ] 运行模式 production / 调试已关闭
  [warn ] 管理员口令 仍在使用安装时的默认口令
           → 登录后台后在「个人资料」里改掉
  [ok   ] 数据库    SQLite 可读写（WAL 已启用）
  [ok   ] 目录权限 缓存/会话/上传目录可写
  [ok   ] 磁盘空间 剩余 412 GB
  [ok   ] PHP 扩展   pdo、mbstring、openssl、fileinfo、json、pdo_sqlite 均已加载
  [ok   ] 错误日志 今天没有 ERROR
  [ok   ] 备份时效 今天已备份

结果：ok 9 / warn 1 / error 0

每项都带修复建议，而不是只报"失败"——半夜看到告警的人需要的是下一步做什么。

几个检查的设计细节：

• 数据库可写：SQLite 会执行一次 BEGIN IMMEDIATE 再回滚。能开能回，说明不仅连得上，而且没有长事务卡着写锁。
• 错误日志：读当天的 ERROR 条数。warn 不阻断，error 才算失败——否则"有错误日志"会天天报警，很快就没人看了。
• 备份时效：取 backup/ 里最新归档的修改时间，超过 7 天提醒。
• 退出码：有 error 返回 1，只有 warn 返回 0。cron 里能直接用，不会被 warn 反复吵。

#一条最小告警链路

# 每小时巡检一次，异常时推群
0 * * * * cd /var/www/vabora && php vabora health >/dev/null 2>&1

.env 里填上机器人地址即启用：

ALERT_WEBHOOK=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx

企业微信与钉钉用 {"msgtype":"text","text":{"content":"…"}}，Slack 与自建端点用 {"text":"…"}——按域名自动适配，不用改代码。推送失败只记录、不影响退出码：通知通道坏掉不该让巡检本身失败。

#结果

• 巡检从"上线前想起来查一遍"变成每小时自动跑；
• 首次跑就抓出一条真实问题：(bool) "false" 在 PHP 里是 true，导致调试模式被误判为已开启——这类"判断写错"的 bug，靠人眼审代码很难发现，靠检查项一跑就露出来；
• 磁盘、日志、备份三件事从"想起来了看看"变成"异常才出现"。

#取舍

• 不做进程级监控：health 是拉取式的，回答"站点现在还正常吗"。至于"PHP-FPM 进程还在不在"，那是外部可用性监控（UptimeRobot 之类）打 /api/ping 的事，两者互补而不是替代。
• 不自动修复：只报告和建议。自动清理日志/自动改配置在半夜跑起来很危险——warn 交给早上的人判断，error 才值得半夜叫人。
• 告警要克制：宁可漏报也不要在非致命项上反复推送。人对告警的信任是会被消耗的。