2 个 9（99%）场景

这些工作负载对业务有帮助，但如果不可用， 它们只会带来 不便。此类工作负载可以是内部工具、内部知识管理或项目跟踪。或者，它们可以是来自实验性服务但实际面向客户的工作负载，并且具有在必要时切换以隐藏该服务的功能。

这些工作负载可以部署为一个区域和一个可用区。

监控资源

我们将进行简单的监控，看看服务主页是否会返回 HTTP 200 OK 状态。出现问题后，我们的行动手册会说明，可以使用实例中的日志来确定根本原因。

适应需求的变化

我们拥有关于常见硬件故障、紧急软件更新和其他破坏性更改的行动手册。

实施变更

我们将使用 AWS CloudFormation 来定义我们的“基础设施即代码”，特别是在发生故障时加快重建速度。

软件更新会使用运行手册手动执行，安装和重新启动服务需要停机。如果在部署过程中出现问题，运行手册会介绍如何回滚到早期版本。

运维和开发团队将使用日志分析来更正全部错误，并且在确定修复工作的优先级并完成修复工作以后才部署更正。

备份数据

我们将使用供应商或专用的备份解决方案，按照运行手册，将加密备份数据发送给 Amazon S3。我们将按照运行手册，通过定期还原数据并确保能使用它们，测试备份数据能正常使用。我们会在 Amazon S3 对象上启用版本控制，并取消备份删除权限。我们会根据要求，使用 Amazon S3 存储桶生命周期策略，进行存档或永久删除操作。

构建弹性

工作负载会部署为一个区域和一个可用区。我们会在单个实例中部署应用程序，包括数据库。

测试弹性

新软件的部署管道已安排好，并进行了一些单元测试，主要是组装工作负载的白箱/黑箱测试。

灾难恢复 (DR) 计划

如果发生了故障，我们会等待故障结束，选择通过运行手册，使用 DNS 修改将请求路由到静态网站。具体的恢复时间取决于可部署基础设施的速度以及数据库还原到最近备份的速度。按照运行手册，如果某个可用区发生了故障，可在同一可用区或其他可用区中实施部署。

可用性设计目标

我们用 30 分钟了解并决定执行恢复，用 10 分钟在 AWS CloudFormation 中部署整个堆栈，假设我们部署到一个新的可用区，并假设数据库可以在 30 分钟内还原。这就意味着要从故障中恢复，大约需要 70 分钟的时间。假设每季度发生一次故障，预计全年的受影响时间为 280 分钟，也就是 4 小时 40 分钟。

这意味着可用性上限是 99.9%。实际可用性还取决于实际故障率、故障持续时间以及每次故障的实际恢复速度。在这种架构中，应用程序需要离线才能更新（每年预计 24 小时：每年六次更改，每次四小时），还要考虑实际事件。因此，参考白皮书前面的应用程序可用性表，我们看到 可用性设计目标 是 99%。

总结