Windows Azure 中断调查

近日，微软 Azure 云计算平台部分服务发生中断，起因是一个闰年 bug。Azure 服务器和软件时间刚过 2 月 29 日 UST 时间 00:00，服务故障便拉开了序幕。日期变化暴露代码中存在缺陷——闰年没有被正确处理好。随后附加服务器的部署，让整个 Windows Azure 云平台陷入了级联错误。

那么什么是导致失败的根本原因呢？Laing解释说，应用程序虚拟机使用传输证书与托管操作系统之间进行安全通信。传输证书创建后的持续时间仅被设计成一年。原有的缺陷代码在创建失效日期时，采用的方法是将当前日期的年份字段加1，结果2012 年2 月29 日创建的传输证书失效期被定为一个不存在的日期——2013 年2 月29 日。该错误阻止了新的传输证书的创建，并成为了此次事件的导火索。

Laing 总结了微软采取的针对预防、检测、响应及恢复方面的几个步骤。此外，微软对于“所有使用 Windows Azure 计算、访问控制、服务总线与缓存”的用户，不管是否受到此次事件影响，都将提供 33% 的费用返还。

Windows Azure 服务仪表板

Windows Azure 中断时间线（以下所有时间均为美国太平洋时间）

2012-02-28 16:00 错误最开始发生在 2012 年 2 月 29 日 00:00。新的虚拟机无法生成正确证书，结果自行终止。25 分钟过后，托管操作系统重新启动虚拟机创建过程，但结果仍然失败。整个过程需要 3 次重启尝试，每次相距 25 分钟。

2012-02-28 17:15 在错误发生整整 75 分钟之后，误差阈值达至上限，失效集群通知首要响应人员“受影响的系统无法恢复”。

2012-02-28 18:38 响应团队初步确定问题出在日期 / 事件 bug 上。

2012-02-28 18:55 基于团队对问题的评估，也为了防止用户造成额外的损害，微软禁用了全球范围内所有集群的服务管理功能。

2012-02-28 22:00 响应团队为更新代码创建测试及上线计划。

2012-02-28 23:20 代码更新完毕。

2012-02-29 01:50 响应团队完成上线测试，将更新代码后的应用程序部署到测试集群中。

2012-02-29 02:11 团队完成对生产集群的补丁部署，同时开始向所有集群部署补丁。

2012-02-29 02:47 原有 bug 发生时，有 7 个集群在刚好处于部分更新状态。这 7 个集群收到的单独更新在部署之前并没有测试，结果又引入了另外一个 bug，继而导致网络连接失效。

2012-02-29 03:30 为这 7 个单独的集群创建修订后的补丁，并在部署前进行了测试。修订版本计划在 05:40 安装。

2012-02-29 05:23 微软宣布大部分客户的服务管理功能已经恢复（除了那单独的 7 个集群以外）。

2012-02-29 05:40 7 个单独的集群接受更新以恢复网络功能。

2012-02-29 08:00 7 个单独集群大部分可以运作。少数个别服务器由于各种不同的中断问题还存在错误，微软员工当天继续工作以进行修补。

2012-03-01 02:15 所有集群服务全部功恢复正常。

查看英文原文： http://www.infoq.com/news/2012/03/azure_outage