周二上午，客户把一张截图甩到群里，说：你们看看，这个订单时间不对。

我点开一看，下单时间 10:23:41。实际下单大概在 10:24 左右。差得不多，但客户做对账，分秒必争，差一分钟就是问题。

我先查了业务服务器的时区。date 一下，GMT+8，没问题。然后查数据库的 time_zone：

SHOW VARIABLES LIKE '%time_zone%';

system_time_zone 是 CST，time_zone 是 SYSTEM，也没问题。当时我还挺自信，跟客户说可能是前端展示的问题，让开发看一下。

开发查了半天，回了一句：接口返回的时间戳就是错的，不信你们自己抓包。

我脸有点挂不住。抓包就抓包。抓完一看，响应体里的 created_at 和数据库里存的值差了 37 秒。业务服务器的时间，比数据库服务器快了 37 秒。

这时候我才想起来，这俩机器不是一批的。业务服务器是去年新上的，数据库服务器是五年前的老机器，中间还跟着机房搬过一次家。老机器上跑的还是 ntpdate——只在开机的时候同步一次时间的那种老古董。

查 /etc/ntp.conf，里面配的 NTP 源是 10.1.8.x 的内网地址，ping 了一下，不通。问了一圈，那个源是原来机房的，搬迁的时候下线了，没人记得来改这台机器的配置。

最坑的是，ntpdate 同步失败是静默的，不报错，日志里就一行 "no server suitable for synchronization found"，不仔细看根本不会注意。所以这台机器从搬迁那天起，时间就一直这么漂着。漂了大半年，漂出 37 秒。

修起来倒简单。装 chrony，改 /etc/chrony.conf，配两个公网源，再留一个内网备份源。systemctl enable --now chronyd。过几分钟看 chronyc tracking，偏移已经收敛到几十毫秒。

改完我以为这事就完了。结果过了两周，客户又来了，说时间还是不对。

这次是反过来的：数据库服务器时间准了，业务服务器也准。查到最后发现，是客户自己代码里写死了一个时区偏移量，跟服务器时间叠加了。开发默默改了代码，没再说话。我也没再追问，大家都是要面子的。

时间同步这个事，看着是最基础的，其实最容易烂在角落里。机器一多、批次一杂，总有那么一两台被遗忘。我后来把所有机器的 NTP 状态都加了监控，每周扫一遍 chronyc tracking，谁漂了谁没漂，一目了然。

反正时间这个事，总能以你想不到的方式再出问题。我能做的就是把监控摆在那，等它下次冒头。