微软云平台的一个故障引发的思考

三 18th, 2012
      闰年bug导致微软Azure故障,原因其实很简单,就是程序员在计算日期的时候偷懒了,本来需求是算出第二年的今日,但是程序员想当然的直接取了当前日期,然后把年份加一,结果导致出现了2013年2月29号这样的悲剧日期。

 

      微软Windows Azure也给出了相应的故障分析和总结的报告,如下链接:

http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx

这份报告相对于阿里目前的故障处理报告来说,更有价值一些,可以从这个报告中学习他们对故障的分析和处理改进思路。很有参考的价值。

 

      这个故障出来之后,有人翻出了Joel同学的软件随想录中关于微软和闰年的典故:详细的故事见下面的链接:http://turingbook.group.iteye.com/group/wiki/2022-BillG-Joel-Program-Manager

大致的故事简介就是:“1991年,Joel在微软还是vba的程序经理的时候,比尔盖茨会review所有的技术设计,joel在准备Excel的文档的时候,碰到的一个设计比较不清晰的地方,关于1990年2月29号的处理问题”

 

       到这里,这个故障相关的原委都已经清楚了,我也从这个故障中看到了一些问题,结合在阿里的这段时间的项目经验,我觉得有些东西还是相通的,可以借鉴和学习。

 1. 测试过程中,必须要全面考虑,把握细节:在我还未得知微软的这个故障之前,我其实已经碰到了一个类似的问题。我们的系统涉及到中美时间,当美国夏令时开始的时候,实际上与中国这边的时间已经有一个小时之差了,但是我们当时的程序用js简单的+8就完了,导致后来出现了时间上的误差。这个故障与微软的这个其实是很类似的问题。所以,测试人员在考虑这个问题的时候,是否有想到这个问题就非常关键了。

2. 问题无大小之分,也无轻重之分:看似这次的产生的原因非常微不足道,但是事实证明,一个小小闰年bug,就能让你标榜高可用的云计算平台,像多米诺骨牌一样迅速坍塌。

3. 自动化不是一切:从故障分析中看到微软提到,他们经过了完全的代码检查,自动化测试等等。缺少了必要的人工检查。

4. 故障不可怕,但需要从故障中吸取经验: 微软的这份报告,针对Prevention, Detection, Response, Recovery 四个方面做出了改进计划,这个值得借鉴。从问题中找到改进的方案和计划才是学习故障的重点。





除非注明,本站文章均为原创。本文基于 BY-NC-SA 协议进行授权,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 metaboy(包含链接).

本文链接地址: http://blog.wangyuxiong.com/archives/51600

订阅本站:http://www.wangyuxiong.com/feed

分类: 思考讨论         标签: , ,
  1. 哈哈,说得非常有道理

无觅相关文章插件,快速提升流量