3 个 9（99.9%）场景

下一个可用性目标针对务必要具备高可用性的应用程序，但是这些应用程序可以承受短时间的不可用。这种类型的工作负载通常用于内部操作，而且此类操作在发生故障时会对员工造成影响。这种类型的工作负载也可能是面向客户的，它们不会带来很高的业务收入，并且可以承受较长的恢复时间或恢复点。这类工作负载包括账户或信息管理的管理应用程序。

我们可以使用两个可用区进行部署，并将应用程序分到不同的层中，从而改进工作负载的可用性。

监控资源

通过在主页上检查 HTTP 200 OK 状态，监控可以扩展为对网站上的可用性发出提醒。此外，每次更换 Web 服务器时、数据库故障转移时，系统都会发出提醒。我们还将监控 Amazon S3 上的静态内容以了解可用性，并在其不可用时发出提醒。日志记录将被汇总，以便于管理并帮助进行根本原因分析。

适应需求的变化

配置自动扩展以监控 EC2 实例上的 CPU 利用率，通过添加或移除实例将 CPU 目标维持在 70%，而且每个可用区内有不少于一个的 EC2 实例。若 RDS 实例上的负载模式显示需要进行扩展，我们将在维护时段更改实例类型。

实施变更

基础设施部署技术与之前的场景相同。

按每两到四周一次的固定日程安排交付新软件。软件更新将自动完成，不是使用 Canary 部署或蓝/绿部署模式，而是使用在位替换。回滚决策将使用运行手册做出。

我们将使用行动手册来找出问题的根本原因。在确定根本原因之后，运营和开发团队会共同确定错误修正方案，并在开发出解决方案后进行部署。

备份数据

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

构建弹性

我们可以使用两个可用区进行部署，并将应用程序分到不同的层中，从而改进应用程序的可用性。我们将使用跨多个可用区工作的服务，如 Elastic Load Balancing、Auto Scaling 和 Amazon RDS 多可用区部署，并通过 AWS Key Management Service 实现加密存储。这将确保在资源级别和可用区级别上能够容忍故障。

负载均衡器只会将流量路由到正常运行的应用程序实例。运行状况检查需要在数据平面/应用程序层上进行，以表明应用程序在实例上的容量。此检查不应针对控制平面。系统将提供 Web 应用程序运行状况检查 URL，并配置为可供负载均衡器和 Auto Scaling 使用，以便能够删除和替换发生故障的实例。如果实例在主可用区内发生故障，Amazon RDS 将管理活动数据库引擎，使其在第二个可用区可用，然后执行修复以还原到相同弹性。

在分层之后，我们可以使用分布式系统弹性模式提高应用程序的可靠性，甚至当数据库在可用区故障转移过程中暂时不可用时，让应用程序仍然可用。

测试弹性

与之前的场景一样，我们会执行功能测试。我们不会测试 ELB、自动扩展或 RDS 故障转移的自我修复功能。

.我们将提供行动手册，其中包含针对常见数据库问题、安全相关事件，以及部署失败的相关解决方案。

灾难恢复 (DR) 计划

整个工作负载恢复和常用报告都有运行手册。恢复会使用备份，而且这些备份被存储在与工作负载相同的区域。

可用性设计目标

假设有一些故障必须要人工决定执行恢复。但为了尽可能提高这种场景下的自动化程度，我们假设每年只有两个事件需要做这种决定。我们需要 30 分钟决定执行恢复，并在 30 分钟内完成恢复。这意味着从故障中恢复需要 60 分钟。假设一年发生两次故障，预计每年受影响的时间为 120 分钟，

这意味着可用性上限是 99.95%。实际可用性还取决于实际故障率、故障持续时间以及每次故障的实际恢复速度。对于此架构，我们需要应用程序暂时离线以执行更新，但这些更新自动进行。我们估计每年需要为此花费 150 分钟：每次更改 15 分钟，每年 10 次。服务不可用的时间是每年总计 270 分钟，所以我们的 可用性设计目标 是 99.9%。

总结

主题	实施
监控资源	仅站点运行状况检查；在发生故障时发出提醒。
适应需求的变化	适用于 Web 和自动扩展应用程序层的 ELB；调整多可用区 RDS 的大小。
实施变更	自动部署到位和用于回滚的运行手册。
备份数据	通过 RDS 自动化备份，以满足 RPO 和用于恢复的运行手册的要求。
构建弹性	自动扩展以提供自我修复的 Web 和应用程序层；RDS 为多可用区。
测试弹性	ELB 和应用程序会自我修复；RDS 是多可用区；无显式测试。
灾难恢复 (DR) 计划	通过 RDS 将加密备份存储于相同的 AWS 区域。