你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
设计可靠性测试策略的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：08 | 通过在测试和生产环境中应用混沌工程原则来测试复原能力和可用性方案。 使用测试来确保正常降级实现和缩放策略通过执行主动故障和模拟负载测试有效。 |
|---|
本指南介绍了设计可靠性测试策略以验证和优化工作负荷可靠性的建议。 可靠性测试侧重于工作负载的复原能力和可用性，特别是在设计解决方案时确定的关键流。 本指南提供特定于故障注入和混乱工程的常规测试指南和指南。
定义
| 术语 | 定义 |
|---|---|
| 可用性 | 应用程序工作负荷在正常状态下运行的时间量，而不会造成重大停机。 |
| 混沌工程 | 将应用程序和服务应用于实际压力和失败的做法。 混乱工程的目标是构建和验证对不可靠条件和缺少依赖项的复原能力。 |
| 故障注入 | 向系统引入错误以测试系统的复原能力的行为。 |
| 可恢复性 | 复原能力的同义词。 |
| 复原 | 应用程序工作负荷能够承受和从故障模式中恢复。 |
关键设计策略
测试可靠性准备
定期执行测试以验证现有阈值、目标和假设。 在工作负载中发生重大更改时，请定期运行测试。 在测试和过渡环境中执行大多数测试。 针对生产系统运行一部分测试也会很有帮助。 使用生产环境规划关键测试环境的一对一奇偶校验。
自动执行测试，以帮助确保一致的测试覆盖率和可重现性。 请将常见的测试任务自动化，并将这些任务集成到生成过程中。 手动测试软件很繁琐且容易出错，但你可以进行手动探索测试。 对于需要开发自动测试的情况，请使用手动测试来确定要开发的测试的范围。
采用左移测试方法，在开发周期早期执行复原和可用性测试。
改编简单的文档格式，以便每个人都可以轻松了解每个常规测试结果的过程和结果。
与相应团队（如运营团队、技术领导、业务利益干系人和灾难恢复利益干系人）共享记录的结果。 结果应告知可靠性目标的优化，例如服务级别目标（SLO）、服务级别协议（SLA）、恢复时间目标（RTO）和恢复点目标（RPO）。
为备份创建常规测试节奏。 将数据还原到隔离的系统，以帮助确保备份有效且还原正常运行。
与灾难恢复利益干系人记录和共享恢复时间指标，以确保对恢复的预期是适当的。
使用行业标准 部署测试过程 来帮助确保你拥有自动化、可预测且高效的部署过程。
测试工作负荷承受暂时性故障的能力。 有关详细信息，请参阅 处理暂时性故障的建议。
测试工作负荷响应负载模式更改和使用量高峰的能力。 使用此信息可帮助你测试 缩放策略。 有关负载和压力测试的信息，请参阅 测试建议。
使用故障注入测试工作负荷如何处理依赖服务或其他依赖项中的故障。
测试和验证自我 修复和自我保护设计 如何响应故障。 测试自动化和手动恢复操作。
测试灾难恢复计划，以响应灾难性故障和其他重大事件。
测试工作负荷正常降级的能力，并使用故障注入将组件故障的爆破半径降到最低。
利用计划内和计划外中断
当工作负荷因计划内维护或计划外中断而脱机时，你有机会执行测试并提高对工作负荷的理解。 以下各部分针对每个方案提供建议。
计划内维护
为更新或修补程序计划内维护时段时，可以测试维护工作中未涉及的组件和流。 执行测试，而不会意外降低工作负荷或完全脱机的风险。 如果在维护时段内有足够的时间，还可以在维护工作完成后测试维护中涉及的组件和流。
计划外中断
使用每个中断事件作为一个机会，通过执行以下步骤（按优先级排序）来了解有关工作负荷的详细信息并改进其复原能力：
让客户重新联机工作负载。 为此，可以针对此问题执行解决方法、解决问题或启动恢复过程。
确定中断的根本原因并解决中断问题。 如果在调查过程中可以修复根本原因，请记录根本原因和修复它所采取的措施。 如果问题需要在以后再执行一个维护时段，请确保缓解措施可以通过全面测试来处理预期的负载。 确保已设置足够的监视来涵盖缓解措施。
如果适用，请在工作负荷中的所有组件中查找可能受类似问题影响的相同问题或配置弱点。 使用此机会主动解决这些组件的问题。 咨询事件历史记录，以检测工作负载中类似问题的模式。
使用你的发现来改进测试策略。 通过直接测试相同的失败，确保已成功解决根本原因和类似问题。
使用故障注入和混乱工程
故障注入测试遵循混乱工程的原则，突出工作负荷对组件故障做出反应的能力。 在预生产和生产环境中执行故障注入测试。 将测试应用于基础结构和应用程序层。 应用你学习 的建议来执行故障模式分析 的信息，以确保仅测试你确定优先级的错误，并且你具有解决故障的缓解策略。 混乱工程的主要准则包括：
主动。 不要等待失败发生。 尝试通过执行混沌试验来发现和修复故障，然后再影响生产环境。
接纳故障。 接受并了解系统中发生的故障。 将故障视为复杂系统的自然组成部分，并将它们用作学习和改进系统可靠性的机会。
中断系统。 故意将故障或压力注入系统以测试其复原能力。 模拟实际故障或中断，以测试和改进工作负荷的恢复功能。
及早识别并解决单点故障。 在测试时，请查阅并更新 失败模式分析 ，以验证和解决文档中的错误。 应用可靠性方法（例如冗余和分段），以提高工作负荷的可用性并最大程度地减少停机时间。
安装防护软件并采取适度的缓解措施。 实施安全措施（如断路器模式或限制模式），以提高可用性。 实现正常降级方法，以便在故障期间实现业务连续性。
最大程度减小冲击半径。 实施故障隔离策略，以帮助确保即使发生故障，其范围也会受到限制。 系统在对客户的影响最小的情况下继续正常运行。
构建抗干扰性。 使用混沌工程试验来提高工作负荷防止和恢复故障的能力。
混沌工程是工作负荷团队文化不可或缺的一部分，也是持续的做法，而不是针对单个中断的短期战术工作。 设计混沌试验时，请遵循此标准方法：
- 从一个假设开始。 每个实验都应有一个明确的目标，例如测试给定流承受特定组件的损失的能力。
- 度量基准行为。 确保给定试验中涉及的流和组件具有一致的可靠性和性能指标，以便在运行试验时与降级状态进行比较。
- 注入故障或错误。 试验应有意将可快速恢复的特定组件作为目标，你应该对故障注入会导致的影响有一个明智的期望，以帮助控制实验的爆破半径。
- 监视产生的行为。 收集有关单个流组件和端到端流行为的遥测数据，试验旨在正确了解故障的影响。 将收集的指标与基线指标进行比较，了解故障注入结果的完整情况。
- 记录流程和观察。 保留试验的详细记录将告知有关工作负荷设计的未来决策，确保解决随时间推移所揭示的差距。
- 识别并处理结果。 规划可添加到工作负荷积压工作中的修正步骤，作为改进。 确保根据与其他部署相同的流程在非生产环境中审查和测试设计改进计划。
定期验证流程、体系结构选择和代码，以快速检测技术债务、集成新技术并适应不断变化的要求。
执行错误注入试验时，可以：
- 确认监视已到位，并设置警报。
- 验证分配直接负责的个人（DRI）以拥有事件的所有权的过程。
- 确保文档和调查过程是最新的。
集成以下建议和注意事项以优化混沌测试策略：
质疑系统假设。 通过测试，可以尝试提高工作负荷和工作负荷设计策略的复原能力。 寻找在假设的组件和流中注入故障的机会，这些组件和流基于过去的体验可靠。 它们可能无法在新工作负载中可靠。
验证更改，例如拓扑、平台和资源。 如果不进行彻底的测试（包括故障注入测试），则更改后，工作负荷的图片可能不完整。 例如，你可能会无意中引入新的依赖项，或者以不立即明显的方式破坏现有依赖项。
使用 SLA 缓冲区。 限制混乱测试，使其保留在 SLA 中，避免中断的潜在信誉或财务影响。 流和组件恢复目标有助于定义测试的范围。
建立错误预算作为对混乱和故障注入的投资。 错误预算是实现 SLO 的 100% 与实现 SLO 商定的差异。
如果试验超出范围，请停止试验。 混沌实验的结果应该是未知结果。 努力在收集大量结果数据和影响尽可能少的生产用户之间取得平衡。
与开发团队密切合作，确保注入失败的相关性。 使用过去的事件或问题作为指导。 检查依赖项，并在删除这些依赖项时评估结果。
识别并记录工作负荷中通过混沌测试显示的不同组件之间的以前未发现依赖项。
根据需要调整恢复计划，以考虑在混沌测试期间发现的依赖项。
使用试验和测试的结果作为新试验和测试的基础。 出现意外行为时，新测试可能会直接针对这些行为，并为你提供设计修正策略的机会。
权衡：生产中的故障注入测试可能会造成中断，并可能导致停机。 与利益干系人就这种可能性保持透明，并确保你具有终止试验的安全措施，并回滚计划，以快速扭转引入的故障。 若要防止生产中的意外中断，请确保规划足够的 冗余 ，并确保利益干系人了解成本权衡。
Azure 便利化
Azure 测试计划 是一种易于使用、基于浏览器的测试管理解决方案，提供计划手动测试、用户验收测试、探索性测试以及收集利益干系人反馈所需的所有功能。
Azure Chaos Studio 是一项托管服务，它使用混沌工程来帮助度量、了解和改进云应用程序和服务的复原能力。 Azure Chaos Studio 在 Ignite 2023 正式发布，并具有许多功能，可帮助你开始使用 Azure 基础结构对应用程序进行故障注入和复原测试。
相关链接
可靠性清单
请参阅完整的建议集。