案例分析：闰秒带来的BUG是否影响了你？

闰秒如何影响了IT世界？在2016年底我们写下的文章里曾经提到2017开年多出这一秒，大家是否平稳度过？欢迎大家留言讲诉你遇到的真实故事。

毫无疑问，根据墨菲定律，可能出现问题的地方就必定会出现问题，只不过何时、何地、何人，就不得而知。根据网上的消息，硅谷的Cloudflare公司的服务确实因为闰秒遭遇到BUG，进而影响了部分用户的域名解析。Cloudflare以向客户提供网站安全管理、性能优化及相关的技术支持为主要业务。

问题的原因出在 Cloudflare 的RRDNS软件内部，一个Number的最小输出结果应该为零，结果在闰秒时变成了负数。

A little later this negative value caused RRDNS to panic. This panic was caught using the recover feature of the Go language.

最终影响就是，Cloudflare 为托管网站提供的一些DNS解析以失败告终。

看看这段程序代码，如何因为一秒而产生了错误。在这段代码中，当 time.Now() 早于早前同样获得的 start 值，则可能返回负数。

这段代码在时间一直向前时工作正常，然而当时间回调时，就出现了问题。1秒虽然很短，但是在Cloudflare的服务请求中，请求的响应是毫秒级别的。

// Update upstream sRTT on UDP queries, penalize it if it fails if !start.IsZero() { rtt := time.Now().Sub(start) if success && rcode != dns.RcodeServerFailure { s.updateRTT(rtt) } else { // The penalty should be a multiple of actual timeout // as we don't know when the good message was supposed to arrive, // but it should not put server to backoff instantly s.updateRTT(TimeoutPenalty * s.timeout) } }

解决的代码只修改了一行，判断了小于0的情况。

当然 Cloudflare 的响应是非常迅速的：

2017-01-01 00:00 UTC Impact starts 2017-01-01 00:10 UTC Escalated to engineers 2017-01-01 00:34 UTC Issue confirmed 2017-01-01 00:55 UTC Mitigation deployed to one canary node and confirmed 2017-01-01 01:03 UTC Mitigation deployed to canary PoP and confirmed 2017-01-01 01:23 UTC Fix deployed in most impacted PoP 2017-01-01 01:45 UTC Fix being deployed to major PoPs 2017-01-01 01:48 UTC Fix being deployed everywhere 2017-01-01 02:50 UTC Fix rolled out to most of the affected PoPs 2017-01-01 06:45 UTC Impact ends

下图显示了Cloudflare 监控的接入解析错误率，修复程序部署后，错误率迅速下降。