灰色故障

灰色故障因其差异可观测性的特征而得名，反映不同实体对故障的观察方式不同。下面我们来做一下定义。

差异可观测性

您操作的工作负载通常都有依赖项。比如，它们可以是您用来构建工作负载的 AWS 云服务，也可以是用于联合身份验证的第三方身份提供者 (IdP)。这些依赖项几乎会一直实现自己的可观测性：记录有关错误、可用性和延迟的指标，以及由其客户使用情况生成的其他指标。当其中一个指标超过阈值时，依赖项通常会采取一些措施来进行纠正。

这些依赖项通常有多个使用者使用其服务。使用者还可以实现自己的可观测性，并记录有关其与依赖项交互的指标和日志，记录诸如磁盘读取延迟、API 请求失败次数或数据库查询花了多长时间之类的信息。

下图使用抽象模型描述了这些交互和测量。

用于了解灰色故障的抽象模型

首先，在此场景中，系统是使用者应用程序 1、应用程序 2 和应用程序 3 的依赖项。该系统具有故障探测器，可以检查从核心业务流程中创建的指标。它还具有故障响应机制，可以缓解或纠正故障探测器观察到的问题。我们可以看到，系统总体的平均延迟为 53 毫秒，并设置了阈值，在平均延迟超过 60 毫秒时调用故障响应机制。应用程序 1、应用程序 2 和应用程序 3 也对它们与系统的交互进行了自己的观察，记录的平均延迟分别为 50 毫秒、53 毫秒和 56 毫秒。

差异可观测性是指其中一个系统使用者检测到系统运行状况不佳，但系统自己的监控无法检测到问题或受到的影响未超过警报阈值的情况。假设应用程序 1 的平均延迟开始达到 70 毫秒，而不是 50 毫秒。而应用程序 2 和应用程序 3 的平均延迟时间没有变化。这会将底层系统的平均延迟增加到 59.66 毫秒，但这并没有超过激活故障响应机制的延迟阈值。但是，应用程序 1 的延迟增加了 40%。这可能会超过为应用程序 1 配置的客户端超时时间，从而影响其可用性，也可能在更长的交互链中造成级联影响。从应用程序 1 的角度来看，它所依赖的底层系统运行状况不佳，但是从系统本身以及应用程序 2 和应用程序 3 的角度来看，该系统是正常的。下图总结了这些不同的视角。

象限图定义了从不同视角来看系统可能处于的不同状态

故障也可能从一个象限跨越到另一个象限。事件可能最开始时是灰色故障，然后变成检测到的故障，然后转变为屏蔽故障，然后可能回到灰色故障。没有明确的周期，在根本原因得到解决之前，几乎随时有可能再次出现故障。

我们从中得出的结论是，工作负载不能总是依靠底层系统来检测和缓解故障。无论底层系统多么先进、有弹性，总有故障会逃脱检测，或保持在反应阈值以内。该系统的使用者（例如应用程序 1）需要得到强化，以快速检测和缓解灰色故障造成的影响。这就要求针对这些情况建立可观测性和恢复机制。

灰色故障示例

灰色故障可能会对 AWS 中的多可用区系统产生影响。例如，以部署在三个可用区的自动扩缩组中的 Amazon EC2 实例的实例集为例。它们都连接到一个可用区内的 Amazon Aurora 数据库。然后，出现灰色故障，会影响可用区 1 和可用区 2 之间的网络连接。这种损坏的结果是，来自可用区 1 中实例的新的和现有数据库连接中有一定比例会失败。下图展示了这种情况。

灰色故障影响了可用区 1 中实例的数据库连接

在此示例中，Amazon EC2 认为可用区 1 中的实例运行状况良好，因为它们仍可通过系统和实例状态检查。Amazon EC2 Auto Scaling 也不会检测到对任何可用区的直接影响，而会继续在已配置的可用区中启动容量。Network Load Balancer (NLB) 会根据针对 NLB 端点执行的 Route 53 运行状况检查，认为其后面的实例运行状况良好。同样，Amazon Relational Database Service (Amazon RDS) 也会认为数据库集群运行状况良好，不会触发自动失效转移。我们有许多不同的服务，它们都认为其服务和资源运行状况良好，但是工作负载检测到影响其可用性的故障。这是一个灰色故障。

