时间偏差看着是小事，真出问题时最费时间。日志时间戳对不上，就很难还原事件的先后顺序。分布式系统更敏感，节点时间不一致可能导致证书校验失败、Kerberos 认证报错、分布式锁失效，数据库主从延迟的判断也会跟着出错。
如果服务器跑在阿里云 ECS 上，阿里云时间同步服务器地址基本直接用就行。官方同时提供公网 NTP 服务和云上内网地址，内网地址走 VPC，延迟更低，也不占公网带宽。
阿里云时间同步服务器地址怎么选
按实例所在的网络环境选，大致分三类：
- 公网地址：ntp1.aliyun.com 到 ntp7.aliyun.com。没有内网访问条件的机器用这组，比如本地机房，或者其他云厂商的主机。
- 通用域名：ntp.aliyun.com，由 DNS 解析到可用节点。不想手动挑编号时用它。
- 云内网地址：ntp.cloud.aliyuncs.com，只能在阿里云 VPC 内访问。ECS 实例优先用这个。
云厂商的服务地址可能随版本和地域调整。上线前以阿里云官方文档为准，并在测试机上先确认域名能正常解析。
一次日志错位排查的经过
某电商团队用十几台 ECS 部署订单服务，实例一直沿用系统默认的时间源。某次大促期间订单状态出现异常，网关日志和订单日志的时间戳相差约两秒，团队几次判断出了错误的先后顺序，排查花了半天多。
后来检查发现，部分实例的偏差已经到几百毫秒，原因是默认时间服务的上游同步链路不稳定。团队把所有实例改指阿里云内网 NTP 地址，并启用 chrony，之后一个月没再出现类似问题。
用 chrony 配置时间同步
主流 Linux 发行版大多默认带 chrony。下面是基本配置，修改前先备份原文件。
sudo cp /etc/chrony.conf /etc/chrony.conf.bak
# 编辑 /etc/chrony.conf，注释掉原有的 pool 或 server 行，添加如下内容
server ntp.cloud.aliyuncs.com iburst
server ntp1.aliyun.com iburst
# 保存后重启服务
sudo systemctl restart chronyd
sudo systemctl enable chronyd如果机器时间已经偏差较大，可以先执行 sudo chronyc makestep 做一次立即校正，再让 chrony 逐步收敛。
配置完成后，用下面的命令检查同步状态。
# 查看时间源列表，带 ^* 的是当前正在使用的源
chronyc sources -v
# 查看本机与时间源的偏差和同步状态
chronyc tracking输出里 System time 的偏差在毫秒级，且 Leap status 显示 Normal，就说明同步正常。
常见问题
- 内网地址连不上：先检查安全组和 VPC 路由是否放行了 NTP 使用的 UDP 123 端口，这是排查时最先该看的地方。
- 时间源数量：至少配两个以上，单个源故障时 chrony 可以切换到其他源。
- 不要混用守护进程：ntpd 和 chronyd 不能在同一台机器上同时运行，两者会相互干扰。装 chrony 前先停掉并禁用旧服务。
地址选对、守护进程配好、偏差定期看一眼，时间问题基本就能控制住。这件事投入不大，但出了问题很值得提前做。
