4 个 9（99.99%）场景

这个应用程序可用性目标需要应用程序具有较高的可用性并且可以承受组件故障。应用程序必须能够承受故障，而无需购买更多资源。此可用性目标针对的是任务关键型应用程序，这些应用程序是电子商务网站、企业对企业 Web 服务或高流量的内容/媒体站点等此类企业主要或重要的收入推动因素。

我们可以使用区域内静态稳定的架构进一步提高可用性。此可用性目标不需要控制面板改变工作负载的行为来承受故障。例如，应该会有足够的容量来承受一个可用区的损失。我们不要求更新到 Amazon Route 53 DNS。我们不需要创建任何新的基础设施，无论是创建或修改 S3 存储桶、创建新的 IAM 策略（或修改策略），还是修改 Amazon ECS 任务配置。

监控 资源

监控内容包括成功指标以及发生问题时的提醒。此外，每次更换出现故障的 Web 服务器时、数据库失效转移时以及可用区出现故障时，系统都会发出提醒。

适应需求的变化

我们会使用 Amazon Aurora 作为 RDS，因为它支持只读副本进行自动扩展。对于这些应用程序，主要内容的读取可用性优于写入可用性的设计也是一个关键的架构决策。Aurora 还可以视需要自动增加存储，以 10 GB 为单位，最高可达 128 TB。

实施变更

我们会使用金丝雀部署或蓝绿部署，将更新独立部署到每个隔离区中。部署是完全自动化的，包括在 KPI 表明存在问题时的回滚。

运行手册中应提出严格的报告要求和性能跟踪。如果成功运营趋向于无法实现性能或可用性目标，则将使用行动手册来确定导致这一趋势的原因。行动手册可用于确定未发现的故障模式和安全事件，还可用于确定发生故障的根本原因。我们还将与 AWS Support 一起提供基础设施事件管理产品。

负责构建与运营网站的团队需要确定任何意外故障的错误更正，并确定实施修复程序后进行部署的优先级。

备份数据

备份和还原操作可以通过使用 Amazon RDS 完成。按照运行手册定期执行操作，确保我们可以满足恢复要求。

构建韧性

我们建议针对此方法使用三个可用区。使用三可用区部署，每个可用区最多拥有 50% 的静态容量。也可以使用两个可用区，但静态稳定容量的成本会更高，因为两个可用区都必须拥有 100% 的峰值容量。我们会添加 Amazon CloudFront 来提供地理缓存，也会减少应用程序数据面板上的请求。

我们会使用 Amazon Aurora 作为 RDS，并在三个可用区内部署只读副本。

应用程序将在所有层上使用软件/应用程序韧性模式进行构建。

测试韧性

部署管道具有完整的测试套件，包括性能、负载和故障注入测试。

我们会在演练日活动期间不断演练我们的故障恢复程序，使用运行手册确保我们可以执行任务，不会偏离程序。构建网站的团队也负责运营该网站。

灾难恢复（DR）计划

整个工作负载恢复和常用报告都有运行手册。恢复会使用备份，而且这些备份被存储在与工作负载相同的区域。演练日活动期间会定期演练还原程序。

可用性设计目标

假设有一些故障必须要手动决定执行恢复，尽管有更好的自动化选项。假定每年只有两个事件需要做这种决定，那么恢复操作会很快。我们需要 10 分钟决定运行恢复，并在 5 分钟内完成恢复。这就表示，大约需要 15 分钟就能从故障中恢复。假设一年发生两次故障，预计每年受影响的时间为 30 分钟，

这意味着可用性上限是 99.99%。实际可用性还将取决于实际故障率、故障持续时间以及每个因素的实际恢复速度。对于这种架构，我们假设应用程序通过更新持续在线。基于此，我们的可用性设计目标为 99.99%。

Summary

主题	实施
监控 资源	对所有层和 KPI 执行运行状况检查；在配置的警报被触发时发出提醒；提醒发生故障。运营会议将密切探讨趋势，并设法达成设计目标。
适应需求的变化	适用于 Web 和自动扩展应用程序层的 ELB；在多个区域为 Aurora RDS 自动扩展存储与只读副本。
实施变更	自动执行金丝雀部署或蓝绿部署，并在 KPI 或提醒表明应用程序中有未检测到的问题时自动回滚。隔离区域会执行部署。
备份数据	通过 RDS 自动备份来满足 RPO 和在演练日活动期间定期演练的自动还原要求。
构建韧性	为应用程序实施故障隔离区；自动扩缩以提供自我修复的 Web 和应用程序层；RDS 为多可用区。
测试韧性	管道内有组件和隔离区域故障测试，并由运营人员在演练日活动期间定期演练；存在用于诊断未知问题的行动手册；还有根本原因分析流程。
灾难恢复（DR）计划	通过 RDS 将备份加密存储于相同的 AWS 区域，并在演练日活动期间进行演练。