上个月有位做在线教育的朋友找到我，说他们后台有个每天凌晨 3 点跑的数据同步任务，最近"隔一天才执行一次"，偶尔还会在 23:50 和 00:10 各跑一遍，同一批数据被处理了两次，数据库里冒出重复的课程记录。他一开始怀疑是 cron 表达式写错了，我让他先把系统时间看一眼，结果 `date` 输出比他自己电脑上的时间快了整整 90 秒。
90 秒不多，但在服务器世界里，它足以让定时任务错过触发窗口、让日志和监控的时间轴彻底错位、让证书的有效期判断提前失效。时钟这东西平时不吭声，一旦出问题就是连着几层业务一起难受。这篇就把 NTP 同步到底是个什么原理、时钟为什么会漂、漂了以后哪些地方会先坏，以及怎么用 chrony 把这一套彻底捋顺，一次讲透。
如果你手上的服务器需要长期跑定时任务、跑 HTTPS 站点或者做数据库主从，这台可以先了解一下：狗云DOGYUN（高性价比云服务器，多机房可选）、RackNerd（全球VPS，特价常推）。时钟问题不分机器档次，但凡机器要跑长活儿，时间就得先对得上。
一、NTP 到底在同步什么：不是一个时间，是四个量
很多人以为 NTP 就是"让服务器跟某个服务器的时间保持一致"，这句话没错，但太粗了。实际同步的时候，客户端跟时间服务器之间要处理四个量：
offset（时钟偏移量）：本机时钟跟对方时钟差了多久，这是要修正的核心；delay（网络往返延迟）：请求发出去到响应回来的时间，用来补偿；jitter（抖动）：延迟的波动程度，抖动大说明网络链路质量差；stratum（层数）：时间服务器自己又是跟谁同步的。NTP 服务器是分层的，stratum 0 是原子钟、GPS 授时这类硬件基准，stratum 1 直接跟 stratum 0 同步，stratum 2 跟 stratum 1 同步，以此类推。每多一层就会引入误差，所以挑上游服务器时，能连到 stratum 1 或 2 最好。
注意 offset 和 delay 是两码事。offset 是"你慢了多少"，delay 是"网络慢了多少"。网络延迟高不等于时钟不准，但高延迟会让 offset 估算变毛糙，进而出现反复校正、时钟来回跳的现象那种"越同步越不准"的情况，多半是延迟太抖导致的。
二、时钟为什么会对不上：三个最常见的原因
第一个原因是根本没装同步服务或者服务没起来。很多人拿到一台云主机就直接用了，systemd-timesyncd 或者 chronyd 压根没装。机器在机房放几个月，RTC 硬件时钟因为电池掉电、或者长期微小偏差慢慢积累，几十秒到几分钟的漂移就是这么来的。
第二个原因是虚拟机或者容器的时钟是"借"来的。KVM 虚拟机的系统时钟默认跟着宿主机走，宿主机一重启，所有虚拟机的时间可能集体跳一下。更麻烦的是容器容器有自己的命名空间时间视图，如果宿主机时间本身不准，容器里会更离谱。还有一种常见情况是容器所在宿主机做了时钟隔离，容器里 `date` 显示的时间和宿主机差了好几秒，此时容器内跑的任何时间判断都是错的。
第三个原因是上游时间服务器不可达，而客户端配置得又很"刚"。strong>chrony 的默认配置里，如果连不上上游，可能会在本地慢慢漂移甚至停止校准；而 ntpd 在某些发行版里遇到上游不可用会直接退出。更麻烦的是国内机房出网受限，配置的 `pool.ntp.org` 根本 ping 不通，同步服务一天都没成功过，自己却毫不知情。
三、时钟漂 90 秒，先坏掉的三个地方
第一个坏掉的是定时任务。crond 判断"当前时间是不是命中了分钟字段"，命中就执行。你以为 3:00 触发，实际机器时间已经是 3:01:30，任务还是能跑；但反过来，机器时间慢 90 秒，3:00:00 那一刻服务器还认为是 2:58:30，任务会被推迟到 3:01:30 才跑。如果这个任务还带"防重复执行"的锁，而锁的判断也用系统时间，就可能出现上一轮还没结束下一轮已经开始，或者干脆跳过一轮。
第二个坏掉的是 HTTPS 证书。证书上有 notBefore 和 notAfter 两个时间戳，客户端握手时会拿自己的本地时间和这两个点比较。如果本机时间偏了，握手阶段就会直接失败，报出来的错还特别有迷惑性浏览器说"证书已过期"，你登进去看证书详情，明明还有一个月才到期。这就是那种让人抓狂的场景。
第三个坏掉的是数据库和监控。MySQL 主从复制依赖时间戳判断复制进度，机器时间乱跳会让延迟统计失真，严重时从库甚至会拒绝应用事务；Zabbix、Prometheus 这类监控系统则会因为采样时间错位，把告警时间和故障时间对不上，等于把你唯一的排查线索给毁了。日志也是同样道理两台机器的日志混在一起按时间排序，顺序全乱。
四、动手排查：四个命令定位问题
第一步看系统自己怎么说：
timedatectl 会输出本地时间、UTC 时间、是否同步、当前使用的 NTP 服务和最后同步时间。一句 `synchronized: yes` 都没有，先别往下查了，同步根本没生效。
第二步看 chrony 的内部状态：
chronyc tracking 看整体状态，System time 那一行是 offset 和频率漂移，Leap status 正常应该是 Normal；chronyc sources -v 逐个看上游源的状态，`^*` 表示当前选中的源，`+` 表示可用但没选中，`?` 表示不可达，offset 和 delay 都有具体数值。这里是最容易看出问题的地方如果所有源都是 `?`，那就是网络出不去或者上游地址写错了。
第三步看偏移到底有多大：chronyc makestep 可以把当前大偏差一次性校正掉（超过阈值时立刻跳变而不是慢慢追），chronyc tracking 里的 Last offset 就是这次跳了多少。
第四步看硬件时钟：hwclock --show 对比硬件时间和系统时间，如果两者差得远，说明系统时间被硬生生掰过；hwclock --systohc 可以把系统时间写回硬件时钟。云主机通常没有可写的 RTC，跳过这一步。
五、把 chrony 配对：一份能直接用的配置
国内机房建议直接用云厂商提供的内网授时源，不用绕公网。国内云基本都能连内网的 NTP 服务，比如阿里云的 `ntp.cloud.aliyuncs.com`、腾讯云的 `time1.cloud.tencent.com`，延迟能压到 1ms 以内，比公网源稳定得多。配置大致是这样：
server ntp.cloud.aliyuncs.com iburst
server 阿里云内网地址 iburst
makestep 1.0 3
rtcsync
逐行解释：iburst 表示开机后立刻连几次，快速拿到一个初始校正值；makestep 1.0 3 的意思是开机后的前 3 次校正，如果偏差超过 1 秒就直接跳变对齐，之后再出现大偏差就只做平滑调整，避免正在跑的服务被时间跳变打断；rtcsync 让系统时间周期性写回硬件时钟，云主机上这行可以省掉。
改完记得 systemctl restart chronyd，然后 chronyc sources -v 确认源的状态变成 ^*。如果是 Debian 系，systemd-timesyncd 和 chronyd 别同时开，两个服务抢同一个 socket 会互相干扰。
六、几个容易忽略的细节
时区和时间是两回事。很多服务器设成 UTC 完全没问题，前提是你知道自己是 UTC。但如果你直接用本地时间跑 cron 却没设时区，或者夏令时切换那天定时任务跳了一小时，那就属于自己给自己找麻烦。国内服务器统一用 Asia/Shanghai 就行。
闰秒也要提一句。Linux 内核在 2017 年之后改成了"闰秒涂抹"策略，把多出来的这一秒摊到一天里慢慢消化，所以一般不用你操心。但如果你用的是 ntpd 老版本，或者容器镜像里塞了自己编译的时间库，就可能在这一天出现 1 秒的跳变，敏感的业务（比如金融对账、按秒计费的接口）建议提前验证一次。
容器环境还有一条：Docker 默认给容器的是宿主机的时间视图，容器里的 timezone 文件只是改显示格式，不改实际时间。如果你的容器跑在多台机器上做定时任务，那这几台机器的时间必须都同步到位，否则同一份 cron 在不同机器上的执行顺序会乱。
七、写在最后
时钟是最容易被忽视的基础设施。它不报错、不告警、不占资源，只是安静地慢慢跑偏，等你发现的时候，cron 跑了两遍、证书握手失败、监控时间轴对不上，排查起来还得倒推半天。真正省心的做法是：新机器上线的时候就把 chrony 配好，顺手加一条监控chronyc tracking 里的 offset 超过 1 秒就告警。这件事花不到十分钟，却能省掉以后几个通宵。
如果你也在处理定时任务不准、证书莫名过期或者日志时间对不上的问题，不妨先按上面的四个命令过一遍，大概率能定位到方向。毕竟，一个连自己几点几分都不知道的服务器，迟早要在别的地方还回来。
喜欢 
顶
难过
囧
围观
无聊
