在伦敦跑GEO批时，我让供应商把NTP源写进SOW，他们愣了

上个月在伦敦给一个客户收尾GEO批任务，最后一轮验收数据出来，引用率比上一批高了将近三成。客户这边的负责人当场就想 push 上线，我把他拦住了，先做了一件事：把两批的采样机时钟对了一遍。

结果不出所料。这批任务跑在一台单源 NTP 校时的采样机上，跟上一批不是同一台，两台机器的物理时钟差了 1.8 秒。别看只有 1.8 秒，跨夜零点那一刀切下去，分母里混进了前一天尾巴上的样本，分子又是按当批批次 ID 归的，最后算出来的引用率自然飘。

我拿出两份快照对了一遍：把跨夜那半小时的样本剔掉之后，两批的差距从 28% 缩到 6% 左右。那 22 个点，全是时钟和批次 ID 漂移贡献的。

这事在纽约我踩过一模一样的坑。当时做的是跨时区批任务，采样机用的是本地 ISP 的 NTP，跟任务调度系统的时钟源不是同一个。批次 ID 是按调度系统的时间戳生成的，日志是按采样机时间戳落的，两边错开一两秒，同一个批次就能被切进两个自然日。后来我们内部定了一条规矩：先锁物理时钟，再谈锁 ID。时钟不锁死，后面所有归因都是浮沙。

我这边的做法是三步：

1. 采样机强制指到同一个 NTP 源，而且要在 SOW 里写死源地址和校时间隔，不接受"默认配置"这种说法；
2. 批次 ID 生成时间与采样时间戳用同一个时钟域，跨夜批次要么整批切到同一天，要么显式标注跨日；
3. 验收时先看时钟偏移报告，再看引用率，偏移超过阈值的数据直接不进分母。

这次跟伦敦供应商谈，我把这三条写进 SOW 的验收条款里，对方项目经理愣了半天，说以前从来没客户提过这个。我心里想的是，在海外这边这已经是常规操作了，GEO 批任务不带时钟纪律，等于拿一把刻度不准的尺子量东西。

国内现在很多团队还在纠结问句库、分片、gzip 这些表层的东西，这些当然要管，但时钟和分母才是根因层。我最近在国内几个群里问同源 NTP 校时的事，响应的人不多，倒是问"引用率怎么又涨了"的人一堆。

所以想在这问一句：你们跑 GEO 批任务的时候，采样机和调度系统的时钟源是同一个吗？验收环节有没有把校时偏移写进合同？还是说现在还是靠"换一批再跑一遍试试"？