可靠性测试的体系结构策略

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

可靠性测试在导致中断之前会捕获体系结构弱点。 如果不对故障方案进行故意测试，则无法知道复原模式是否实际工作，或者工作负荷是否在其定义的目标内恢复。

在测试影响可用性的安全风险、使系统不可用的性能问题和限制事件响应的操作差距时，可以增强工作负荷的可靠性。 使用本文中的策略，建立定期测试机制，针对工作负载的失效模式定期验证你的工作负载。 随着体系结构的更改和事件暴露出新的弱点，改进测试。 建立这样的信心：您的工作负载能够承受故障、弹性扩展以满足需求，并在 RTO 和 RPO 目标内恢复，同时建立反馈闭环，从而持续增强系统的可靠性水平。

本文中的关键策略建立在OE:09 测试的架构策略中描述的基础测试实践之上。 首先查看该文章。 本指南中的建议仅限于可靠性方面，重点在于让您确信您的工作负载能够承受故障，并在既定目标范围内恢复。

下表定义了本文中使用的关键可靠性术语。

定义

根据服务类型定义可靠性测试范围

定义可靠性测试的范围时，请考虑你使用的服务的共同责任模型。 每种服务类型（IaaS、PaaS、SaaS）都具有不同的可靠性保证和不同级别的故障处理控制。 将测试重点放在你拥有的可靠性方面。

• 将测试深度与责任相匹配。 对于基础结构服务（IaaS），你的团队拥有最可靠的决策，因此请通过混乱工程和故障注入进行彻底验证。 对于平台（PaaS）和软件（SaaS）服务，提供商管理大部分基础可靠性。 重点关注工作负载如何与这些服务交互，例如它如何处理 PaaS 中的基础设施故障转移、限流、服务降级或负载模式的变化。

• 将混合服务工作负载考虑在内。 当工作负荷跨多个服务类型时，测试职责因组件而异。 你可能会在可用区发生中断期间测试基于 VM 的基础架构组件的故障转移，但对于专为高可用性而设计的 PaaS 数据库，则依赖提供商的保障。 确定这些边界的位置，并确保测试涵盖它们之间的差距。

针对可靠性目标进行端到端测试

可靠性目标（如 SLO、RTO 和 RPO）定义工作负荷在故障条件下的行为方式。 将它们用作贯穿完整关键流程的通过和失败标准，而不只是针对单个组件。

• 验证整个流程的恢复情况。 单个组件可能会在其 RTO 内恢复，但如果下游依赖项也需要恢复，整体恢复时间仍可能超过目标值。 考虑整个流的总恢复时间，包括检测问题的时间和响应时间。

• 使用 SLO 和错误预算定义测试范围。 你的错误预算决定了你可以在故障注入方面进行多少投入。 限制混沌测试以保留在 SLO 中，并使用流恢复目标定义每个测试的边界。

从关键流和故障模式生成可靠性方案

从工作负载中的关键流程以及可能影响这些流程的故障模式开始。 使用 故障模式分析 来确定影响最大的故障方案，并生成测试来验证复原能力和恢复策略。

按影响和可能性确定优先级。 并非每个故障模式都值得相同的测试投资。 首先关注具有最高潜在用户影响和最高发生可能性的方案。 让故障模式分析驱动此优先级。

验证容错和恢复机制

专注于最有可能导致停机或降低用户体验的方案。 使用本部分中的策略生成测试，以验证工作负荷处理故障和有效恢复的能力。

备份和还原

备份和还原测试应验证数据保护方法是否满足恢复目标。

• 制定测试周期。 根据备份配置、数据架构或基础结构更改的频率确定测试还原的频率。 更频繁的更改需要更频繁的还原测试。

• 设置恢复目标。 根据 RPO 和 RTO 目标测量实际还原时间，以确认备份策略满足恢复目标。

• 不要想当然地认为备份是完整的。 备份可能因配置不当而仅备份了你的部分数据。 验证数据完整性和完整性，而不仅仅是还原操作是否成功。

• 隔离测试。 在独立于生产的环境中验证还原，以便在不中断实时工作负荷的情况下运行彻底检查。

暂时性故障

暂时性故障（例如瞬间网络中断、短暂的服务不可用和连接超时）是常见的可靠性风险。 验证您的工作负载能够在不影响用户的情况下应对这些故障。 有关详细信息，请参阅有关处理暂时性故障的建议。

• 专注于你拥有的内容。 如果 SDK 或平台服务自动处理重试和断路器，请测试当这些内置机制耗尽时会发生什么情况，例如所有重试失败或断路器打开时会发生什么情况。

• 验证错误处理配置。 评估工作负荷的故障处理配置。 验证重试策略、断路器阈值和超时值在实际故障条件下是否按预期方式运行。

• 测试暂时性故障和永久性故障之间的边界。 验证当故障持续超过预期阈值时，工作负荷是否正常地从重试行为过渡到回退或降级。

