Summary of Windows Azure Service Disruption on Feb 29th, 2012 (leap year bug)
1. 4:00PM PST, February 28：leap year问题导致认证失败（直接year + 1得到下一年的日期是错的）
2. 5:15PM PST：经过每次25分钟的三次尝试失败之后，报警通知人工处理
3. 6:38PM PST：工程师定位问题所在
4. 6:55PM PST：停止用户控制台，防止用户错误操作后台集群导致更严重问题
5. 10:00PM PST：制定操作计划
6. 11:20PM PST：fix代码开发完毕
7. 1:50AM PST, February 29：fix代码测试完毕（同时在某个生产集群上测试）
8. 2:11AM PST：完成了一个生产集群的升级
9. 5:23AM PST：持续fix各个集群，此时，大部分集群的用户控制台恢复服务
10. 2:47 AM PST on the 29：最后剩下7个集群还有问题，这些集群升级的时候的碰到兼容问题，导致网络无法连通
11. 3:40 AM PST：重新测试方案
12. 5:40 AM PST：开始fix 剩余的7个集群
13. 8:00 AM PST：集群状态正常，但是很多机器仍然处于未连通状态
14. 2:15 AM PST, March 1：所有服务恢复
可以看到：
1. 最初是leap year问题导致bug，这个真的是比较低级的，而且微软这么多年了，应该有很多date的lib，为什么还会需要自己写代码处理日期？日期本来就不好处理。
2. 出了问题之后也只影响了一台机器，但是为了防止更多的机器发生问题，停止了用户控制台，然后逐个集群慢慢升级
3. 估计全球集群过程比较慢，高层不满意了，于是开始大规模升级，这下出了兼容性问题，恢复时间成倍延长，这说明碰到越严重的问题越要冷静，否则问题很可能升级为不可控制
4. 出兼容性问题也是因为其测试未在集群进行，而是在单机进行的，这让我非常惊讶，作为对流程推崇备至的微软，应该知道生产集群的升级要做回归，而且作为分布式系统的开发同学，对单机和集群的理解应该也很深，所以这里只在单机测试应该是轻敌了
5. 整个过程持续了30几个小时，其中大部分时间都是因为中间不兼容错误操作导致的，工程师身心疲惫，后续出问题的可能性更大。
