--- title: 上线巡检该查什么：10 项检查与一条告警链路 url: https://vabora.dev/posts/launch-health-check author: Vabora published: 2026-08-14 09:00:00 updated: 2026-09-27 10:33:42 category: 最佳实践 tags: 最佳实践, 架构设计, 运维 canonical: https://vabora.dev/posts/launch-health-check license: 转载与引用请注明出处并保留原文链接 --- # 上线巡检该查什么：10 项检查与一条告警链路 > 站点上线后最常见的故障不是"崩了"，而是"悄悄坏了"：磁盘满了、日志全是错误、备份三个月没跑。用一条命令把 10 项检查固化，异常自动推到群里。 ## 背景 上线后最危险的状态不是 500，而是**半坏**： - 缓存目录忽然不可写 → 页面变慢，但没人报错； - 备份任务三个月前就失败了 → 直到需要恢复时才发现； - 管理员口令还是安装时的默认值 → 扫描器一晚上就能试出来； - 磁盘 92% 满 → 再过两天会话文件写不进去，全站登录失效。 这些都不会主动告诉你。所以要做两件事：**把检查固化成一个命令**，**把异常推到你会看到的地方**。 ## 十项检查 ```bash php vabora health ``` ```text [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 反复吵。 ## 一条最小告警链路 ```bash # 每小时巡检一次，异常时推群 0 * * * * cd /var/www/vabora && php vabora health >/dev/null 2>&1 ``` `.env` 里填上机器人地址即启用： ```dotenv 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` 才值得半夜叫人。 - **告警要克制**：宁可漏报也不要在非致命项上反复推送。人对告警的信任是会被消耗的。