服务器时间差几秒，很多人觉得无所谓。真正出问题时才会发现，很多系统默认时间是准的。日志时间戳对不上，故障复盘时就很难还原事件顺序。分布式数据库靠时间戳判断事务先后，偏差太大会出现数据冲突。Kerberos、TLS 证书校验和 API 签名也对时间敏感，偏差超出容忍范围，请求会直接报错。
NTP（Network Time Protocol）是解决这个问题的标准协议。服务器定期和上游时间源对时，通常能把误差控制在毫秒级。在阿里云上，第一步通常就是选对阿里云ntp服务器地址。
阿里云 NTP 服务器地址有哪些
阿里云的时间服务地址分两类，对应的网络环境不同，别混用。
ECS 内网地址
如果服务器是阿里云 ECS，并且和时间服务在同一地域的 VPC 里，优先走内网。常用的有：
- ntp.cloud.aliyuncs.com：通用入口，不用关心背后是哪个节点，配一个就能用。
- ntp1.cloud.aliyuncs.com 到 ntp7.cloud.aliyuncs.com：多个内网节点，适合做冗余，多配几个让客户端自己交叉比对。
内网走阿里云内部链路，延迟低，也不占公网带宽。ECS 之间对时，这是最省心的选择。
公网地址
服务器在本地机房、其他云厂商，或者访问不到阿里云内网时，只能用公网地址：ntp1.aliyun.com 到 ntp7.aliyun.com。
公网链路长，延迟和抖动都比内网明显。至少配两到三个节点，让 chrony 有多个样本可以比对，单个节点抖一下，整体不至于跟着跑偏。
另外，云厂商的时间服务地址可能随基础设施调整。正式上线前，最好再核对一下阿里云官方文档的最新说明。
chrony 配置示例
ECS 上使用内网地址
假设一组订单服务部署在 ECS 上，日志里偶尔出现同一笔订单的时间顺序错乱。这类问题往往先查时钟，再查业务代码。把时间源统一到内网地址，chrony 配置可以这样写：
# /etc/chrony.conf
server ntp.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
makestep 1.0 3
rtcsync改完后用 chronyc sources -v 看上游源是否可达、是否被选中，再用 chronyc tracking 看当前偏差。偏差稳定在毫秒以内，跨机日志才好对齐。
本地机房访问公网地址
假设一套数据采集服务同时跑在阿里云和本地机房。本地机器够不到内网地址，就改用公网源，并多配几个节点：
# /etc/chrony.conf
server ntp1.aliyun.com iburst
server ntp2.aliyun.com iburst
server ntp3.aliyun.com iburst节点多，chrony 才能依据多数源的结果做判断。某个节点短时抖动时，影响会小很多。
配置时容易漏掉的几点
同一 VPC 里的 ECS 优先用内网地址，别为了省事绕去公网。只配一个时间源的话，出问题时没有参照，至少保留两到三个。
如果机器用的是 ntpd 而不是 chrony，配置语法不一样，但选地址的原则相同。
安全组和网络 ACL 要放行 UDP 123 端口的进出流量，否则同步会一直失败，而且报错不一定直观。迁移主机或修改网络配置之后，记得重新检查一次同步状态。
小结
阿里云 NTP 的门槛不高，难点通常在于选对地址、留够冗余。ECS 用 ntp.cloud.aliyuncs.com 或内网节点；外部环境用 ntp1.aliyun.com 到 ntp7.aliyun.com，并保留多个源。时间同步稳定了，日志、监控和分布式系统的很多排查都会轻松不少。
