阿里云 NTP 时间不准？先看这几个配置点

服务器时间偏差一开始往往不显眼。日志里的时间戳差几秒，很多人会先当成正常误差放过去。但时间一乱，影响会沿着链路往外扩。分布式系统靠时间判断事件先后，TLS 证书校验依赖有效期，Kerberos 认证对时间误差也很敏感。一台机器慢了几秒，就可能出现登录失败、订单重复，或者监控告警对不上。所以在阿里云上为服务器配置稳定的时间源，最好在初始化阶段就做，而不是等出了问题再补。

阿里云提供的 NTP 服务（网络时间协议）可以让云主机与标准时间源保持同步。下面用一个案例说明它的用法，再列出常见的失败原因和对应的检查方法。

案例：订单日志对不上的一次排查

某电商团队在大促期间发现，支付回调日志和订单服务日志的先后顺序经常颠倒。开发同学最初怀疑是消息队列有延迟，查了好几个小时，才发现部分应用服务器的系统时间比标准时间快了约 3 秒，数据库所在主机的偏差却是反方向的。两边叠加在一起，时间线就完全不可信了。

根源其实很简单：各节点没有统一指向可靠的时间源。团队后来把所有 ECS 实例都指向阿里云内网 NTP 服务，并用 chrony 完成同步。修改之后，日志时间线恢复正常，链路追踪里的耗时统计也重新能拿来做判断。这个案例的提醒是，排查业务问题前，先确认时间本身是准的，否则看到的所有先后关系都可能是假的。

配置步骤

多数 Linux 发行版默认使用 chrony 做时间同步。下面是一份基础配置，仅供参考，具体参数请以阿里云官方文档和你所用的系统版本为准：

# /etc/chrony.conf
server ntp.cloud.aliyuncs.com iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

这几个参数值得看一眼。iburst 会在启动时快速连续发出多次请求，让首次同步更快完成。driftfile 记录本机时钟的漂移规律，重启后能更快收敛。makestep 1.0 3 的意思是：在前 3 次校时中，如果偏差超过 1 秒，允许直接跳变校正。rtcsync 则会把系统时间同步到硬件时钟。

改完配置后执行 systemctl restart chronyd 重启服务，再用 chronyc sources -v 查看时间源状态。列表里某个源前面带 * 号，表示它已被选为当前同步源，这就是正常状态。如果没有任何一个源带 *，先别急着改配置，往下看排错部分。

常见问题与排错思路

实际操作中，时间同步失败基本集中在下面几类情况，可以按顺序逐个排除。

网络不通：安全组或本机防火墙没有放行 UDP 123 端口。排查时先看这一项。可以用 chronyc tracking 查看 System time 和 Last offset，如果偏移量长时间不收敛，或者持续变大，大概率是链路问题。
时间源选错：ECS 实例应优先使用阿里云内网地址，延迟更低，也不占用公网出口。公网地址更适合非阿里云环境。跨地域或混用多种公网源，有时会带来额外的延迟和抖动，反而让偏移量波动更大。
虚拟机时钟漂移：部分虚拟化环境里，宿主机调度会影响虚拟机的时钟走速。这时可以确认 driftfile 是否正常写入，并检查 rtcsync 是否生效。如果同步结果总在变化，除了看 NTP 配置，也要看宿主机层面的情况。
多个时间服务互相干扰：有些系统同时开着 systemd-timesyncd 或 ntpd，会和 chronyd 抢着修改时间。停掉多余的服务，只保留一个时间同步进程，问题往往随之消失。可以用 timedatectl 查看 NTP synchronized 的状态，确认只有一个服务在管理时间。
首次校时跳变过大：偏差较大时，chrony 默认会逐步调整，而不是直接跳变。如果需要尽快校正，可以通过 makestep 允许一次性跳变。但时间突然变化可能影响数据库事务、定时任务和依赖时间的缓存，这类操作最好安排在低峰期，并提前通知相关同事。