故障刚开始时,Azure 状态页面甚至一度无法打开:

9 月 4
日,微软在美国中南部地区的圣安东尼奥数据中心由于雷电天气影响导致电压激增,数据中心的冷却系统发生故障。为保证数据和硬件完整性,数据中心的自动化措施强制关闭了系统电源以防止机器因过热造成损坏。这一事故引发了
Azure 中断,Office 365 以及 Azure Active Directory
服务都受到影响,并且恢复相关存储服务经历了很长时间。

微软已经对9月4日影响全球客户的故障发布了一份初步根本原因分析报告。Azure工程团队正在继续调查此事件,并表示他们将在”未来几周内”提供更详细的分析。

图片 1

故障从 9 月 4 日上午 9 点(北京时间 9 月 4 日
17:00)左右开始出现问题,到 9 月 5 日 13 点左右(北京时间 9 月 5 日
21:00
左右),微软大多数受影响服务的存储可用性已经恢复,整个故障中断时间超过
24 小时。

微软的官员们在这份分析报告中表示,受到影响的客户将在10月份的账单中,根据微软Azure服务水平协议(Microsoft
Azure Service Level Agreement)得到相应的补偿。

微软表示,位于得克萨斯州的美国中南部数据中心遭到了雷电风暴,结果散热系统出现了故障,迫使该公司关闭了许多服务器和系统,以防遭到更严重的损坏。

跟踪服务中断的 DownDetector.com 网站显示 Azure
服务中断主要位于德克萨斯州:

9月4日,正如之前在博客的文章中所述,微软在美国中南部的数据中心附近出现了一次雷击,很多Azure服务出现了故障,需要通过Azure
动态目录(Azure Active Directory)进行身份认证的Office
365也受到影响,此次事件的影响波及到了微软全球的很多客户。

散热系统是现代数据中心的一个重要组成部分,因为散热系统是消除在一个封闭的地方紧密堆叠在一起的成千上万台服务器产生的高温所必不可少的。简而言之,如果这个系统出了故障,所有系统都将随之停运。

Azure 官方推特 Azure Support 让用户查看 Azure 状态页面,但是 Azure
服务中断甚至影响到该页面也一度无法访问。Azure Support
将事故称为“网络问题”,并表示中断只会影响美国中南部的客户,但是很多用户表示中断已经影响了包括西欧、亚洲在内的其他地区。

微软的分析报告总结表示,风暴导致”电力系统供应的波动,导致电压骤升。”电压的骤升导致一个Azure数据中心切换至发电机供电,并关闭了该数据中心的制冷系统,但该中心配备有浪涌抑制器。该数据中心仍然通过冷却系统中与负载相关的热缓冲器维持所需的工作温度,但是等到缓冲器作用耗尽,温度就出现了升高,设备就出现了自动关闭。

因此,如果温度上升到超过安全水平,像微软这样的公司落实了自动关闭数据中心机器的程序。这是保护微软数据中心投资的重要措施,但是对云客户来说也带来了很大的不便。

Azure Support
在对用户的回复中澄清了为什么其他地区会受到影响:“在某种程度上,我们所有的数据中心都是相互联系的。因此,如果一个数据中心出现故障,它将转移到其他数据中心。此外,在欧洲的客户可能会在受影响的数据中心托管一些资源。“

一些硬件在关闭之前就已经被损坏,包括”大量存储服务器”以及其他网络设备和电源单元。现场团队开始尝试恢复基础架构,这意味着更换故障硬件,将服务器迁移到健康的服务器上并检查数据是否已经损坏。

微软提到的恶劣天气很可能与飓风戈登有关,这场1级风暴目前正在得克萨斯州海岸的附近兜转。

包括 Office 365 和 VSTS (Visual Studio Team Services)在内的近 40 个
Azure 服务受到影响。根据 Office 365 的公告,Office 365
用户遇到的问题类型如下:

对于那些想知道为什么微软的数据中心没有在故障中转移到备份站点的人:”当时做出的决定是为了恢复数据而不是转移到另一个数据中心,因为由于地理复制的异步特性,故障转移会导致部分数据丢失。”

微软表示,这起故障已影响了许多 Azure 云服务,包括 Visual Studio Team
服务。停运的其他服务包括 Azure Active Directory
身份管理服务和基于云的生产力套件 Office
365。所以,昨天国内很多开发者也表示 Visual Studio Code
的扩展中心无法搜索插件。

Exchange 某些用户可能无法访问网页上的 Outlook。
通过其他协议进行的电子邮件访问则有可能不受影响。Power BI
用户可能收到“服务器不可用”错误或可能无法登录。SharePoint
大多数影响已得到缓解,但一部分用户可能无法进行更改或更改无法保存。Microsoft
Teams 用户可能无法访问 Teams 的 Office 文档。Intune
受影响的用户可能无法访问 Intune 门户或其他功能。

关闭数据中心会影响许多依赖于该数据中心内存储服务器的Azure服务。受影响的服务包括:torage、虚拟机、Application
Insights、认知服务和自定义视觉API(Cognitive Services & Custom Vision
API)、备份、应用程序服务(以及用于Linux的应用程序服务和用于容器的Web应用程序)、用于MySQL的Azure数据库、SQL数据库、Azure自动化、站点恢复,Redis缓存、Cosmos数据库、流分析、媒体服务、Azure资源管理器(Azure
Resource Manager)、Azure VPN网关、PostgreSQL、Application Insights
、Azure机器学习工作室、Azure搜索、数据工厂、HDInsight、物联网中心、分析服务、密钥库、日志分析、Azure监视器、Azure计划程序、逻辑应用程序、Databricks、ExpressRoute、容器注册表、应用程序网关、服务总线、事件中心、Azure
Portal IaaS Experiences– Bot服务、Azure批处理、Service Fabric和Visual
Studio Team Services。

