有关设计可靠性测试策略的建议

适用于此 Azure Well-Architected 框架可靠性清单建议：

本指南介绍有关设计可靠性测试策略以验证和优化工作负载可靠性的建议。 可靠性测试侧重于工作负载的复原能力和可用性，特别是设计解决方案时确定的关键流。 本指南提供特定于故障注入和混沌工程的常规测试指南和指导。

定义

关键设计策略

常规测试指南

• 定期执行测试以验证现有阈值、目标和假设。 当工作负荷发生重大更改时，请运行定期测试。 在测试和过渡环境中执行大多数测试。 针对生产系统运行一部分测试也很有用。 规划关键测试环境与生产环境的一对一奇偶校验。

• 自动执行测试，以帮助确保一致的测试覆盖范围和可重现性。 请将常见的测试任务自动化，并将这些任务集成到生成过程中。 手动测试软件很繁琐且容易出错，但你可以执行手动探索性测试。 如果需要开发自动测试，请使用手动测试来确定要开发的测试的范围。

• 采用左移测试方法，在开发周期的早期执行复原能力和可用性测试。

• 调整简单的文档格式，以便每个人都可以轻松了解每个常规测试的过程和结果。

• 与相应的团队（如运营团队、技术领导、业务利益干系人和灾难恢复利益干系人）共享记录的结果。 结果应指示可靠性目标的优化，例如服务级别目标 (SLO) 、服务级别协议 (SLA) 、恢复时间目标 (RTO) ，以及恢复点目标 (RPO) 。

• 为备份创建定期测试节奏。 将数据还原到独立的系统，以帮助确保备份有效且还原正常运行。

• 记录恢复时间指标并与灾难恢复利益干系人共享，以确保恢复预期合适。

• 使用行业标准 部署测试过程 来帮助确保部署过程自动化、可预测且高效。

• 测试工作负载承受暂时性故障的能力。 有关详细信息，请参阅 处理暂时性故障的建议。

• 测试工作负载响应负载模式更改和使用高峰的能力。 使用此信息可帮助你测试 缩放策略。 有关负载和压力测试的信息，请参阅 测试建议。

• 使用故障注入测试工作负载如何处理依赖服务或其他依赖项中的故障。

• 测试和验证 自我修复和自我保护设计 如何响应故障。 测试自动和手动恢复操作。

• 测试 灾难恢复计划 以响应灾难性故障和其他重大事件。

• 使用故障注入测试工作负载正常降级和最小化组件故障的爆炸半径的能力。

利用计划内和计划外中断

当工作负荷由于计划内维护或计划外中断而脱机时，你有一个独特的机会执行测试并提高对工作负载的理解。 以下部分提供了针对每个方案的建议。

计划内维护

如果计划内有更新或修补程序的维护时段，则可以测试维护工作不涉及的组件和流。 执行测试，而不会有意外降级工作负载或完全脱机的潜在风险。 如果在维护时段内有足够的时间，还可以在维护工作完成后测试维护中涉及的组件和流。

计划外中断

利用每个中断事件的机会，通过执行按优先级排序的步骤，详细了解工作负载并提高其复原能力：

• 让客户重新联机工作负荷。 为此，可以针对此问题执行解决方法、解决问题或启动恢复过程。

• 确定中断的根本原因并解决它。 如果可以在调查过程中修复根本原因，请记录根本原因以及修复它所采取的措施。 如果此问题需要在以后进行额外的维护时段，请确保缓解措施可以通过全面测试它来处理预期的负载。 确保已设置足够的监视以涵盖缓解措施。

• 如果适用，请在工作负载中的所有组件中查找可能受类似问题影响的相同问题或配置弱点。 利用此机会主动处理这些组件。 查阅事件历史记录，以检测工作负载中类似问题的模式。

• 使用你的发现来改进测试策略。 通过直接测试相同的故障，确保已成功解决根本原因和类似问题。

故障注入和混沌工程指南

故障注入测试遵循混沌工程的原则，强调工作负载对组件故障做出反应的能力。 在预生产和生产环境中执行错误注入测试。 将测试应用于基础结构层和应用程序层。 应用你学到的 关于执行故障模式分析的建议 的信息，以确保仅测试你优先考虑的故障，并且你具有解决故障的缓解策略。 混沌工程的关键准则是：

• 主动。 不要等待失败发生。 尝试通过执行混沌试验来预测故障，以便在问题影响生产环境之前发现并解决问题。

• 接纳故障。 接受并学习系统中发生的故障。 将故障视为复杂系统的自然组成部分，并利用它们作为学习和提高系统可靠性的机会。

• 中断系统。 故意将故障或压力注入系统以测试其复原能力。 模拟实际故障或中断，以测试和改进工作负载的恢复功能。

