设计备份和恢复
Tailwind Traders 等组织需要在他们的任务关键型应用中提供高度的可靠性。 为了实现本地应用所需的可靠性，通常需要购买更多的计算资源，例如服务器和存储。 购买更多的计算资源可以在本地基础结构中构建冗余。
此外，在理想情况下，任何任务关键型应用及其关联数据在发生故障后都能够恢复到故障点，这一点也至关重要。 这种可恢复性通常由备份、还原组件和过程提供。 对于在 Azure 中托管应用的组织或具有混合应用部署的组织而言，还有其他注意事项和选项。
可靠应用包括：
针对组件故障可复原。
具有高可用性，并且能够以正常状态运行，没有显著的故障时间。
若要实现所需的复原能力和高可用性，必须首先定义你的需求。
备注
本模块使用“复原能力”这一术语来描述系统妥善处理故障并且从故障中恢复的能力，包括意外发生的故障和恶意造成的故障。
定义要求
定义需求涉及以下方面：
确定你的业务需求。
构建你的复原计划以满足这些需求。
下表中的注意事项提供了有关此过程的指导。
| 注意事项 | 说明 |
|---|---|
| 你有哪些工作负荷以及它们有哪些用途？ | 从业务逻辑和数据存储要求的角度讲，工作负荷是逻辑上与其他任务截然不同的功能或任务。 对于可用性、可伸缩性、数据一致性和灾难恢复，每个工作负荷可能会有不同的需求。 |
| 工作负荷的使用模式是什么？ | 使用模式可以确定你的需求。 确定关键时期和非关键时期内的需求差异。 为了确保运行时间，请跨多个区域计划冗余，以防一个区域发生故障。 相反，为了将非关键时期的成本降至最低，可以在单个区域中运行应用程序。 |
| 有哪些可用性指标？ | 平均恢复时间 (MTTR) 和平均故障间隔时间 (MTBF) 是通常使用的指标。 MTBF 是指某个组件在两次中断之间按预期方式合理运行的持续时间。 MTTR 是指发生故障后，还原某个组件所需的平均时间。 使用这些指标来确定需要添加冗余的位置，并针对客户确定服务级别协议 (SLA)。 |
| 有哪些恢复指标？ | 恢复时间目标 (RTO) 是指在某一事件后可以接受应用不可用的最长时间。 恢复点目标 (RPO) 是指发生灾难期间可接受数据丢失的最大持续时间。 还要考虑恢复级别目标 (RLO)。 此指标确定恢复的粒度。 换句话说，你是想必须能够恢复服务器场、Web 应用还是只恢复特定项即可。 若要确定这些值，请进行风险评估。 确保你了解组织中故障时间或数据丢失的成本和风险。 |
| 有哪些工作负荷可用性目标？ | 为了帮助确保你的应用体系结构满足业务需求，请为每个工作负荷定义目标 SLA。 除了应用程序依赖关系以外，还应该考虑到满足可用性要求所需的成本与复杂性。 |
| 什么是你的 SLA？ | 在 Azure 中，SLA 描述 Microsoft 在运行时间和连接性方面所做的承诺。 如果针对特定服务的 SLA 为 99.9%，则应该预期该服务在 99.9% 的时间内可用。 |
提示
如果高可用性方案中任何关键组件的 MTTR 超过了系统 RTO，那么系统中的故障可能会导致不可接受的业务中断。 换句话说，你无法在定义的 RTO 内还原系统。
通过回答上述问题，在你的解决方案中为每个工作负荷定义自己的 SLA。 这有助于确保体系结构满足你的业务需求。 例如，如果一个工作负荷需要 99.99% 的正常运行时间，但此工作负荷依赖于SLA 为 99.9% 的服务，则该服务不能是系统中的单一故障点。
定义恢复需求后，可以选择合适的恢复技术。