Azure 9.4“尸检报告”：雷击后又遭遇连环杀

上周 Azure 被雷击垮了，近日在其官网发布了详细的事后分析报告，作者是 Azure DevOps 工程技术主管 Buck Hodges (@tfsbuck)，云头条经翻译，发表如下，供各位参考：

始于2018年9月4日的VSTS故障

2018年9月4日星期二，VSTS（现名为Azure DevOps）遭遇长时间的故障，影响了在美国中南部地区（全球托管VSTS客户的10个地区之一）设有组织的客户。 由于服务之间相互依赖，这次故障还影响了全球各地的客户。 由于恢复VSTS服务有赖于恢复数据中心的Azure，因此花了逾21个小时才恢复了美国中南部的所有VSTS服务。在VSTS服务恢复后，由于数据库宕机，我们另外遇到了一起持续2个小时的事件，影响了美国中南部的发布管理服务。恢复Azure存储帐户的过程中，我们的一些Git和软件包管理客户还遇到了间歇性故障。

首先，我想对受影响地区的托管客户为长时间的VSTS故障及其对全球客户带来的影响深表歉意。这起事件对我们来说前所未有。在我们七年的历史中，这次故障是VSTS客户遇到持续时间最长的。我通过Twitter、电子邮件和电话与客户沟通，客户的团队至少有一天无法正常办公。我们让客户失望了。这是一次痛苦的经历，为此我道歉。

究竟发生了什么？

这起事件始于袭击美国中南部数据中心附近得克萨斯州南部的高能量风暴，包括几次雷击。这导致公用设施区出现了电压骤降和骤升，结果影响了散热系统。确保数据和硬件完整性的自动化数据中心程序立即生效，关键硬件进入了有条不紊的断电过程。因此，美国中南部的VSTS服务无法使用。可以在Azure状态页面（https://azure.microsoft.com/en-us/status/history/）上看到关于数据中心受到影响的更多信息。

VSTS在美国中南部有多项配备扩展单元（SU）的服务。从2018年9月4日09:45 UTC开始，由于数据中心断电过程，美国中南部的所有VSTS SU都宕机了。

除了托管在美国中南部地区的VSTS组织外，托管在该地区的一些全球VSTS服务也受到了影响，比如Marketplace。这导致了全球性影响，例如无法获得扩展功能（包括VS和VS代码的扩展功能）、总体速度减慢、仪表板功能错误以及无法访问存储在美国中南部的用户配置文件。

此外，VSTS组织托管在美国的用户无法使用发布管理和软件包管理这两项服务。使用托管macOS队列的构建和发布管道失效。此外，由于使用美国中南部的数据，VSTS状态页面过期，我们用于为客户发布更新的内部 工具 也托管在美国中南部。

Azure恢复数据中心后，VSTS服务开始恢复如初。几乎所有服务都自行恢复，但未能自行恢复的几项服务需要手动重启。

服务恢复后，就在Azure的恢复工作继续进行之际，客户遇到了Git、发布管理和一些软件包管理等方面的其他问题。VSTS事件结束于2018年9月6日00:05 UTC。

为什么VSTS服务没有故障切换到另一个地区？

我们绝不想丢失任何客户数据。我们的数据保护策略的一个重要部分是，使用Azure SQL DB时间点恢复（PITR）备份和Azure地理冗余存储（GRS），将数据存储在两个地区。这让我们能够在尊重数据主权的同时，在同一个地区复制数据。只有Azure Storage才能决定对GRS存储帐户进行故障切换。如果Azure Storage在这次故障期间切换过去、出现数据丢失，我们仍等待恢复以免数据丢失。

万一出现故障，Azure Storage为恢复提供了两个选项：等待恢复或从只读辅助副本访问数据。使用只读存储会降低Git/TFVC和Build（构建）等关键服务的性能、以至于无法使用，因为既无法签入代码，也无法保存构建的输出（因此无法部署）。此外，一旦备份恢复，故障切换到备份数据库会因备份延迟而导致数据丢失。

