p0级故障-nptd和ntpdate用法

一、背景

绝对真实的大厂线上P0级故障经历分享。某日凌晨3点，企业微信群变得热闹起来，想都不用想，作为互联网人，特别是运维相关的同学知道，肯定又是出故障了，并且这个故障还很大。

当前晚上我睡着了，电话没接到，事后同事跟我讲了他们凌晨都在怎么排查问题。

当晚凌晨80%的事业群业务故障，导致充值、访问、各种系统出现各种告警。凌晨收到告警大家一致在排查到底是什么问题导致的，排查了近2个小时，后来才发现批量的Linux主机时间都跑到2000年。。这确认没人能想到是这个原因，大家都去查数据库集群、es、redis等等，所以浪费了很多时间最后才定位到。

这尼玛绝对是大坑啊，这次损失了将近30w-50w左右的人民币。。。。, 幸好不是创业公司，要不然直接宣布倒闭，幸好是凌晨，流量没那么大，如果在白天，这个损失估计扩大10倍。

下文讲述下发生本次p0故障的根本原因，吃瓜群众，听我娓娓道来~

二、原因分析

1、现状操作

故障修复之前，SRE之前采用的时间服务器同步方式是，Crontab定时同步npt服务器。我看好多人也是用这样的操作。但是，这里有两个关键点:

1、使用定时任务的方式，定期执行ntpdate命令，同步NTP服务器的时间

2、NTP源服务器，SRE使用了开源的NTP时间服务器站点

2、墨菲定律-NTP服务器自己时间都发生了错误

开源的NTP时间服务器，竟然在那天出异常了。。NTP服务器时间都自己变得不准了，那么跟随这个NTP的这些服务器使用ntpdate，直接修改自己服务器的时间跟随NTP服务器。。大家都跳到2000年的时间，GG, Game Over

3、nptdate和ntpd两个命令的区别

参考一篇博客: https://www.cnblogs.com/liuyou/archive/2012/07/29/2614330.html

简而言之:

1、ntpdate很无脑，就是一个一次性命令，你让他改操作系统的时间改成啥样，它就改成啥样。非常依赖于NTP时间服务器的正确性。 NTP服务器时间是怎样，到Crontab定时就更新为和NTP源时间服务器一样的时间。

2、nptd的方式是一个后台进程的形式，它稍微会智能一点，一旦发现自己操作系统时间和NTP服务器时间差距较大，可以自己设置，例如超过几分钟或者十几分钟之类的，那么nptd守护进程就不会同步NTP服务器的时间，而是使用自己的本地时间继续往下走。由此，ntpdate会慢慢地检查与NTP时间服务器的差距，进行校正，而不是像nptdate立马跳跃更改服务器的时间。像这个故障，如果使用了nptd，就不会造成巨大损失，因为当前时间和2000年差距太大， ntpd根本就不会改变自己服务器的时间为NTP服务器时间,而是依然使用自己本地时间。等NTP源服务器恢复后，再逐步校正同步NTP源服务器时间.