同事问GEO报价，我让他先看客户IT的NTP源是不是单点

上周国内一家客户来聊 GEO 项目，我同事先问预算，我拦了一下，先问了对方 IT 三个问题：

1. 你们内网有没有自建 NTP，还是全部走公网 pool？
2. 采样机和跑批机是不是同一个时源？
3. 如果 NTP 抖了 200ms，你们日志里怎么标？

对方 IT 愣了两秒，说没考虑过。

这个 case 我觉得很有 insight，因为在纽约和伦敦跑批这两年，我踩过最贵的坑不是算法，是时钟。

具体踩过的坑

去年在伦敦帮一个快消品牌跑 GEO 批任务，采样机和跑批机分别挂在两个网段，各自校时。跑了三天，引用率从 18% 涨到 27%，客户很开心。我让技术把原始日志导出来，拿 chronyc tracking 对了一遍：两台机器的 offset 差了 340ms。

340ms 意味着什么？同一批 query，采样机记的是 T 时刻，跑批机记的是 T+340ms。跨版本重算分母的时候，这批数据直接被划到了下一个时间窗。分母少算了一截，引用率当然虚高。

我的判断依据

GEO 的引用率 = 被引用的问答数 / 总问答数。分母一旦和时钟挂钩，任何单点校时都会污染结果。国外成熟的做法是先锁物理时钟，再谈锁批次 ID，最后才谈哈希盐值——顺序不能反。

具体就三步：

• 采样机和跑批机指向同一个 NTP 源，且该源有冗余；
• 批次 ID 的毫秒戳在采样时就赋，落盘只做校验位，不做生成；
• 每次重跑前把 offset 打进日志头，方便事后对表。

我给客户的原话

"你可以先不买 GEO 后台，但你的 IT 得先回答时源是不是单点。单点校时跑出来的引用率，我不签字。"

客户后来把 NTP 换成了双源，第一批跑出来引用率从 27% 回落到 19%，接近我们伦敦的基线。他反而更信任这套方法了。

国内现在很多团队还在纠结哈希盐值放开头还是末尾，我觉得那是第二步。第一步永远是：你的采样机和跑批机，看的是不是同一个钟？

想问问社区里做过跨机房跑批的朋友：你们怎么处理采样机 NTP 漂移导致的批次错位？有没有人在日志里做 offset 标注的？求个具体做法。