应对灰色故障

如果您的 AWS 环境中出现灰色故障，您通常有三个选项可以选择：

• 什么都不做，等待损坏结束。

• 如果损坏隔离在单个可用区，请撤离该可用区。

• 失效转移到另一个 AWS 区域 并利用 AWS 区域隔离的优势来缓解影响。

对于大多数工作负载，许多 AWS 客户都认为第一个选项还不错。他们可以接受可能延长的恢复时间目标 (RTO)，只要不必构建额外的可观测性或弹性解决方案。其他客户选择实现第三个选项，即多区域灾难恢复 (DR)，作为其针对各种故障模式的缓解计划。在这些场景中，多区域架构可以很好地发挥作用。但是，使用这种方法时需要进行一些权衡（有关多区域注意事项的完整讨论，请参阅AWS 多区域基础知识）。

首先，构建和运营多区域架构具有挑战性、复杂性且可能产生高昂成本。要使用多区域架构，您需要认真考虑选择哪种灾难恢复策略。仅仅为了处理区域损坏而实施多区域主动-主动灾难恢复解决方案在财务上可能不可行，而备份和恢复策略可能无法满足您的弹性要求。此外，多区域失效转移必须要在生产中持续开展，这样您才能确信它们能在需要时起作用。所有这些都需要专门投入大量时间和资源来构建、操作和测试。

其次，如今使用 AWS 服务跨 AWS 区域 复制数据都是异步执行的。异步复制可能导致数据丢失。这意味着在区域失效转移期间，可能会出现一定程度的数据丢失和不一致。您对数据丢失量的容忍度即为恢复点目标 (RPO)。如果客户对数据一致性要求严格，则当主区域再次可用时，他们必须建立协调系统来修复这些一致性问题。或者，他们必须构建自己的同步复制或双写系统，这会对响应延迟、成本和复杂性产生重大影响。它们还将次要区域作为每项事务的硬依赖项，这可能会降低整个系统的可用性。

最后，对于许多使用主动/备用方法的工作负载，执行失效转移到另一个区域所需的时间不为零。您的工作负载组合可能需要按特定顺序在主区域中关闭，需要耗尽连接或停止特定进程。然后，可能需要按特定顺序恢复这些服务。在投入使用之前，新资源可能还需要进行配置或需要一段时间才能通过所需的运行状况检查。在此失效转移过程中，各种资源完全不可用。这就是 RTO 所关心的问题。

在一个区域内，许多 AWS 服务都提供高度一致的数据持久性。Amazon RDS 多可用区部署使用同步复制。Amazon Simple Storage Service (Amazon S3) 提供强大的先写后读一致性。Amazon Elastic Block Storage (Amazon EBS) 提供多卷崩溃一致性快照。Amazon DynamoDB 可以强一致性读取。与多区域架构相比，这些功能可以帮助您在单个区域中实现更低的 RPO（在大多数情况下为零 RPO）。

撤离可用区的 RTO 低于多区域策略，因为您已为各个可用区配置了基础设施和资源。当可用区受损时，多可用区架构可以继续以静态方式运行，而不必小心翼翼地订购被关闭的服务并进行备份，也不必耗尽连接。在可用区撤离期间，由于工作转移到剩余的可用区，许多系统可能只会出现轻微的降级，而不会像区域失效转移那样出现完全不可用时期。如果系统设计为能够在可用区故障时保持静态稳定（在本例中，这意味着在其他可用区预先配置容量以接纳负载），则工作负载的客户可能根本感受不到影响。

除了您的工作负载外，单个可用区的损坏还可能影响一项或多项 AWS 区域服务。如果您观察到区域影响，则应将该事件视为区域服务损坏，尽管该影响的来源位于单个可用区。撤离可用区并不能缓解此类问题。发生这种情况时，请使用您现有的应对计划来应对区域服务损坏。

本文档的其余部分重点介绍第二种选择，即撤出可用区，以此来降低单可用区灰色故障的 RTO 和 RPO。这些模式可以帮助多可用区架构实现更高价值和效率，对于大多数类别的工作负载，还可以减少创建多区域架构来处理这些类型事件的需求。