# 可靠性
<a name="reliability"></a>

 可靠性支柱涵盖相关工作负载按照计划正确而稳定执行其预期功能的能力。这包括在其全部生命周期内运行和测试工作负载的能力。本白皮书深入介绍了有关在 AWS 中实施可靠工作负载的最佳实践指导。

**Topics**
+ [韧性的责任共担模式](shared-responsibility-model-for-resiliency.md)
+ [设计原则](design-principles.md)
+ [定义](definitions.md)
+ [了解可用性需求](understanding-availability-needs.md)

# 韧性的责任共担模式
<a name="shared-responsibility-model-for-resiliency"></a>

 韧性是 AWS 和您的共同责任。您要了解作为韧性一部分的灾难恢复（DR）和可用性在这个共担模式下如何运行，这很重要。

 **AWS 责任 – 云的韧性** 

 对于运行 AWS 云 中提供的所有服务的基础设施，AWS 负责维持其韧性。此基础设施包括运行 AWS 云 服务的硬件、软件、网络和设施。AWS 采取合理的商业措施来提供这些 AWS 云 服务，确保服务可用性达到或超过 [AWS 服务水平协议（SLA）](https://aws.amazon.com/legal/service-level-agreements/)。

 [AWS 全球云基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)旨在让客户能够构建高韧性的工作负载架构。每个 AWS 区域 都完全隔离，由多个[可用区](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones)组成，这些可用区是基础设施的物理隔离分区。可用区会隔离可能影响工作负载韧性的故障，防止这些故障影响区域内的其他可用区。与此同时，AWS 区域 中的所有可用区都通过完全冗余的专用城域光纤，以高带宽、低延迟的网络进行互联，从而在可用区之间实现高吞吐量、低延迟的联网。可用区之间的所有流量都经过加密。网络性能足以完成可用区之间的同步复制。跨可用区对应用程序进行分区时，公司可以实现更好的隔离和保护，防止受到停电、雷击、龙卷风、飓风等事故和灾害的影响。

 **客户责任 – 云中的韧性** 

 您的责任由您选择的 AWS 云 服务决定。这决定了您承担韧性责任时必须执行的配置工作量。例如，Amazon Elastic Compute Cloud（Amazon EC2）等服务要求客户执行所有必要的韧性配置和管理任务。部署 Amazon EC2 实例的客户负责[在多个位置部署 Amazon EC2 实例](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)（例如 AWS可用区），使用自动扩缩等服务[实施自我修复](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)，以及对安装在实例上的应用程序使用[韧性工作负载架构最佳实践](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)。对于托管服务（例如 Amazon S3 和 Amazon DynamoDB），AWS 会运营基础设施层、操作系统和平台，而客户访问端点即可存储和检索数据。您负责管理数据的韧性，包括备份、版本控制和复制策略。

 在 AWS 区域 的多个可用区中部署工作负载是高可用性策略的一部分，该策略将问题隔离在一个可用区，同时使用其他可用区的冗余继续处理请求，以此保护工作负载。多可用区架构也是灾难恢复策略的一部分，旨在更好地隔离工作负载，防止受到停电、雷击、龙卷风、地震等事故和灾害的影响。灾难恢复策略也可以使用多个 AWS 区域。例如，在主动/被动配置中，如果主动区域不再处理请求，则工作负载的服务会从其主动区域失效转移到其灾难恢复区域。

![\[展示韧性共担模式的图表。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png)


 

 您可以使用 AWS 服务来实现韧性目标。作为客户，您负责管理系统的以下方面，以便实现云中的韧性。有关每项服务的更多详细信息，请参阅 [AWS 文档](https://docs.aws.amazon.com/index.html)。

 **联网、配额和限制** 
+  [基础](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html)部分详细介绍了责任共担模式这一领域的最佳实践。
+  根据预期的负载请求增加情况（如果适用），规划留足了扩展空间的架构，了解所包含服务的[服务配额](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html)和限制。
+  设计[网络拓扑](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)，使其具有高可用性、冗余性和可扩展性。

 **变更管理和运营韧性** 
+  [变更管理](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html)包括如何在环境中引入和管理变更。[实施变更](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html)需要构建运行手册并让其保持最新状态，也需要为应用程序和基础设施制定部署策略。
+  [监控工作负载资源](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html)的韧性策略考虑了所有组件，包括技术和业务指标、通知、自动化以及分析。
+  云中的工作负载必须[适应需求变化](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html)，能根据受损情况或使用量波动情况进行横向缩减。

 **可观测性和故障管理** 
+  必须通过监控来观测故障才能自动执行修复，让工作负载能够[承受组件故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)。
+  [故障管理](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html)要求[备份数据](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html)，运用最佳实践让工作负载能够承受组件故障,以及[规划灾难恢复](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)。

 **工作负载架构** 
+  [工作负载架构](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)包括如何围绕业务领域设计服务、运用 SOA 和分布式系统设计来防止发生故障，以及如何内置节流、重试、队列管理、超时和应急措施等功能。
+  依靠经过验证的 [AWS 解决方案](https://aws.amazon.com/solutions/)、[Amazon Builders' Library](https://aws.amazon.com/builders-library/) 和 [serverless patterns](https://serverlessland.com/patterns) 来与最佳实践保持一致，从而快速启动实施。
+  通过持续改进将系统分解为分布式服务，以便更快地扩展和创新。使用 [AWS 微服务](https://aws.amazon.com/microservices/)指导和托管服务选项来简化引入变更和实现创新的工作，提高完成这类工作的能力。

 **关键基础设施的持续测试** 
+  [测试可靠性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html)意味着在功能、性能和混乱层面进行测试，也意味着采用事件分析和演练日活动实践来积累专业知识，解决人们不太了解的问题。
+  对于全云部署和混合应用程序，如果知道在出现问题或组件故障时应用程序会有怎样的表现，您就可以快速和可靠地从故障中恢复。
+  创建并记录可重复的试验，了解事情未按预期发展时系统有何表现。这些测试会证明整体韧性的有效性，并在面对真正的故障场景之前为运营程序提供反馈环路。

# 设计原则
<a name="design-principles"></a>

 在云中，有许多原则可帮助您提高可靠性。在讨论最佳实践时，请记住以下几点：
+  **自动从故障中恢复：**通过监控工作负载的关键性能指标（KPI），您可以在指标超过阈值时触发自动化响应机制。这些 KPI 应该是对业务价值（而不是服务运营的技术方面）的一种度量。这可实现自动发送故障通知和跟踪故障，以及启动解决或修复故障的自动恢复流程。借助更高级的自动化功能，可以在故障发生之前预测和修复故障。
+  **测试恢复程序：**在本地环境中，经常会通过执行测试来证明工作负载能够在特定场景中正常运作。通常不会利用测试来验证恢复策略。在云中，您可以测试工作负载的故障情况，并验证恢复程序。您可以采用自动化方式来模拟不同的故障，也可以重新建立之前导致故障的场景。此方式可以在实际的故障发生*以前*揭示您可以测试与修复的故障路径，从而降低风险。
+  **横向扩展以提高聚合工作负载的可用性：**使用多个小型资源取代一个大型资源，以降低单个故障对整个工作负载的影响。跨多个较小的资源分配请求，确保不会共用常见故障点。
+  **无需预估容量：**本地工作负载出现故障的常见原因是资源饱和，即对工作负载的需求超过该工作负载的容量（这通常是拒绝服务攻击的目标）。在云中，您可以监控需求和工作负载利用率，并自动添加或删除资源，以保持最佳水平来满足需求，而不会出现超额预置或预置不足的问题。虽然还有很多限制，但有些配额是可控的，其他配额也可以管理（请参阅[管理服务配额和限制](manage-service-quotas-and-constraints.md)）。
+  **通过自动化管理变更：**使用自动化方式对基础设施进行变更。需要管理的变更包括对自动化的变更，可对其进行跟踪与审查。

# 定义
<a name="definitions"></a>

 本白皮书涵盖了云中的可靠性，对以下四个领域的最佳实践进行描述：
+  基本原理 
+  工作负载架构 
+  变更管理 
+  故障管理 

 要实现可靠性，您必须从基础入手，而基础是服务配额和网络拓扑适应工作负载的环境。在设计时，分布式系统的工作负载架构必须能够预防与减少故障。工作负载必须处理需求或要求的变化，而且它的设计必须能够检测故障，并自动加以修复。

**Topics**
+ [韧性与可靠性的组件](resiliency-and-the-components-of-reliability.md)
+ [可用性](availability.md)
+ [灾难恢复（DR）目标](disaster-recovery-dr-objectives.md)

# 韧性与可靠性的组件
<a name="resiliency-and-the-components-of-reliability"></a>

 云中的工作负载可靠性取决于多个因素，其中最主要的要属*韧性*：
+  **韧性**是指工作负载从基础设施故障或服务中断中恢复，并能动态获取计算资源来满足需求以及减少中断（如错误配置或暂时性网络问题）的能力。

 会对工作负载可靠性产生影响的其他因素还有：
+  卓越运营，其中包括变更自动化，使用行动手册对故障做出响应，以及通过运营准备情况审查（ORR）确保应用程序已经为生产运营做好准备。
+  安全性，其中包括杜绝恶意行为者破坏数据或基础设施，避免影响可用性。例如，使用加密备份来确保数据安全。
+  性能效率，其中包括通过设计在最大程度上提高工作负载的请求速率，并且将延迟最小化。
+  成本优化，其中包括权衡取舍，如确定要在 EC2 实例上投入更多以实现静态稳定性，还是在需要更大容量时依赖自动扩展。

 韧性是本白皮书的主要关注点。

 其他四个因素也很重要，我们将在讨论 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 的相应支柱时加以介绍。这里的许多最佳实践也解决了可靠性在这些方面的问题，但重点是韧性。

# 可用性
<a name="availability"></a>

 *可用性*（又称为*服务可用性*）既是定量衡量韧性的常用指标，也是具有针对性的韧性目标。
+  **可用性**是指工作负载可供使用的时间百分比。

 *可供使用*指的是在需要时能够履行约定的功能。

 这里计算的是一段时间内的百分比，例如一个月、一年或之后的三年。最严格地来说，当应用程序不能正常运行（包括计划内和计划外的中断）时，可用性就会降低。我们按以下方式计算*可用性*：

![\[\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/availability-formula.png)

+ 可用性是一段时间（通常是一个月或一年）内正常运行时间的百分比（例如 99.9%） 
+  常见的简单表达方式仅指“9 的数量”；例如，“5 个 9”表示 99.999% 可用 
+ 在公式中，有些客户选择在*总时间*中排除计划内的维护停机时间（例如计划内维护）。但不建议采用这种方法，因为用户可能希望在这些时间内使用您的服务。

 下表列出了常见的应用程序可用性设计目标，以及在仍然达到目标的同时，一年内可能会出现的最长中断时间。该表包含我们常常会在每个可用性层看到的应用类型示例。在本文档中，我们会引用这些值。


|  可用性  |  最大不可用性（每年）  |  应用程序类别  | 
| --- | --- | --- | 
|  99%  |  3 天 15 小时  |  批处理、数据提取、传输和加载作业  | 
|  99.9%  |  8 小时 45 分钟  |  知识管理、项目跟踪等内部工具  | 
|  99.95%  |  4 小时 22 分钟  |  电子商务、销售点  | 
|  99.99%  |  52 分钟  |  视频传输、广播工作负载  | 
|  99.999%  |  5 分钟  |  ATM 交易、电信工作负载  | 

**根据请求测量可用性：**对服务而言，计算成功和失败的请求数可能比计算“可用时间”更容易。在这种情况下，可以采用如下计算公式：

![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)


这通常以一分钟或五分钟为周期进行测量。然后，可以根据这些时间段的平均值计算每月正常运行时间百分比（基于时间的可用性测量）。如果在给定时间段内未收到任何请求，则该时间段内的可用性为 100%。

  

 **针对硬依赖关系计算可用性：**许多系统对其他系统具有硬依赖关系，依赖的系统中的中断会直接转换为调用系统的中断。这与软依赖关系相反，其中依赖的系统的故障会在应用程序中得到弥补。在出现此类硬依赖关系的情况下，调用系统的可用性是依赖的系统可用性的结果。例如，如果您有一个旨在实现 99.99% 可用性的系统，它对两个其他独立系统具有硬依赖关系，这两个系统都旨在实现 99.99% 的可用性，则工作负载在理论上可以实现 99.97% 的可用性：

 Availinvok × Avail*dep1* × Avail*dep2* = Availworkload 

 99.99% × 99.99% × 99.99% = 99.97% 

 因此，在计算可用性时，您一定要了解依赖项及其可用性设计目标。

 **针对冗余组件计算可用性：**当系统涉及到使用独立的冗余组件（例如，不同可用区中的冗余资源）时，从理论上讲，可用性的计算方法是：100% 减去组件故障率的乘积。例如，如果系统使用了两个独立的组件，每个组件都具有 99.9% 的可用性，此依赖项的有效可用性为 99.9999%：

![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/image2.png)


 Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency)) 

 99.9999% = 100% − (0.1%×0.1%) 

 *快捷方式计算*：如果计算中所有组件的可用性仅包含数字九，则可以将九的数量相加得出答案。在上面的示例中，两个具有 3 个 9 可用性的冗余独立组件得到 6 个 9 可用性。

 **计算依赖项的可用性。**有些依赖项会提供有关其可用性的指导，包括许多 AWS 服务的可用性设计目标。但在没有相关指导的情况下（例如，制造商未发布可用性信息的组件），一个估算方式是确定**平均故障间隔时间（MTBF）**和**平均恢复时间（MTTR）**。可以通过以下公式来确定可用性估算值：

![\[\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)


 例如，如果 MTBF 为 150 天，且 MTTR 为 1 小时，则可用性估算值是 99.97%。

 有关更多详细信息，请参阅 [Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)，了解如何计算可用性。

 **可用性的成本：**设计应用程序来实现更高级别的可用性通常会导致成本增加，因此在开始设计应用程序之前，应该确定真正的可用性需求。高级别的可用性对彻底失败场景下的测试和验证提出了更严格的要求。它们要求从各种故障中自动恢复，并要求系统运营的所有方面都按照相同的标准进行类似的构建和测试。例如，容量的添加或删除、更新软件或配置更改的部署或回滚或者系统数据的迁移，都必须依照预期的可用性目标进行。可用性级别非常高时，软件部署的成本会增加，相应地，创新会受到影响，因为在部署系统时需要放慢行动速度。因此，这里的指导方针是，在系统运营的整个生命周期内，在应用标准和考虑适当的可用性目标时，要做得彻底。

 在具有更高可用性设计目标的系统中，成本增加的另一种方式与依赖项的选择有关。在目标较高的情况下，可以选择作为依赖项的软件或服务集减少，具体取决于其中哪些服务已具备我们前面所说的深度投资。随着可用性设计目标的增加，通常要少找一些多用途服务（例如关系数据库），多找一些专用服务。这是因为后者更易于评估、测试和自动化，与包括在内但未使用的功能发生意外交互的可能性也较低。

# 灾难恢复（DR）目标
<a name="disaster-recovery-dr-objectives"></a>

 除了可用性目标之外，韧性策略还应包括灾难恢复（DR）目标，这些目标基于发生灾难事件时恢复工作负载的策略。灾难恢复侧重于一次性恢复目标，可应对自然灾害、大规模技术故障或人为威胁（如攻击或错误）。这与可用性不同，可用性衡量的是一段时间内响应组件故障、负载峰值或软件错误的平均韧性。

 **恢复时间目标（RTO）**由组织定义。RTO 是指服务中断和服务恢复之间可接受的最大延迟。这决定了当服务不可用时，什么时间段被视为可接受的时间窗口。

 **恢复点目标（RPO）**由组织定义。RPO 是指自上一个数据恢复点以来可接受的最长时间。这决定了从上一个恢复点到服务中断之间可接受的数据丢失情况。

![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/business-continuity.png)


*RPO（恢复点目标）、RTO（恢复时间目标）和灾难事件之间的关系。*

 RTO 和 MTTR（平均恢复时间）相似，两者都测量中断开始到工作负载恢复之间的时间。但 MTTR 取的是一段时间内多次影响可用性的事件的平均值，而 RTO 则是*单次*可用性影响事件允许的目标或最大值。

# 了解可用性需求
<a name="understanding-availability-needs"></a>

 人们最初会认为应用程序的可用性是整个应用程序的单一目标，这种想法很常见。但是，经过仔细检查后，我们经常发现应用程序或服务的某些方面具有不同的可用性要求。例如，比起检索现有数据，某些系统可能会优先实现接收和存储新数据的功能。又或者，比起更改系统配置或环境的操作，有些系统可能会优先执行实时操作。服务可能会在一天中的某些时段具有非常高的可用性要求，但可以容忍这些时段之外的更长时间的中断。您可以通过这些方法来将单个应用程序分解成各个组成部分，并评估每个部分的可用性要求。这样做的好处是可以根据特定需求集中投入可用性方面的精力（和费用），而不是根据最严格的要求设计整个系统。


|  建议  | 
| --- | 
|  批判性地评估应用程序的独特方面，并在适当的情况下区分可用性和灾难恢复设计目标来反映业务需求。 | 

 在 AWS，我们通常会将服务分为“数据面板”和“控制面板”。数据面板负责交付实时服务，控制面板则用于配置环境。例如，Amazon EC2 实例、Amazon RDS 数据库和 Amazon DynamoDB 表的读/写操作都是数据面板操作。而启动新的 EC2 实例或 RDS 数据库，或者在 DynamoDB 中添加或更改表元数据，都属于控制面板操作。虽然高水平的可用性对所有这些功能来说都很重要，但数据面板的可用性设计目标通常比控制面板更高。因此，具有高可用性需求的工作负载应该避免运行时依赖于控制面板操作。

 很多 AWS 客户会采用类似的方法批判性地评估其应用程序，并识别具有不同可用性需求的子组件。然后，针对不同的方面量身定制可用性设计目标，并执行适当的工作来设计系统。AWS 拥有根据一系列可用性设计目标设计应用程序的丰富经验，包括设计具有 99.999% 或更高可用性的服务。AWS解决方案架构师（SA）可帮助您根据可用性目标进行合理设计。在设计过程中尽早让 AWS 参与进来，有助于我们更好地帮助您实现可用性目标。并不是只有在启动工作负载前才要针对可用性进行规划，还应该持续不断地进行规划，从而在获得运营经验的过程中细化设计，从实际事件中吸取经验教训，并能承受不同类型的故障。然后，您可以投入适当的工作来改进实施。

 工作负载所需的可用性需求必须与业务需求和关键性相符。使用定义的 RTO、RPO 和可用性来定义业务关键性框架，然后您就可以对每个工作负载进行评估。此方法要求参与工作负载实施的人员了解该框架，了解工作负载对业务需求的影响。