我们在努力改进应对数据中心故障的主要解决方案是可用区（AZ），我们还在探究异步复制的可行性。

一个地区内的可用区

有许多故障模式影响某地区的一个或多个数据中心，可使用Azure最近推出的可用区来解决问题。第一批提供可用区的地区于2018年3月上线，目前有五个地区提供可用区。以下是说明文档的描述。

可用区是一种高可用性技术，可保护应用程序和数据免受数据中心故障的影响。可用区是Azure地区内独特的物理位置。每个可用区由一个或多个配备独立电源、散热和网络系统的数据中心组成。为了确保弹性，所有支持可用区的地区至少有三个独立可用区。一个地区内物理分离的可用区可保护应用程序和数据免受数据中心故障的影响。可用区冗余服务可跨可用区复制应用程序和数据，以防出现单一故障点。

可用区旨在提供保护，防范像影响美国中南部的雷击这类事件。它们提供低延迟高带宽连接，由于数据中心邻近，可在一个地区内实现同步复制。比如说，Azure SQL可以将节点分布于诸可用区。可用区将使一个地区的VSTS服务能够继续可用，只要整个地区保持可用性。

跨地区的同步复制

跨地区的同步复制需要在针对写入持久数据的调用返回响应之前，向两个地区提交针对持久数据的每次修改。乍一看，它似乎是理想的解决方案，因为确保两个地区都提交了数据意味着每次故障切换不会有数据丢失。

然而，跨地区同步复制的实际情形很混乱。比如说，与美国中南部配对的地区是美国中北部。即便是光速，数据到达另一个数据中心、原始数据中心收到响应也需要时间。往返延迟添加到每次写入。这为美国中南部和美国中北部之间的每次往返增加了约70ms。对于我们的一些关键服务而言，这个时间太长了。由于种种原因，机器运行速度变慢，网络出现问题。由于只有在两个不同地区的两组不同的服务可以成功地提交数据、作出响应时，每次写入才成功。因此，要么可用性受到影响（等待辅助写入提交时暂停），要么系统必须回退到异步复制。

跨地区的异步复制

所有写入必须始终跨地区同步提交否则失败，这方面的要求放宽意味着，数据将被异步写入辅助地区，这是同步写入的回退模式。如果异步副本速度快，那么在正常情况下，效果实际上与同步复制（数据同时写入到主地区和辅助地区）一样。

通盘考虑

展望未来，我们计划通过使用可用区来解决某个地区内的故障，我们已经开始致力于让VSTS可以使用可用区。可用性目前在五个地区得到支持，将来会有更多的地区支持。美国中南部和托管VSTS服务的另外一些地区还没有可用区。我们需要将服务转移到这些地区，这需要时间。由于目前并非所有地区都有可用区，不会移动那些地区的VSTS服务，以便继续尊重数据主权。这也意味着遇到发生在美国中南部的这类事件，那些地区的VSTS服务将无法使用。

跨地区实现完美的同步复制以确保在任何时间点跨地区的每次故障切换时实现零数据丢失，对于还需要快速的每项服务来说是不可能的。我们的目标是，最有效地兼顾高性能和高可用性这两个相竞争的目标。

解决地区的故障是个难题。我们正在研究跨地区异步复制数据的可行性。如果是Azure SQL，我们将使用活动地理复制。如果是Azure Storage，我们将针对每次写入将数据异步写入到主地区和辅助地区，这将在辅助地区为我们提供第二个副本，万一故障切换时随时可供使用。这将充分利用标准的Azure Storage SLA，GRS没有这种SLA。我们需要在配对的数据中心配置计算及其他资源，或者在故障切换时，或者始终作为热备份来提供。

综上所述，我仍需要解决这个问题：如果数据丢失，何时将故障切换到另一个地区。我不想为客户决定接不接受数据丢失。一些客户告诉我，如果让庞大团队迅速开始工作，丢失数据也认了；另一些客户告诉我，他们不想丢失任何数据，会等数据恢复，不管这个过程有多长。这种情况下的另一个挑战是，面对故障会持续多久没有明确结论的情形，必须做出决定。众所周知，很难准确估计何时恢复，人们几乎总是过于乐观。

