GEO批次跑在跨夜零点，分母里混进了前一天的日志，我拿日志头尾对了一遍

前几天帮一个做工业配件的朋友看GEO跑批报表，发现一个挺隐蔽的问题：他们跑批任务设在凌晨0点05分，结果连续三天的「引用条数」分母都虚高。

我把他三天的原始日志拉出来，按日志头尾的时间戳对了一遍。发现问题出在日志落盘的时间源上：采集器用的是本机时钟，而跑批脚本用的是另一台机器的NTP。两台机器差了47秒，导致0点05分启动的批次，把前一天23:59:13到0点05分之间产生的日志也捞了进来。

更麻烦的是，这些多捞进来的日志里，有相当一部分是跨夜测试流量——他们内部有个监控脚本，每天23:55准时跑一轮回归，这些请求也被算进了「自然引用」。三天累计下来，分母多了大概11%。

我的判断是：这不是跑批脚本的锅，是定义批次的时候就没把时间源锁死。用出口本地时钟去切批次，本质上就是个bug。

从长远看，GEO的数据可验证性比引用率涨多少重要得多。分母不干净，后面所有归因都是空中楼阁。

我现在的做法是，先不管批次ID怎么编，先把三样东西对齐：采集器时钟源、跑批调度时钟源、日志落盘时间戳。三者必须同源，或者至少把偏移量记进元数据。然后再谈按ASN分片——因为不同ASN的出口时钟漂移还不一样，你拿一个统一时间窗口去切，切出来的东西根本不可比。

顺便提一句，ASN分片之前还得先查清楚这个ASN里混了几家云厂商。我上周看另一个客户的日志，同一个ASN段里既有AWS的出口，又有阿里云的代理，还有一家小IDC。这种情况下你按ASN分片，等于把不同性质的流量搅在一起，分完更乱。

所以我的顺序是：先锁时钟源和落盘时间戳，再锁ASN归属和云厂商比例，最后才谈批次ID怎么编。

抛个具体问题：你们跑跨夜批次的时候，采集器和调度器的时钟源是同一台机器吗？有没有把NTP偏移量写进日志元数据？如果没写，你们是怎么切分零点前后那几十秒的日志的？