RTO和RPO
恢复时间目标 (RTO) 由组织定义。RTO是服务中断和恢复服务之间可接受的最大延迟。这决定了当服务不可用时，什么时间段被视为可接受的时间窗口。 恢复点目标 (RPO) 由组织定义。RPO是自上次数据恢复点以来的最大可接受时间。这决定了从上一个恢复点到服务中断之间可接受的数据丢失情况。
RPO（恢复点目标）、RTO（恢复时间目标）和灾难事件的关系。
RTO与MTTR（平均恢复时间）类似，因为两者都衡量从中断开始到工作负载恢复之间的时间。但是，平均值MTTR是在一段时间内取代多个影响可用性的事件，而RTO影响单个可用性事件的目标值或允许的最大值。
可用性（又称为服务可用性）既是定量衡量韧性的常用指标，也是具有针对性的韧性目标。
- 可用性是指工作负载可供使用的时间百分比。
- 可用性是一段时间（通常是一个月或一年）内正常运行时间的百分比（例如 99.9%）
- 常见的简单表达方式仅指“9 的数量”；例如，“5 个 9”表示 99.999% 可用
- 在公式中，有些客户选择在总时间中排除计划内的维护停机时间（例如计划内维护）。但不建议采用这种方法，因为用户可能希望在这些时间内使用您的服务。
下表列出了常见的应用程序可用性设计目标，以及在仍然达到目标的同时，一年内可能会出现的最长中断时间。该表包含我们常常会在每个可用性层看到的应用类型示例。在本文档中，我们会引用这些值。
根据请求测量可用性：对服务而言，计算成功和失败的请求数可能比计算“可用时间”更容易。在这种情况下，可以采用如下计算公式：
针对硬依赖关系计算可用性：许多系统对其他系统具有硬依赖关系，依赖的系统中的中断会直接转换为调用系统的中断。这与软依赖关系相反，其中依赖的系统的故障会在应用程序中得到弥补。在出现此类硬依赖关系的情况下，调用系统的可用性是依赖的系统可用性的结果。例如，如果您有一个旨在实现 99.99% 可用性的系统，它对两个其他独立系统具有硬依赖关系，这两个系统都旨在实现 99.99% 的可用性，则工作负载在理论上可以实现 99.97% 的可用性：
Availinvok × Availdep1 × Availdep2 = Availworkload
99.99% × 99.99% × 99.99% = 99.97%
针对冗余组件计算可用性：当系统涉及到使用独立的冗余组件（例如，不同可用区中的冗余资源）时，从理论上讲，可用性的计算方法是：100% 减去组件故障率的乘积。例如，如果系统使用了两个独立的组件，每个组件都具有 99.9% 的可用性，此依赖项的有效可用性为 99.9999%： 计算依赖项的可用性。有些依赖项会提供有关其可用性的指导，包括许多 AWS 服务的可用性设计目标。但是，在不可用的情况下（例如，制造商不发布可用性信息的组件），一种估算方法是确定平均故障间隔时间 (MTBF) 和平均恢复时间 (MTTR)。可以通过以下公式来确定可用性估算值：
