有关设计可靠性测试策略的建议
适用于此 Power Platform Well-Architected 可靠性清单建议：
| RE:06 | 通过在测试和生产环境中应用混沌工程原则来测试复原能力和可用性场景。 使用测试通过执行主动故障和模拟负载测试来确保正常降级实现和缩放策略是有效的。 |
|---|
本指南介绍有关设计可靠性测试策略以验证和优化工作负荷可靠性的建议。 可靠性测试着重于工作负荷的复原能力和可用性，特别是设计解决方案时确定的关键流。 本指南提供特定于故障注入和混沌工程的常规测试指南和指导。
定义
| 术语 | 定义 |
|---|---|
| 空闲情况 | 应用程序工作负荷在不显著停机的情况下以正常状态运行的时间量。 |
| 混沌工程 | 使应用程序和服务受到实际压力和故障的做法。 混沌工程的目标是生成和验证对不可靠条件和缺少依赖项的复原能力。 |
| 故障注入 | 向系统引入错误以测试系统复原能力的行为。 |
| 可恢复性 | 复原能力的同义词。 |
| 复原能力 | 应用程序工作负荷能够承受故障模式并从故障模式中恢复。 |
关键设计策略
若要确保您的工作负荷满足其可靠性目标并且可以正常处理故障，执行测试至关重要。 故障注入是一种测试类型，有意向系统中引入故障或压力以模拟真实场景。 通过使用故障注入和混沌工程技术，您可以提前发现并修复问题，以免它们影响您的生产环境。 本部分提供有关对工作负荷的测试、故障注入和混沌工程的指南。
常规测试指南
定期执行测试以验证现有阈值、目标和假设。 当工作负荷发生重大更改时，请运行定期测试。 在测试和过渡环境中执行大多数测试。 针对生产系统运行一部分测试也很有用。
自动执行测试，以帮助确保一致的测试覆盖范围和可重现性。 自动执行常见测试任务，并将其集成到生成流程中。 手动测试软件很繁琐且容易出错，但您可以执行手动探索性测试。 如果需要开发自动测试，请使用手动测试来确定要开发的测试范围。
采用左移测试方法，在开发周期的早期执行复原能力和可用性测试。
调整简单的文档格式，以便每个人都可以轻松了解每个常规测试的流程和结果。
与相应的团队（例如运营团队、技术领导、业务利益干系人和灾难恢复利益干系人）共享记录的结果。 结果应指示可靠性目标的优化，例如服务级别目标 (SLO)、服务级别协议 (SLA)、恢复时间目标 (RTO)，以及恢复点目标 (RPO)。
为备份创建定期测试节奏。 将数据还原到独立的系统，以帮助确保备份有效且还原正常运行。
记录恢复时间指标并与灾难恢复利益干系人共享，以确保恢复预期合适。
使用行业标准部署测试过程来帮助确保部署流程自动化、可预测且高效。
测试工作负荷承受暂时性故障的能力。 有关详细信息，请参阅有关处理暂时性故障的建议。
使用故障注入，测试工作负荷如何处理依赖服务或其他依赖项中的故障。
测试灾难恢复计划以响应灾难性故障和其他重大事件。
使用故障注入测试工作负荷正常降级和最小化组件故障的爆炸半径的能力。
利用计划内和计划外中断
当工作负荷由于计划内维护或计划外中断而脱机时，您有一个独特的机会执行测试并提高对工作负荷的理解。 以下部分提供了针对每个场景的建议。
计划维护
当有更新或修补程序的计划内维护时段时，可以测试维护工作不涉及的组件和流。 执行测试，而不会有意外降级工作负荷或完全脱机的潜在风险。 如果在维护时段内有足够的时间，还可以在维护工作完成后测试维护中涉及的组件和流。
计划外中断
利用每个中断事件的机会，通过执行按优先级排序的步骤，详细了解工作负荷并提高其复原能力：
让用户重新联机工作负荷。 您可能需要针对此问题执行解决方法、解决问题或启动恢复流程。
确定中断的根本原因并解决它。 如果可以在调查过程中修复根本原因，请记录根本原因以及修复它所采取的措施。 如果问题需要稍后再使用另一个维护时段，请确保缓解措施可以通过彻底测试来处理预期的负载。 确保已设置足够的监视以涵盖缓解措施。
如果适用，请在工作负荷中的所有组件中查找可能受类似问题影响的相同问题或配置弱点。 利用此机会主动处理这些组件。 查阅事件历史记录，以检测工作负荷中类似问题的模式。
使用您的发现来改进测试策略。 通过直接测试相同的故障，确保已成功解决根本原因和类似问题。
故障注入和混沌工程指南
故障注入测试遵循混沌工程的原则，强调工作负荷对组件故障做出反应的能力。 在预生产和生产环境中执行故障注入测试。 应用您从执行故障模式分析中学到的信息，以确保仅测试您优先考虑的故障，并且您具有解决故障的缓解策略。
混沌工程的关键准则是：
主动。 不要等待故障发生。 尝试通过执行混沌试验来预测故障，以便在问题影响生产环境之前发现并解决问题。
接纳故障。 接受系统中发生的故障并吸取经验教训。 将故障视为复杂系统的自然组成部分，并利用它们作为学习和提高系统可靠性的机会。
中断系统。 故意将故障或压力注入系统以测试其复原能力。 模拟实际故障或中断，以测试和改进工作负荷的恢复功能。
生成抗干扰性。 使用混沌工程试验来提高工作负荷防止故障并从故障中恢复的能力。
混沌工程是工作负荷团队文化和持续实践不可或缺的一部分，而不是应对单个中断的短期战术工作。 当设计混沌试验时，请遵循以下标准方法：
从一个假设开始。 每个试验都应有一个明确的目标，例如测试流承受特定组件损失的能力。
度量基准行为。 确保试验中涉及的流和组件具有一致的可靠性和性能指标，以便在运行试验时与降级状态进行比较。
注入一个或多个故障。 试验应有意针对可以快速恢复的特定组件，并且您应该对故障注入将产生的影响有一个明智的预期，以帮助控制试验的爆炸半径。
监视产生的行为。 收集试验针对的各个流组件和端到端流行为的遥测数据，以正确了解故障的影响。 将收集的指标与基线指标进行比较，以全面了解故障注入结果。
记录流程和观察。 保留试验的详细记录将为将来的工作负荷设计决策提供信息，确保解决随时间推移而出现的漏洞。
识别并处理结果。 计划可添加到工作负荷积压工作中的修正步骤作为改进。 确保按照与其他部署相同的流程，在非生产环境中评审和测试设计改进计划。
定期验证流程、体系结构选择和代码，以快速检测技术债务、集成新技术并适应不断变化的要求。
当执行故障注入试验时，您可以：
确认监视已到位并设置了警报。
验证分配直接负责的个人 (DRI) 以取得事件的所有权的流程。
确保文档和调查流程是最新的。
集成以下建议和注意事项来优化混沌测试策略：
质询系统假设。 通过测试，您尝试提高工作负荷的复原能力和工作负荷设计策略。 寻找机会，将故障注入到根据过去的经验认为可靠的组件和流中。 在新的工作负荷中，它们可能不可靠。
验证更改。 如果不进行全面的测试（包括故障注入测试），则进行更改后，可能会对工作负荷有不完整的了解。 例如，您可能引入了不立即可见的新依赖项。
使用 SLA 缓冲区。 限制混沌测试，使其保持在 SLA 范围内，避免中断造成潜在的不利影响。 流和组件恢复目标有助于定义测试的范围。
建立错误预算作为对混乱和故障注入的投资。 错误预算是实现 100% 的 SLO 和达成一致的 SLO 之间的差值。
如果试验超出范围，请停止试验。 混沌实验的结果应该是未知结果。 努力在收集大量结果数据和影响尽可能少的生产用户之间取得平衡。
与开发团队密切合作，确保注入的故障的相关性。 使用过去的事件或问题作为指导。 检查依赖项并在删除这些依赖项时评估结果。
识别并记录工作负荷中不同组件之间的以前未发现的依赖项，这些依赖项通过混沌测试显示。
根据需要调整恢复计划，以考虑在混沌测试期间发现的依赖项。
使用试验和测试的结果作为新试验和测试的基础。 当出现意外行为时，新的测试可能会直接针对这些行为，并为您提供为这些行为设计修正策略的机会。
权衡：在生产中进行故障注入测试会造成干扰，并可能导致停机。 就这种可能性与利益干系人保持透明，并确保您已制定安全措施来终止试验和回滚计划，以快速逆转引入的故障。
Power Platform 便利化
您可以在 Power Automate 中使用静态结果来返回固定结果，以测试工作负载。
Power Apps 测试引擎（预览版）是一个 Power Platform CLI 组件，您可以用它在 Power Apps 中测试独立的画布应用程序。
Azure Test Plans 是一种易于使用、基于浏览器的测试管理解决方案，它提供计划内手动测试、用户验收测试、探索性测试以及从利益干系人那里收集反馈所需的所有功能。
如果您的工作负荷包括 Azure 资源，您可以使用 Azure Chaos Studio，它是一项托管服务，使用混沌工程来帮助度量、了解和改进云应用程序和服务的复原能力。
如果您的工作负载包含 Microsoft Copilot Studio 代理，您可以使用 Power CAT Copilot Studio 工具包配置代理和测试。 通过针对 Copilot Studio 应用程序接口（Direct Line）运行单个测试，根据预期结果对代理响应进行评估。
可靠性清单
请参考整套建议。