定时任务凌晨配置白天跑？先查时区

典型症状#

• 服务每天固定时刻出现几百条超时/500，持续十几分钟，然后自愈
• 配置/文档里写的是凌晨低峰执行维护，实际运行时间却是白天工作时间
• 维护任务耗时随数据量增长逐日恶化（今天 2 分钟，下周 20 分钟）

排查路径（按序，命中率高）#

1. 按分钟聚合 ERROR/WARN，找爆发窗口 不是看单条错误，而是看分布。grep '"level":"ERROR"' log | 按 time 分桶统计，错误会聚成一个明显的尖峰。

2. 与维护任务起止时间对齐 找 VACUUM / GC / backup / checkpoint 这类任务的 Start/Complete 日志，比对是否与错误窗口严丝合缝。能对上 = 找到元凶。

3. 看维护任务耗时趋势 VACUUM 之类每天都会记录 duration，统计 7 天趋势——持续恶化 = 数据增长型问题。

4. 源码确认 Timezone（关键一步） grep Timezone 调度注册代码。凡是 Timezone: "UTC" + 服务器在 UTC+8，直接把 UTC 时间 +8 才是真实执行时刻。

举例：cron 写 0 2 * * *（凌晨 2 点），如果调度用 UTC，那它在 UTC+8 就是上午 10 点 执行——工作时间黄金时段。

两条铁律#

铁律一：配置”低峰时间”前，先确认调度时区。凌晨配置白天执行，先查时区，别查业务逻辑。

铁律二：排查”固定时刻故障”时，不要一开始就查业务代码，先看有没有每日维护任务在这个时刻跑（VACUUM / 备份 / 清理 / 缓存重建都是候选）。

放大因素：数据只进不出#

这类故障常被一个隐藏问题放大：存储策略默认关闭清理。

请求日志只进不出，DB 7 天涨到 8GB，所有全表操作（VACUUM / 备份 / 查询）逐日变慢，维护窗口越拖越长，最终撞进工作时间。

教训：“默认不清理”对日志型表是定时炸弹。启用保留策略（如请求日志保留 7 天），让库停在固定水位。

守护进程的”假死”特性#

守护进程维护类操作（VACUUM / 全量备份）对在线服务的杀伤方式很特别：锁库期间所有请求超时 → 对外表现为 500 或超时，且进程本身没崩。

监控看起来一切正常（CPU 不高、内存正常、进程存活），但用户疯狂 500。这是”假死”不是”崩溃”，不会触发重启告警，特别容易漏判。

结论#

记住这套症状指纹：每日固定时刻 500 + 维护任务在同一时刻 + 进程没崩。下次遇到，第一反应不是去读业务代码，而是 grep Timezone 看调度时区——这一步能省你一整天瞎排查。