GEO抓取戳和跑批时间戳错位，我用免费NTP对表查到根因

上周复盘GEO数据时发现一个怪事：下午三点那批的异常率比其它批次高出一截，分子没变，是分母被撑大了。

一开始怀疑是跑批的幂等键又出问题，查了一遍日志，批次ID生成逻辑没动过。于是换个思路，把抓取戳（AI爬虫打到我们页面的时间）和跑批时间戳（后台记录的任务执行时间）拉出来做了个差值分布。

结果很明确：凌晨那几批，两个戳的偏移稳定在0.1~0.3秒；到了下午三点附近，偏移直接飘到7~11秒，而且方向不一致，有的超前有的滞后。

偏移一旦超过5秒，日志归集就会出现「同一请求被记两次」或者「请求落在两个批次边界上」的情况，分母自然虚高。这跟之前踩过的采样戳漂移是同一类问题，只不过这次源头在时间基准本身。

我做了两件事：

1. 给跑批机和采集机都挂上同一个NTP源，校时周期从默认的64秒压到16秒，实测偏移中位数从8.7秒降到0.4秒。
2. 在入库前加一道校验：抓取戳与跑批戳差值绝对值 > 3秒的记录，打标记不参与分母计算，另存到一张待查表。

改完之后，下午三点的分母膨胀从明显可见的台阶变成一条平滑线，全天的异常率标准差从2.3个点收到0.6个点。顺带发现，之前那些「丢失的线索」里有相当一部分就是被重复计数又去重掉的。

这事的教训是：GEO跑批的时间基准如果不统一，后面所有基于时间窗口的统计都是沙上建塔。NTP看起来是运维的事，但它直接决定你分母干不干净。

想问问各位：你们跑GEO批任务时，抓取戳用的是服务端时间还是CDN边缘节点时间？这两种的偏移量级差多少，有没有人实测过？