公有云早已飞入寻常百姓家，除了初创的企业，很多大公司也将自己的服务部署在共有云平台上，因此公有云的稳定性和可靠性是十分重要的。平日里谈起公有云，大家总把注意力放在行业老大 Amazon Web Services 上，不太提及 Microsoft Azure，今天就让我们来看一下去年 11 月 Azure 发生的将近 11 个小时的故障。
首先，来回顾一下故障的经过，根据《Update on Azure Storage Service Interruption》这篇官方博客的介绍，这起编号为 3071402 的故障名为“Microsoft Azure Service Incident : Connectivity to multiple Azure Services – Partial Service Interruption”，影响了 19 种 Azure 服务，涉及 12 个 Region，当时似乎只有澳大利亚数据中心幸免于难。
讽刺的是多个微软自己的服务也受到了牵连，Windows Store 和 Xbox Live 都受到不同程度的影响。而 Azure 的 Service Health Dashboard 也受故障影响，在故障发生之初尽然显示一切正常，Azure 也真是“醉”了。
一个月后，Azure 团队在其官方博客上就此次故障发表了详细的说明——《Final Root Cause Analysis and Improvement Areas: Nov 18 Azure Storage Service Interruption》，文中剖析了造成故障的原因。本次变更主要是针对 Azure Storage Table Front-Ends 的，目的是减少 CPU 开销，提升存储服务的性能。在测试和预生产环境中，本次变更顺利地通过了健康检查，同时显著提升了系统性能，还解决了几个已知的问题。但是在后续的增量部署中，不幸发生了，Azure Blob Storage Front-Ends 错误地开启了该功能，触发了一个 Bug，导致系统进入死循环无法再提供服务了。几分钟后，监控发现问题，工程师团队在 30 分钟内回滚了 Azure Blob Storage Front-Ends 的变更，对于已经进入死循环的系统进行了重启。
存储系统的故障还影响了虚拟机服务，主要可以将问题归纳为三类，都发生在存储故障和故障恢复阶段：
如果说代码的 Bug 未在测试中被发现尚情有可原，那么在换一个灯泡都需要将近50 个工程师参与，流程极为繁琐苛刻的微软，不遵守流程就是不可原谅的了，《Microsoft confirms Azure outage was human error》一文直接就在标题上将其称为“人祸”。
Azure 的部署遵循名为“flighting”的流程，这个流程大致如下：
负责本次性能优化的工程师认为该变更已经在生产环境的小集群上正常运行几个星期了，应该没有问题，在整个 Azure 上开启该功能没有太大风险。而配置工具也没有强制遵循增量部署变更的策略，导致该变更被部署到了整个系统上。
所谓没有规矩不成方圆，有了规矩不能贯彻执行也没用，在小公司或者初创团队，避免繁琐的流程的确能够带来很多便捷，但是在大型团队或者一些核心系统中，流程还是必须的。同时， 必须还要有系统能够保证流程得以正确执行 ，人是会犯错的，人是会走捷径的，就像造成本次故障的那位同学，所以才要系统来进行约束。
Hacker News 上围绕 Azure 团队的故障分析展开了讨论，大家都对 Azure 团队的公开透明表示赞赏（其实在 Azure 的官网有个页面专门记录故障，相比某些公司出了问题遮遮掩掩，这种做法显然更受欢迎），同时不少人也在关心造成这次故障的那位同学的命运，一位读者引用了 IBM 的 Thomas Watson 的话：
曾经在支付宝的运维团队也有位朋友这么告诉我——“对运维操作要有敬畏之心”，这句话一直被我记在心中，相信他一定是在背了重大故障之后才会有此感悟。估计 Azure 的那位同学后续一定在操作时会更加仔细，遵循规范。
不知各位读者在了解了 Azure 的这次故障后，是否也能有所收获，当然，如果您在工作中也有过类似的经验教训，不妨也和大家分享一下吧。
