“闰年虫”引发Windows Azure中断

     作者    <a href="/misc/goto?guid=4958331671407783771">Abel Abel</a> 译者    <a href="/misc/goto?guid=4958331654885407681">曹如进</a>    <p> 微软 Windows Azure 云平台若干子区域受“闰年虫”影响致许多客户 12 至 24 个小时无法使用服务。</p>    <p> 根据 <a href="/misc/goto?guid=4958331672940734439">Windows Azure 服务仪表板</a>显示，从 UTC 时间 2 月 29 日凌晨到 3 月 1 日早上，大量的子区域服务和全球性服务发生了超过 24 小时的中断。以下是受影响的服务：</p>    <ul>     <li>Windows Azure 计算服务（Compute Service）部分出现故障，6个子区域中有 4 个出错，共影响了美国中北部区域6.7%、美国中南部 28% 以及北欧区域 37% 的托管服务。另外，Azure 的一些其他服务也受到了波及，包括：访问控制2.0（Access Control 2.0）、市场（Marketplace）、服务总线（Service Bus）以及访问控制&缓存入口（Access Control & Caching Portal）；</li>     <li>美国中南部区域的服务总线中断超过 24 小时；</li>     <li>位于美国中南部的市场也部分受到了超过 12 小时的影响，特别是那些需要 OAuth 访问的服务。</li>     <li>2012年 2 月 29 日触发的某个证书问题导致服务管理（Service Management）服务在全球性范围内受到影响。一些区域约 12 小时无法正常访问，其他区域超过 24 小时无法正常访问。</li>    </ul>    <p> 存储、CDN 和其他服务似乎并未受到影响。  而平台管理入口（Platform Management Portal）由于另外一个不同的问题，导致 3 月 1 号全球范围内受到大约 3 小时的影响，其原因是因为“后台某个设置被配置错误”。</p>    <p> 微软负责服务器和云服务的副总裁 Bill Laing 简要通报了 Azure 客户此次<a href="/misc/goto?guid=4958331673747137859">中断及其原因</a>。据 Laing 描述，Azure 团队在太平洋标准时间 2 月 28 日下午5:45，即 UTC 时间 2 月 29 日上午1:45意识到该问题。而问题的罪魁祸首是由 2 月 29 日这个特殊日子触发的一个软件 bug。</p>    <blockquote>     <p>这个问题迅速被触发并确定起因是一个软件 bug。虽然根本原因分析还在进行当中，但是问题看起来似乎是对闰年的时间计算不正确所致。</p>    </blockquote>    <p> 赛门铁克报告说，<a href="/misc/goto?guid=4958331674544918673">闰年虫影响了他们6.1版本的软件交付</a>。Inedo 合作伙伴 Alex Papadimoulis 报告说，<a href="/misc/goto?guid=4958331675338526719">他们的一些客户受到了影响</a>。此外，<a href="/misc/goto?guid=4958331676138460473">新西兰一些销售设备也发生了故障</a>。</p>    <p> 虽然这个 bug 对小公司多少可以接受，但是对于微软着实有些尴尬，特别是因为它影响了客户托管在微软云平台上的服务。有意思的是，如此之小的事情竟然够弄垮这么大的计算平台，同样<a href="/misc/goto?guid=4958331676936869937">一年前亚马逊也发生过这样的事情</a>：在美国东部区域的一块可用区流量被错误地转到一个无法处理这些流量的低级别的路由中，影响了几个 EBS（弹性块存储，Elastic Block Storage）结点，并最终导致了整个区域的垮掉。我们可能还会看到此类中断事件，毕竟“人非圣贤，孰能无过”。</p>    <p> <strong>查看英文原文：</strong><a href="/misc/goto?guid=4958331677730394164">http://www.infoq.com/news/2012/03/Azure-Blackout-Leap-Year-Bug</a></p>