• 将弹性功能导致的瞬时故障考虑在内。 区域冗余和类似的设计通常会在正常故障转移操作期间产生暂时性故障。 例如，区域冗余数据库可能会导致暂时性连接故障，因为流量在中断期间转移到正常的区域。 测试工作负荷是否可以处理这些预期的暂时性故障，而不会对用户造成重大影响。

加载和缩放响应

验证您的工作负载在需求发生变化时能否保持可靠，无论是突然激增还是逐步增长。 有关详细信息，请参阅 缩放策略。 有关负载和压力测试指南，请参阅 测试建议。

• 测试横向扩展和横向缩减。 验证新容量能否足够快地上线，并确保缩容不会丢弃请求或留下孤立资源。

• 考虑到扩缩容延迟。 满足触发缩放的条件并准备好新容量之间始终存在延迟。 确定工作负荷是否可以在该差距期间处理需求，或者是否需要预先预配额外的容量。

依赖项故障

工作负荷可能依赖于直接控制之外的服务，例如第三方 API、托管平台服务或共享内部服务。 验证工作负荷是否处理这些依赖项中的故障，而不会对用户造成重大中断。

• 按关键性对依赖项进行分类。 并非所有依赖项都保证相同的测试投资。 优先测试关键流中缺少内置冗余或回退路径的依赖项。

• 测试每个依赖项的回退行为。 当某个依赖项不可用时，您的工作负载应回退到备用路径或其他处理方式，而不是彻底失败。 确认每个回退机制均能正确触发，并且其他无关功能继续正常工作。

• 考虑到部分故障和级联故障。 依赖项很少以二进制方式失败。 不要只测试完全中断。 涵盖延迟增加、间歇性错误和部分数据可用性。

• 验证隔离效果以及影响范围控制情况。 验证单个依赖项失败是否不会级联到不相关的功能。

自我保存和恢复

验证自我修复和自我保护设计在发生故障时如何响应，包括在无法立即完全恢复的情况下，您的工作负载是否仍可继续以降级方式运行。

• 对自动恢复进行端到端测试。 评估您的运行状况模型，确保其包含适当的检查项。 验证这些检查是否准确检测故障，按预期触发自动修正，并将系统返回到可接受的时间范围内正常状态。

• 验证手动恢复运行手册。 自动恢复不会涵盖每个方案。 在接近真实的条件下测试手动运行手册，以确保操作员能够在压力情况下执行这些手册，并在恢复时间目标内完成。

• 验证正常降级行为。 当某个组件发生故障时，你的工作负载应能够优雅降级，而不是彻底失败。 测试它是否能够在降级模式下运行，例如将请求排队等待人工审核，并且要确认这种降级体验是用户可以接受的。 确认团队知道如何在此状态下操作工作负荷以及如何还原完整功能。

事件和灾难恢复（DR）

发生事件或灾难时，快速检测并有效响应的能力至关重要。 测试计划和流程，确保它们解决灾难性故障和重大事件。 使用专用环境进行 DR 测试，以避免影响生产工作负荷。 有关详细信息，请参阅 灾难恢复计划。

• 验证事件检测机制。 模拟事件，验证监视日志是否捕获必要的信息，以及警报是否适当触发。 例如，测试请求失败率上升会被多快检测到，以及监控数据的采样频率。

• 测试事件管理过程。 确认团队可以有效地遵循事件响应过程。 有关详细信息，请参阅 事件响应。

• 测试完整故障转移和故障恢复。 单独测试各个部分，可能会遗漏那些只会在真实切换过程中才暴露出来的协同故障。 验证完整的故障转移顺序，包括 DNS 切换、还原备份和数据复制一致性以及客户端重新连接。 此外，还应测试故障切回到主部署，因为这通常比首次切换更复杂。

• 验证故障转移环境中的容量。 确认您的故障转移环境具备足够的预先配置容量，能够在发生故障转移后立即承接流量，而不至于因负载过大而崩溃。 测试环境是否可以在缩放机制激活和验证缩放方法时维持操作。 有关详细信息，请参阅 负载和缩放响应。

• 对照目标进行衡量。 如果 DR 测试未达到 RTO 或 RPO 要求，请分析其中的差距，并据此更新 DR 计划。

• 验证人员和流程。 DR 测试应验证通信渠道，确认操作员具备执行恢复流程所需的访问权限和操作权限，并确保他们在压力下也能快速找到 DR 专用运行手册。

通过桌面演练测试和评估你的计划

桌面推演可帮助你在真实事故暴露这些漏洞之前，发现可靠性测试中的缺口。 通过模拟团队的故障方案，可以识别未经测试的条件，并验证响应过程是否按预期工作。

• 模拟现实事件。 推演一个故障场景，例如区域性中断或部署损坏，并让你的团队描述他们将采取哪些步骤来检测、响应并从中恢复。 这些讨论通常会揭示有关尚未通过测试验证的系统行为的假设。