• 及早识别并解决单点故障。 在测试时，请查阅并更新 故障模式分析 ，以验证并解决文档中的错误。 应用冗余和分段等可靠性方法，以提高工作负载的可用性并最大程度地减少停机时间。

• 安装防护软件并采取适度的缓解措施。 实施安全措施（如断路器模式或限制模式）以提高可用性。 实现正常降级方法，以便在故障期间实现业务连续性。

• 最大程度减小冲击半径。 实施故障隔离策略，以帮助确保即使发生故障，其范围也有限。 系统继续正常运行，对客户的影响最小。

• 构建抗干扰性。 使用混沌工程试验来提高工作负载防止故障并从故障中恢复的能力。

混沌工程是工作负载团队文化和持续实践不可或缺的一部分，而不是应对单个中断的短期战术工作。 设计混沌试验时，请遵循以下标准方法：

1. 从一个假设开始。 每个试验都应有一个明确的目标，例如测试给定流承受特定组件损失的能力。
2. 度量基准行为。 确保给定试验中涉及的流和组件具有一致的可靠性和性能指标，以便在运行试验时与降级状态进行比较。
3. 注入故障或错误。 试验应有意针对可以快速恢复的特定组件，并且你应该对故障注入将产生的影响有一个明智的预期，以帮助控制实验的爆破半径。
4. 监视产生的行为。 收集试验针对的各个流组件和端到端流行为的遥测数据，以正确了解故障的影响。 将收集的指标与基线指标进行比较，以全面了解故障注入结果。
5. 记录流程和观察。 保留试验的详细记录将为将来的工作负载设计决策提供信息，确保解决随时间推移而揭示的差距。
6. 识别并处理结果。 规划可添加到工作负载积压工作中的修正步骤，作为改进。 确保按照与其他部署相同的流程，在非生产环境中评审和测试设计改进计划。

定期验证流程、体系结构选择和代码，以快速检测技术债务、集成新技术并适应不断变化的要求。

执行故障注入试验时，可以：

• 确认监视已到位并设置了警报。
• 验证分配直接负责的个人 (DRI) 以取得事件的所有权的过程。
• 确保文档和调查过程是最新的。

集成以下建议和注意事项来优化混沌测试策略：

• 质疑系统假设。 通过测试，可以尝试提高工作负载和工作负载设计策略的复原能力。 寻找机会，将故障注入到根据过去的经验认为可靠的组件和流中。 在新的工作负载中，它们可能不可靠。

• 验证更改，例如拓扑、平台和资源。 如果不进行全面的测试（包括故障注入测试），则更改后，可能会对工作负载有不完整的了解。 例如，你可能无意中引入了新的依赖项，或者以不立即可见的方式破坏了现有依赖项。

• 使用 SLA 缓冲区。 限制混沌测试，使其保持在 SLA 范围内，避免中断对信誉或财务造成的潜在影响。 流和组件恢复目标有助于定义测试的范围。

• 建立错误预算作为对混乱和故障注入的投资。 错误预算是实现 100% 的 SLO 和达成一致的 SLO 之间的差值。

• 如果试验超出范围，请停止试验。 混沌实验的结果应该是未知结果。 努力在收集大量结果数据和影响尽可能少的生产用户之间取得平衡。

• 与开发团队密切合作，确保注入的故障的相关性。 使用过去的事件或问题作为指导。 检查依赖项并在删除这些依赖项时评估结果。

• 识别并记录工作负载中不同组件之间以前未发现的依赖项，这些依赖项通过混沌测试显示。

• 根据需要调整恢复计划，以考虑在混沌测试期间发现的依赖项。

• 使用试验和测试的结果作为新试验和测试的基础。 出现意外行为时，新的测试可能会直接针对这些行为，并为你提供为这些行为设计修正策略的机会。

权衡：生产中的故障注入测试可能会造成中断，并可能导致停机。 就这种可能性与利益干系人保持透明，并确保你已制定安全措施来终止试验和回滚计划，以快速扭转引入的故障。 若要防止生产中出现意外中断，请确保规划足够的 冗余 ，并且利益干系人了解成本权衡。

Azure 便利化

Azure Test Plans 是一种易于使用、基于浏览器的测试管理解决方案，它提供计划内手动测试、用户验收测试、探索测试以及从利益干系人那里收集反馈所需的所有功能。

Azure Chaos Studio 是一项托管服务，它使用混沌工程来帮助度量、了解和改进云应用程序和服务的复原能力。 Azure Chaos Studio 在 Ignite 2023 上正式发布，并具有许多功能，可帮助你开始使用 Azure 基础结构为应用程序进行故障注入和复原能力测试。

相关链接

• Azure 应用程序的备份和灾难恢复
• 可靠性测试清单
• 测试应用程序的可用性和复原能力

可靠性清单

请参阅完整的一组建议。