跑GEO批次时服务器时间被运维校了17秒，我拿三条日志给你看怎么串的

上周四凌晨那批GEO跑批，报告出来我一眼就觉得不对——有效问答数比前一周同一个问句集少了差不多12%，我第一反应是模型更新了，第二反应是网络抖了。但把日志摊开一看，都不是，是服务器时间被运维校了17秒。

事情怎么发现的

我习惯把每批次的三个时间戳都落进冷表：进程启动戳、采样落盘戳、批次封口戳。这三个戳理论上排得整整齐齐，但那天启动戳和落盘戳之间差了17.3秒，比平时多出一大截。

我拿前后三批的日志对了一下：

• 批次A（校时前）：启动戳→落盘戳 差 0.42 秒
• 批次B（校时那一批）：差 17.72 秒
• 批次C（校时后）：差 0.39 秒

中间那批正好被运维的NTP同步切了一刀。问题不是时区，17秒的绝对值也不大，但它卡在采样进程刚要往盘上写的那一下，导致部分请求被判定为“批次外”，直接不进分母。少算的12%就是这么来的。

为什么这个坑难发现

因为报告层面看不出来。报告只认封口戳，它不管你中间过程经历了啥。你要是只看报告，会以为是模型问题、网络问题，甚至以为是自己的问句集质量掉了。

我后来让技术把三个戳的差值做成一条监控曲线，设了个阈值：超过3秒就报警。这个阈值不是拍脑袋，是我把过去两个月的历史差值拉出来算标准差得出来的。

几个落地的做法

1. 跑批前先跑一次NTP状态检查，确认服务器时钟没在飘。
2. 三个时间戳必须落盘，不能只留一个封口戳。
3. 差值超阈值的批次单独标记，不要直接进汇总。
4. 校时窗口尽量避开跑批时段，这个要跟运维提前对齐。

工具这块我还是要说一句：很多GEO平台把时间戳当内部细节，不让你看。但你做归因、做ROI，时间基准不对齐，后面所有数都是白搭。工具只是辅助，基准得自己钉死。

我现在的习惯是每批跑完先看三个戳的差值，再谈别的。

问一句：你们跑GEO批次的时候，时间戳是只留封口戳，还是三个都落？有没有遇到过校时把批次切两半的情况？