• 将发现结果转换为测试用例。 利用演练过程中暴露出的缺口和未知问题，设计新的可靠性测试。 如果团队发现，没有人知道某个特定依赖项发生故障时工作负载会如何表现，那么这种情况就应该纳入测试策略。

充分利用计划内和计划外停机时段

当工作负荷因计划内维护或计划外中断而脱机时，你有机会执行测试并提高对工作负荷的理解。

计划内维护

在进行更新或打补丁的维护窗口期间，测试未涉及此次维护工作的组件和流程。 您可以运行测试，而不必担心会意外导致工作负载性能下降或下线。 如果有足够的时间，请在完成工作后测试维护中涉及的组件。

计划外中断

每个计划外中断都是增强可靠性测试策略的机会。 还原服务并完成事件后评审后，使用发现改进测试。

• 测试缓解措施。 如果应用了解决方法或临时修复，请验证它是否可以在永久修复到位之前处理预期的负载。

• 扫描类似的弱点。 查看其他组件，了解导致中断的相同配置或设计模式。 在这些组件以同样的方式失效之前，为它们添加测试。

组合不同类型的测试

在一起运行不同类型的测试时，可以揭示在隔离运行每个测试时不可见的可靠性问题。 工作负荷可能会在正常情况下处理特定负载，但相同的负载会在引入错误时导致故障。

• 重复使用现有的测试基础结构。 如果已有用于负载测试的基础结构和测试工具，请使用它同时运行混沌测试。 将负载和故障注入合并在同一测试运行中会显示工作负荷在现实条件下的行为方式，即需求和故障同时发生。

• 先从非生产环境开始。 在风险较低的环境中开始可靠性测试，你可以在其中安全地探索故障模式。 只有在你已从非生产环境中充分获取洞察，并且已具备将影响范围控制在最小、能够快速回滚的保障措施后，才应转入生产环境测试。

使用故障注入和混沌工程

故障注入和混沌工程通过故意引入故障和观察响应，帮助你增强对工作负荷复原能力的信心。 在运行试验之前，请确保已准备好缓解策略。

• 定期运行混沌试验。 评估 测试范围。 向你认为可靠的组件和流程中注入故障。 随着体系结构的变化，新的故障模式出现，以前的假设可能不再存在。 定期运行试验以捕获回归、验证新依赖项并确认最近的更改未引入弱点。

• 利用失败模式分析来聚焦实验重点。 每个实验都应以特定故障或一组故障为目标，并具有明确的假设，例如测试给定流的承受特定组件的损失的能力。 当试验显示新的故障模式或未发现的依赖项时，请更新失败模式分析以使其保持最新状态。

• 在试验期间包含爆破半径。 以能够快速恢复的组件为目标，并对每次故障注入的影响形成有依据的预期。 如果试验超出范围或产生意外结果，请将其停止。 平衡收集有意义的数据，尽量减少对用户的影响。

• 根据基线进行度量。 为每个试验中的流和组件建立一致的可靠性和性能指标。 将降级状态指标与这些基线进行比较，以了解故障的完整效果，并确定复原设计是否满足其目标。

• 将结果纳入测试策略中。 使用试验结果驱动新测试、更新恢复计划，以及通知修正积压工作项。 出现意外行为时，请为这些行为创建有针对性的测试，并设计修正策略。

权衡：在生产环境中进行故障注入测试可能会造成干扰，并且可能导致停机。 就这种可能性向利益相关方保持透明。 实施安全措施，以便你可以停止试验并快速回滚，并灵活处理何时运行测试或在敏感时段避免它们。 若要防范意外中断，请规划足够的 冗余 ，并确保利益干系人了解成本权衡。

风险： 可靠性测试可以扩展许多故障模式的覆盖范围，但一旦它不再提供有意义的价值，应该停止。 如果你们已经积压了一批已知的可靠性问题，应优先修复这些问题，而不是添加更多测试。

Azure 协助服务

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

Azure Chaos Studio是一种托管服务，它使用混沌测试来帮助衡量、了解和改进云应用程序和服务复原能力。

Azure 应用测试是一项服务，可让你使用 剧作家工作区 运行功能测试，并使用 Azure 负载测试 运行性能测试，以识别应用程序中的问题。

Azure 服务运行状况具有计划内维护窗格，它是Azure门户中的专用部分，可让你了解即将进行的维护活动。 它突出显示可能影响 Azure 资源的事件，帮助你提前做好准备。

连接监视器 是 Azure 网络观察程序的 一项功能，可用于跨 Azure 和混合环境对网络连接进行综合监视和实时测试。 在混沌工程方案中，连接监视器可用于将故障注入目标网络组件，并持续测量延迟和数据包丢失等关键指标。 此功能允许团队观察中断如何影响网络可靠性，无论是针对单个流组件，还是跨端到端网络路径。 若要评估故障的影响并确定要改进的领域，请将连接监视器遥测与基线指标进行比较。

相关链接

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

可靠性清单

请参阅完整的建议集。