# 定义
<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 则是*单次*可用性影响事件允许的目标或最大值。