满足这两者的唯一方法是，万一某地区不可用，让客户能够选择对其组织进行故障切换。我们已开始探索如何能够为客户提供这种选择，包括表明辅助副本是不是最新，一旦主数据中心恢复，可能提供手动协调。这实际上是我们应不应该实施异步跨地区故障切换机制的关键。由于这是我们刚开始探究的话题，现在判断是否切实可行为时过早。

其他问题

下面我简要介绍我们在这起事件中遇到的另外几个问题。

• 全球影响：我们在美国中南部的一些服务为其他地区的VSTS服务提供功能。美国中南部的发布管理（RM）服务是整个美国RM用户的主要主机。Marketplace服务为VS、VSTS和VS Code的用户提供扩展功能，这是单实例服务。如前所述，我们会努力将这些服务转移到支持可用区的地区。

• 性能下降：User（用户）服务负责提供用户配置文件。每个用户就在多个User服务实例中的一个。事件期间，调用美国中南部User的服务慢慢失效。包装这些呼叫的断路器（circuit breaker）通常会打开，快速失效，并提供一种性能优雅下降的体验。遗憾的是，由于URL模式的不同，断路器包装针对所有User服务实例的调用。因此失效率太低，断路器不会打开（只有针对美国中南部的调用失效，因此大多数调用成功），导致其他地区的客户遇到Web UI很慢的情况，如果他们的配置文件托管在美国中南部。为了消除事件期间的性能影响，我们手动打开断路器，关闭所有用户的配置文件体验。我们正在更改User服务调用的断路器，将调用范围框定于特定实例。此外，我们还发现了过多的重试（为了检索用户首选项），因此在事件期间影响了用户体验。

• 仪表板错误：由于对Marketplace服务进行非关键调用以获得扩展功能的URL，其他地区的用户看到仪表板上出现了错误。这方面还没有经过测试以确保性能优雅下降，我们已为仪表板安排了故障注入测试。

• 不正确的服务状态：事件发生后的头几个小时内，由于依赖美国中南部的AzureStorage，我们无法更新服务状态。我们已经构建了一个新的服务状态门户网站，不仅可以更有效地应对发生在特定地区的故障，还可以通过让客户极容易看到其组织的状态，改善我们在故障期间的沟通方式。由于事件早期发生了Azure活动目录问题，我们在访问与我们的沟通工具一起使用的登录信息时也遇到了问题。

• 服务启动问题：在恢复期间，用于某服务的一小部分虚拟机正在运行，但没有足够的虚拟机来处理入站的负载。我们有一个名为VssHealthAgent的进程负责监测虚拟机的健康状况。虚拟机似乎不健康，因此它按顺序从负载均衡系统中取出每个虚拟机，收集诊断信息，重启虚拟机，然后将它们重新插入到负载均衡系统。这导致转储收集过程在返回到负载均衡系统后很快重新运行。我们修复了这个错误，确保在这样的持续降级状态下从负载均衡系统中删除实例的次数是有限的。虽然这个问题的影响很小，但我把它当作自动缓解所面临的一个固有挑战。

下几步

以下是我们从这次事件中汲取教训后所做的几个改变。

1. 在受支持的区域，将服务转移到提供Azure可用区的地区，以灵活适应某个地区内的数据中心故障。

2. 探究跨地区异步复制的潜在解决方案。

3. 使用我们自己的组织，为VSTS服务定期演练跨地区的故障切换。

4. 为不止一个地区使用的内部工具添加冗余机制。

5. 修复了仪表板中导致对Marketplace的失败调用使仪表板无法使用的回归。

6. 检查用于服务对服务调用的断路器，确保正确的范围（出现在对User服务的调用中）。

7. 评估我们目前的故障注入测试在这次事件中暴露的缺口。

对于这次事件的长时间故障，我再次深表歉意。

相关阅读： Azure 挂了：云被雷击垮了；已持续 22 个小时

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如需转载，请联系原作者获取授权。