服务器时间不准的时候，通常不会马上出事。日志时间戳对不上，证书偶尔校验失败，分布式任务的先后顺序乱掉，等人去查，往往已经绕了好几圈。很多团队是出了故障才想起看一眼机器的时钟。在阿里云上跑业务，把阿里云时间同步服务器配好，工作量不大，之后基本不用再操心。这篇文章讲清楚它能做什么、怎么配，以及配完之后误差大概能控制在什么水平。
时钟为什么会偏
服务器的时钟靠晶振计时，晶振本身就会漂移。温度变化、虚拟化环境里的时钟抖动，都会让本地时间慢慢偏离标准时间。偏差只有几秒的时候，大多数业务还能正常运行。一旦到了几百毫秒，问题就会接连冒出来：
- 日志对不上：多台机器的日志时间不一致，排查跨服务调用时，很难还原真实的先后顺序。
- 认证失败：Kerberos、TOTP 动态口令、TLS 证书有效期校验都依赖时间。偏差太大，登录或握手会直接失败。
- 数据互相覆盖：如果系统用时间戳做版本控制或分布式锁，时钟错乱时，后写入的旧数据可能盖掉新数据。
- 定时任务错位：cron 在错误的时间点触发，报表、结算、备份可能重复执行，也可能漏掉。
阿里云有两类时间服务
阿里云给云上用户提供的时间服务分两类，选哪个取决于服务器在哪里。服务地址和可用性策略可能调整，具体以官方文档的最新说明为准。
- 内网时间服务：ECS 实例通过阿里云内网地址同步时间，流量不出 VPC，延迟低，也不依赖公网是否通畅。在云上运行的服务器，优先用这个。
- 公网 NTP 服务：ntp.aliyun.com 以及 ntp1 到 ntp7 等域名，适合不在阿里云 VPC 里的机器，比如本地机房或其他云厂商的主机。
大多数业务跑在 ECS 上，内网服务基本够用。它不占用公网带宽，也避开了公网抖动导致的同步失败。同步失败往往就发生在网络波动的时候，那时候你最不希望时间源本身也出问题。
配置分三步
第一步：先看当前状态
动手之前，先摸清机器现在的时间情况。主流 Linux 发行版普遍用 chrony 或 systemd-timesyncd 管理时间，用对应的状态命令就能看到同步源、偏移量和同步状态。如果偏移量已经超过一秒，建议挑业务低峰期修正。时间一下子跳变，正在运行的程序可能出现异常，比如超时判断出错，或者定时器提前触发。
第二步：把时间源指向阿里云
以 chrony 为例，编辑配置文件，把默认的时间源换成阿里云内网地址。内网地址请以官方文档为准。如果实例位于 VPC 中，就加上内网时间服务的地址，同时注释掉原来的公网源。修改完成后重启 chrony，让配置生效。
这里有一点要注意：同一台服务器不要同时挂太多时间源。源与源之间如果存在偏差，chrony 会反复判断该信哪一个，切来切去，稳定性反而变差。一到两个可靠源通常就够了，多了并不会更准。
第三步：验证同步效果
重启后用同步状态命令检查源是否可用。当前正在使用的源会带上标记，偏移量应该稳定在毫秒级。如果偏移量长时间收敛不下来，或者源显示不可达，先别急着改配置，优先检查安全组和路由，确认 UDP 123 端口的出入方向都已放行。NTP 走的就是这个端口，同步出问题时，它往往是第一个要查的地方。
案例：电商订单的支付时间早于下单时间
某电商团队在大促期间遇到过一个典型问题。订单服务部署在十几台 ECS 上，支付回调和库存扣减分别由不同的机器处理。大促结束后，财务对账时发现部分订单的支付时间早于下单时间。团队排查了好几天，始终没有头绪。
最后定位到的原因很朴素：部分历史实例的时钟偏差超过了三秒。这些实例创建时使用的镜像不同，默认时间源也不一致，运行久了偏差一点点累积起来。团队把所有实例统一指向阿里云内网时间服务，又在监控里加了时钟偏移告警，偏移超过一百毫秒就发出通知。之后同类对账问题再没有出现过。
这件事说明，时间同步属于不出问题就没人管的基础设施。配一次，再加上持续监控，比事后追查省事得多。
常见问题怎么查
- 同步源一直不可达：查安全组是否放行 UDP 123，也看本地防火墙会不会把响应报文拦下来。
- 偏移量反复跳动：多半是时间源配得太多，或者网络抖动较大。先精简源的数量，观察一段时间，通常会好转。
- 虚拟机重启后时间异常：检查宿主机和虚拟机的时钟同步设置，避免两层时钟互相干扰。
- 修改后没有生效：确认改的是系统实际读取的那个配置文件，并确认服务确实重启过。不同发行版的配置路径不一样，以系统文档为准。
小结
配阿里云时间同步服务器，关键是三件事：选对时间源，控制源的数量，持续盯住偏移量。ECS 上的实例优先用内网服务，跨环境的机器再考虑公网地址。把时间同步放进基础运维清单，能避开很多难以复现的隐蔽故障。