Visual Studio Team Services 小组补充道:“由于一些内部基础设施依赖 Azure
云服务,美国中南部地区以外的企业组织的客户所用的持续集成/持续交付(CI/CD)工作流程和仪表板也可能受到了影响。”

根据 VSTS 的公告,这次中断影响了使用微软 Visual Studio Team Services
的开发人员,导致他们无法访问帐户,报告仪表板也无法加载。

微软表示”这些服务中的绝大部分在协调世界时9月5日的11:00都已经恢复了”,但是也承认到了9月7日的8:40才完全解决这些问题。

专家们表示,这一事件向使用云服务的企业组织敲响了警钟:说到运行云端的关键工作负载,只有傻瓜才会依赖单单一家提供商。

根据 Microsoft Dynamics 公告,这次中断还影响了 Azure Active
Directory,Microsoft Dynamics Finance 以及 Operations 和 Lifecycle
Services 的用户。

为什么美国中南部地区以外的客户也会受到这一系列事件的影响?据该帖子称,”Azure
Service
Manager的弹性不足”,它采用的是”经典”资源类型的运营管理服务。微软的高管们表示,”虽然ASM是一项全球服务,但它不支持自动故障转移。”由于对ASM和其他相关服务的各种依赖性,美国中南部地区以外的Azure资源管理器服务也受到了影响。

Mimecast 有限公司的网络弹性专家彼得•班纳姆(Pete Banham)说:“今天 Azure
发生的事件再一次清楚地表明,企业组织需要做好自己的冗余机制,而不是依靠单单一家提供商。”

9 月 5 日,Azure
状态更新中表示,工程师正在优先恢复存储资源,以便恢复依赖于这些受影响资源的所有服务,但是恢复过程需要一段时间。到北京时间
9 月 5 日晚 9 点左右,大多数受影响的服务已经恢复。

Constellation 研究公司的首席分析师兼副总裁霍尔格•米勒(Holger
Mueller)表示,不过,该事件也给了希望避免将来发生此类事件的微软一个深刻的教训。

到底应该怎么上云?

米勒说:“这次事件深刻地提醒人们,即使对于像微软这等规模的 IaaS
提供商来说,要保持数据中心正常运行有多难。闪电、洪水、飓风、大雪和暴雨都会影响数据中心的可用性。所以一个关键的问题是,微软从中汲取了什么教训?它如何在将来能避免类似的故障?这给了希望加强云基础设施的公司一个深刻的教训。”

此次 Azure 服务中断时间长,影响较大,又引发了大家对上云风险的讨论。

在发布的最新消息中,微软表示它在努力使所有受影响的服务重新上线,不过截止本文发稿时,这项工作仍在进行之中。而
Azure
状态页面也尚未更新相关动态消息。微软的恢复计划如下:

VSTS 一整天都用不了,这是个很严重的问题。有用户说:

  1. 恢复美国中南部数据中心的电源(已完成)

  2. 恢复美国中南部 Azure 存储规模单元的软件负载均衡器(已完成)

  3. 恢复美国中南部受影响的 Azure 存储规模单元(进行中)

  4. 恢复美国中南部剩余的依赖于存储的服务(进行中)

我无法相信 Azure
仍在瘫痪。昨天整天我都无法访问美国中南部地区的资源。整个区域的服务中断可能会持续
24 小时的事实将使我的团队认真考虑转向 AWS。如果我们的服务中断 5
分钟,我们的客户会很生气。我甚至不想去想如果因为一些完全不受我们控制的事情而宕机一整天会发生什么。

微软表示:“工程师已成功地恢复了数据中心的电源。此外,工程师已恢复了大部分受影响的网络设备。虽然一些服务开始出现了恢复如初的迹象,但抢救工作仍在进行之中。”

讨论中也有这样的疑惑:

不过我们也发现 Azure
服务支持在推特发布的公告,评论中依然有不少用户反映很多服务存在问题。

区域性中断应该不会拖垮那么多服务,地理冗余在哪里?

参考:云头条

虽然很多细节都围绕在具体是哪里的冷却系统发生了故障,Azure
这次的服务中断可以让大家认识到可用区(AZ,availability zones)
的重要性。AZ
能让使用云服务的用户在给定云计算区域内的几个独立建筑周围分散工作量,以期避免单个数据中心会带来的问题。

AZ 的设置直到去年才成为微软基础设施战略的一部分,并且目前微软只向全球 54
个区域中的三个地区推出了 AZ(美国东部 2 区和东南亚地区可作为预览)。

上云本来是要防止这些基础设施问题的,但是不要忘了,即使 99%的 SLA
也意味着一年 365 天大约可以有 4 天不在线。所以很多公司会提到 99.9% 和
99.99%,当以年为单位来看,小数点后面的位数也不可小觑。公有云提供的高度冗余意味着公司需要在全国各地拥有为站点提供服务并充当备份的私有数据中心。很多公司连建立这么多数据中心的预算足都不足,更不用说额外的维护成本了。

Mimecast 的网络弹性专家 Pete Banham 说:“今天在 Azure
发生的事件再次提醒企业需要建立自己的冗余,而不是依靠单一的供应商。所有公司(包括
Microsoft)都需要考虑由于技术故障或人为错误而导致关键服务故障可能产生的下游影响。服务总是会有失败的时候,IT
领导者们需要确保自己没有将责任外包给单一的云服务。”