AWS 因为闰秒大面积宕机

[ykswang]

Twitter上已经各种酸爽了

[zhengkai]

昨天刚看到同事发了个 http://toutiao.com/a4600340448/ ，今天就……

[lilydjwg]

可报道说是因为路由泄漏啊： http://mashable.com/2015/06/30/aws-disruption/?utm_cid=mash-com-Tw-tech-link

[tt88050643]

我们公司（一交易所）采取的方法是在6月30号晚停止ntp服务，7月1号8点以后，手动ntpdate立即校时，保证开盘前完成闰秒调整，而从今天的记录来看，ntp服务器不会出现07:59:60而是在08:00:00时间点停留两秒。在之前的模拟闰秒的测试中看，主机在接收到闰秒通知后是会重复跑两遍07:59:59。

[em70]

@learnshare 千年虫是当时业界集体忽悠外行的，没那么严重，但搞得全世界都如临大敌，很多软件公司都大大的赚了一笔

[ykswang]

@lilydjwg 我们在AWS的集群网络不通，CPU100%，都是从7:59:59后开始的

[duangaduang]

我们自己的服务器N多负载飙高，影响不小，主要还是我们用的内核版本比较低，哎！

[duangaduang]

@tt88050643 你们很专业啊！

[lilydjwg]

@ykswang 那给点链接去围观嘛。截图又不能点又不能复制文本。

[tt88050643]

@duangaduang 交易系统对时间进行切片打上时间戳，对时间还是挺敏感的。

[kamushin]

@wdlth 8点-9点，怎么可能还没同步好:(

[easehu]

我们公司从今年1月份就开始出通告了，我们在3月份完成所有设备的调查，最后找供应商确认这些设备是否会因为闰秒问题出现问题，最后到4月中旬得到结果，只有两台过保的光纤交换机可能会有问题，其他的机器系统内核都升级到了新版本，网络设备和存储设备都询问过供应商，确定到时没有这个问题。最终给两台光纤交换机搞了个私有的ntp服务器（ntp配置无法去掉，过保没技术支持），在私有ntp上用perl 模拟ntp服务器。早上平稳过度没出现设备宕机和网络中断的情况。

[micyng]

@est 不会出现60，而只是59重复一次

[princeofwales]

半个月前就做好了预案，今早提前到了公司，临时停止了几台数据库服务器的ntp，8点过后再打开，没有发现异常
我看了一些资料，是说会出现07:59:60，一般的应用当然没问题，timestamp类型的字段就可能有问题了，数据库不认第60秒

[rrfeng]

不是闰过好几回了吗……第一次就是停了 NTP 然后第二天起
反正我们的业务时间相关性不是很大。

[alen]

AWS机器没啥特殊变化，就和平时一样没啥事发生。

[julyclyde]

@easehu 如果交换机连不上ntp会如何？直接让它访问不了不就得了，为什么还做个假的？

[julyclyde]

@princeofwales 数据库字段应该可以吧？就怕事务处理受逆转时刻影响

[wy315700]

@julyclyde 那样 交换机时间会永远比其他设备快一秒。。。

[julyclyde]

@wy315700 闰秒之后再让它能连上就可以慢慢调过来吧。你的假ntpd提供啥数据给它？

[wy315700]

@julyclyde
估计是内核原因，不支持平滑过度1s这么大的差距，也许可以过度10ms这样的，所以要弄一系列假的NTP数据，诱导他慢慢的过度过来。

仅个人猜测