针对恢复进行设计
 工作负载必须能够预测大多数故障并从中进行恢复，而不管故障的规模大小，同时对用户体验和业务目标造成的干扰最小。 |
|---|
即使复原能力很高的系统也需要在体系结构设计和工作负载操作中采用灾难准备方法。 在数据层上，应该有一些策略可以在出现损坏的情况下修复工作负载状态。
示例场景
Contoso 目前在本地 SQL Server 数据库上托管大量数据，最近已使用 Azure 服务实现其数据分析解决方案的现代化。
新的分析解决方案利用 Azure Analysis Services、Azure 数据工厂、Azure Synapse Analytics、Power BI 和 Azure 虚拟机。 解决方案的所有用户都是内部用户。 在考虑解决方案的可用性要求后，团队决定在单个区域中实施该解决方案。
数据通过 Azure 数据工厂引入，并在保存到 Analysis Services 存储之前进行处理。 在该过程中需要一个旧 Windows 进程，其已部署到云中的 VM。
为灾难做好准备
事先构建、测试和记录与协商的恢复目标一致的恢复计划。 除了整个系统之外，计划还必须涵盖所有组件。
明确定义的过程可实现快速恢复，以防对企业的财务和声誉造成负面影响。 定期进行恢复演练可测试恢复系统组件、数据的过程以及故障转移和故障回复步骤，以避免在时间和数据完整性是衡量成功与否的两个关键因素时出现混乱。
Contoso 的挑战
- 解决方案仅在内部使用，不被视为任务关键型解决方案。 因此，工作负载团队和业务利益干系人一致认为，在部署解决方案的 Azure 区域丢失或整个解决方案因某个其他原因变得不可用这两种出现概率较低的情况下，在次要区域中重新构建解决方案是一种很好的恢复模式。
- 工作负载团队在其灾难恢复计划中描述了如何在另一个区域构建解决方案，但还没有机会执行完整的灾难恢复演练。
应用方法和结果
- 遇到区域性中断后，灾难恢复响应团队能够按照灾难恢复计划的说明在另一个区域中重新部署分析解决方案。
- 团队发现灾难恢复计划与部署解决方案所需的一些操作之间存在差距，因而更新了该计划，以提高未来的恢复效率。
- 工作负载团队和利益干系人同意加速计划内灾难恢复测试，以确保更新后的计划具有更高的恢复效率。
解决有状态数据
确保可以修复恢复目标内所有有状态组件的数据。
备份对于使用受信任的恢复点（如上次已知的良好状态）将系统恢复为工作状态至关重要。
不可变和事务一致的备份可确保数据无法更改，而且还原的数据不会损坏。
Contoso 的挑战
- 工作负载团队决定将 SQL 数据库移到 Azure，以减少分析处理时间。 VM 在分析过程中大量使用其中的一个数据库，因此团队需要确保能够以尽可能低的 RPO 恢复数据库状态。
应用方法和结果
- 由于数据库很大，每个都超过 4 TB，短期内无法迁移到 Azure SQL 数据库。 因此，团队决定迁移到运行 SQL Server 2022 的 Azure VM。
- 团队决定对所有数据库（包括关键数据库，例如 VM 使用的数据库）使用自动备份功能。
- 对于关键数据库，团队计划使用自动备份功能以及托管实例链接功能主动将数据库复制到 Azure SQL 托管实例。
在设计中实现自动自行修复功能
自行修复功能是一种机制，允许工作负载的组件通过恢复受影响的组件以及根据需要故障转移到冗余基础结构来自动解决问题。 使用设计模式可通过自行修复机制为工作负载增加复原能力。
自行修复自动化有助于降低人为干预等外部因素的风险，并缩短故障维修服务周期。
Contoso 的挑战
- 引入数据时从 Azure 数据工厂调用的 Windows 进程最初部署到多个 VM，以提高可用性。
- 在某些情况下，旧 Windows 进程崩溃，需要重启 VM。 虽然总体处理时间受到的影响最小（由于冗余级别），但团队希望实施一种解决方案来自动检测故障和恢复。
应用方法和结果
- 团队决定实施 Azure 虚拟机规模集解决方案，该解决方案被配置为部署应用程序运行状况扩展，以持续监视 VM 进程的运行状况。
- 启用自动实例修复后，规模集现在可以通过重启 VM 或基于同一映像创建新实例来修复组件。