服务器时间出错时，通常不会立刻报错。日志对不上、证书突然校验失败、定时任务跑了两次或者一次没跑，等有人注意到，往往已经过去一段时间。不少团队是吃过一次难查的故障，才回头检查时间同步。这篇文章讲阿里云时间服务器怎么用、内网和公网怎么选、chrony 怎么配，最后用一个订单对账的案例说明排查思路。
时间偏差会在哪些地方出问题
服务器的时钟靠主板上的晶振计时，晶振会随温度和老化慢慢偏移。单台机器每天的走时偏差可能有几百毫秒，甚至更多。只有一台机器时，这点偏差基本没人察觉；服务拆到多台机器之后，同一件事在不同机器上记下的时间就可能对不上。常见的影响有几类：
- 日志错位：跨机器排查时，时间戳对不齐，很难还原请求的先后顺序。
- 证书校验失败：HTTPS 证书有生效和过期时间，服务器时间偏差过大，客户端可能判定证书无效。
- 分布式协议异常：依赖时钟的锁、租约和事务超时，遇到时间跳变可能误判。
- 定时任务重复或遗漏：对账、结算这类任务如果触发时间不准，容易重跑或漏跑。
阿里云时间服务器是什么
阿里云时间服务器基于 NTP（Network Time Protocol，网络时间协议）提供时钟同步。云服务器定期和它对齐，多台 ECS 实例的时钟就能保持一致。使用阿里云 ECS 的话，不需要自己搭建时间源，直接用官方提供的地址即可。
访问方式主要有两种。内网地址适用于同一地域内的 ECS，延迟低，也不占用公网带宽。公网域名适合不在阿里云内网的服务器，或者需要跨地域同步的场景。不同地域和镜像版本的推荐写法可能有差异，具体以阿里云官方文档为准。
内网还是公网地址怎么选
- 同一地域的 ECS 优先用内网地址，抖动更少，同步更稳定。
- 跨地域、跨云或本地 IDC 的服务器用公网域名，同时确认安全组放行 UDP 123 出方向访问。
- 对时序要求很高的业务，可以在地域内部署一台本地时间源，由它向其他机器分发时间，减少单点波动带来的影响。
chrony 配置示例
目前主流 Linux 发行版大多使用 chrony 做时间同步，配置简单，收敛也快。以下步骤适用于常见的 CentOS、Alibaba Cloud Linux 和 Ubuntu 环境：
- 检查服务状态：执行 systemctl status chronyd，确认 chrony 已安装并在运行。没装的话，用包管理器安装即可。
- 编辑 /etc/chrony.conf，把默认上游源换成阿里云内网时间服务器，例如 server ntp.cloud.aliyuncs.com iburst。iburst 参数能让启动时的首次同步更快。
- 执行 systemctl restart chronyd 重启服务，再用 chronyc sources -v 看上游源的状态。最后用 chronyc tracking 检查 System time 和 Last offset 两项，确认偏移量稳定在毫秒级。
部分阿里云官方镜像已经预置了内网时间源。修改前先查看现有配置，避免重复添加或覆盖原有设置。
误差多少毫秒算正常
没有一个放之四海而皆准的数字。日志排查和一般对账，对毫秒级的偏差通常不敏感。锁、租约、事务超时这类机制对偏差更敏感，阈值要结合业务的容忍度来定。实际运维中，可以先观察 chronyc tracking 的偏移量是否长期稳定在毫秒级，再根据业务设定告警线。偏移量忽大忽小、或者持续单向增长，才是更值得查的信号。
案例：某电商订单对账异常的排查过程
某中型电商团队在大促后发现，部分订单的支付时间和支付回调时间顺序颠倒，对账系统把它们判成异常订单，人工核对花了两天。团队最初怀疑是消息队列重复投递，但排查后没有找到相关问题。
接着，团队对比了几台应用服务器的时间，发现其中两台 ECS 的时钟偏差超过 800 毫秒。这两台机器恰好部署了支付回调服务。原因是它们早期用自定义镜像创建，镜像里的时间源指向一个已停止维护的外部地址，时钟长期没有校准。
处理方式很直接：所有 ECS 统一切换到阿里云内网时间服务器，重启 chrony 后，偏差收敛到几毫秒以内。团队随后把 chronyc tracking 的偏移量纳入监控，超过阈值就告警。此后，对账系统没有再因为时序错乱而误判。
常见问题与注意事项
- 安全组未放行：同步失败时，先检查安全组和本机防火墙是否放行 UDP 123 端口。
- 虚拟机快照恢复：从快照还原后，时间可能短时间内跳变，恢复后主动执行一次同步检查。
- 容器环境：容器通常共享宿主机时钟，时间同步应在宿主机上统一管理，不必在每个容器里单独配置。
- 避免手动修改系统时间：大幅跳变会影响依赖单调时钟的程序。让 chrony 平滑调整，更稳妥。
阿里云时间服务器的配置门槛不高，难点在于统一管理和持续监控。把时间同步纳入基础设施的日常维护，才能避免这类问题在关键时刻冒出来。
