Linux 系统时间漂移导致服务异常？chrony 与硬件时钟排查

系统时间漂移是个慢刀子：证书突然失效、定时任务错峰、日志时间对不上、分布式锁莫名超时，最后查下来都是时间问题。分享一套排查流程。
第一步确认漂移方向和幅度。用 chronyc tracking 看系统时间与参考源的偏差，用 timedatectl 看 RTC 时间与系统时间是否一致。漂移是单向越走越快，还是来回跳变，指向的问题完全不同：单向漂移多是晶振或虚拟化时钟源问题，来回跳变多是多个时间源打架。
第二步检查时间源配置。chrony.conf 里 server 数量、iburst、makestep 的设置很关键。虚拟机上要确认时钟源：kvm-clock、tsc、hpet 选错，时间就会漂。云主机还要看宿主机时间同步是否正常，客户机再怎么调也追不上宿主机的漂移。
第三步检查 RTC。系统重启后时间跳回旧值，往往是 RTC 电池没电或硬件时钟没写入。hwclock -w 同步一次，再重启验证，别只在运行态修。
第四步看业务影响面。证书有效期、Token 过期、数据库主从复制延迟，都对时间敏感。修好时间后要复查这些服务，别以为时间对了就万事大吉。
你们有没有遇到过时间漂移导致的诡异故障？虚拟机上你们一般选哪种时钟源？

时间漂移排查把 chrony tracking 和 RTC 分开看很关键。虚拟机上再补一条：先确认宿主机同步正常，再动客户机；客户机追着一个本身在漂的 kvm-clock 只会反复 makestep。生产上建议对证书校验、分布式锁和定时批处理分别设「时间偏移」告警阈值，避免只在业务报错后才发现。RTC 电池与 UTC/local 解释混用时，重启后跳变方向能帮你快速判断是硬件时钟还是时区配置问题。

宿主机先行这条很关键，我再补几个落地判断。虚拟机上先看宿主机本身是否稳定：宿主机在漂，客户机无论怎么调 server 和 makestep 都只会反复跳变，等于在追一个不稳的源。确认宿主机正常后，再看客户机时钟源，kvm-clock 一般优先，tsc 在迁移或老内核上容易出问题，选错源的表现往往是单向漂移而不是随机跳变。
另外要区分系统时间与硬件时间：timedatectl 看 RTC 是 UTC 还是 localtime，混用时重启后时间会按时区差跳一次，很容易被误当成漂移。修完后不要只看一次 chronyc tracking，要连续看 offset 和频偏趋势，offset 收敛但频偏仍在增大，说明时钟源或晶振仍有问题。证书、令牌和主从复制这类时间敏感服务，修好后也要单独复查一次过期与延迟指标，避免时间对了、业务状态还没恢复。