案例分析：闰秒带来的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 监控的接入解析错误率，修复程序部署后，错误率迅速下降。

原文链接指向Cloudflare的官方发布源。

---

如何加入"云和恩墨大讲堂"微信群

搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。

近期文章