在生产中右移测试

  • 项目

右移是后续在 DevOps 流程中移动某些测试以在生产环境中进行测试的做法。 在生产环境中进行测试使用实际部署来验证和度量应用程序在生产环境中的行为和性能。

DevOps 团队可通过左移测试策略来提高速度。 左移会在 DevOps 管道中提前推送大多数测试，从而缩短新代码进入生产环节并可靠运行的时长。

但是，尽管很多类型的测试（如单元测试）可轻松实现左移，但某些类别的测试在未部署部分或整个解决方案的情况下无法运行。 部署到 QA 或暂存服务可模拟出一个类似的环境，但无法完全替代生产环境。 团队会发现某些类型的测试需在生产环境中进行。

在生产环境中测试可提供：

  • 生产环境的广度和多样性。
  • 客户流量的实际工作负荷。
  • 随着生产需求随时间不断变化，个人资料和行为的状况。

生产环境会不断变化。 即使应用未更改，它依赖的基础结构也会不断变化。 在生产环境中进行测试可验证给定生产部署以及不断变化的生产环境的运行状况和质量。

在生产环境中右移至测试对于以下场景尤其重要：

微服务部署

基于微服务的解决方案可能存在大量独立开发、部署和管理的微服务。 右移测试对这些项目尤其重要，因为不同的版本和配置可通过多种方式到达生产环境。 无论预生产测试覆盖率如何，都需要在生产环境中测试兼容性。

确保部署后的质量

发布到生产环境只是交付软件工作的一半。 另一半是在生产环境中通过实际工作负荷大规模确保质量。 由于环境会不断变化，因此团队永远无法在生产环境中停止测试。

在生产环境中测试数据实际上是实际客户工作负荷下的测试结果。 在生产环境中进行测试包括了监视、故障转移测试和故障注入。 此测试可跟踪故障、异常、性能指标和安全事件。 测试遥测还有助于检测异常。

部署环

为了保护生产环境，团队可使用基于环的部署和功能标志以渐进且受控的方式发布更改。 例如，最好捕获一个 bug，它可防止购物者在不到 1% 的客户处于该部署环时完成购买，而不是在一次性切换所有客户后完成购买。 检测到故障的功能值必须超过这些故障的净损失，从而以有意义的方式对给定业务进行度量。

第一个环应为运行标准集成套件所需的最小大小。 这些测试可能与管道中之前针对其他环境运行的那些测试类似，但测试会验证该行为在生产环境中是否也相同。 此环可在明显错误（例如配置错误）影响客户之前进行识别。

初始环验证完成后，下一环可扩大范围，以包含测试运行的实际用户的子集。 如果一切正常，部署则会通过后续的环和测试，直到每个人都在使用它。 完整部署并不意味着测试已结束。 跟踪遥测对于在生产环境中进行测试至关重要。

故障注入

团队通常使用故障注入和混沌工程来了解系统在故障情况下的行为。 这些做法有助于：

  • 验证实现的复原机制确实有效。
  • 验证一个子系统中的故障是否包含在该子系统中，且不会出现级联效应从而导致重大中断。
  • 证明先前事件的修复工作达到所需效果，而无需等待其他事件发生。
  • 为实时现场工程师创建更真实的培训演练，以便他们能更好地准备处理事件。

自动执行故障注入试验是一个很好的做法，因为它们是必须在不断变化的系统上运行的昂贵测试。

混沌工程可能会成为一种有效的工具，但应仅限于对客户影响不大或没有影响的 Canary 环境。

故障转移测试

故障注入的其中一种形式是故障转移测试，它可用于支持业务连续性和灾难恢复 (BCDR)。 团队应为所有服务和子系统制定故障转移计划。 这些计划应包括：

  • 受影响服务的业务影响的清晰说明。
  • 平台、技术以及设计 BCDR 计划的人员的所有依赖关系的地图。
  • 灾难恢复过程的正式文档。
  • 定期执行灾难恢复演练的节奏。

断路器故障测试

断路器机制会从较大的系统切断某一给定组件，通常其目的是防止该组件的故障扩散到其边界之外。 可有意触发断路器来测试以下场景：

  • 断路器打开时回退是否有效。 回退可能适用于单元测试，但确定它在生产环境中是否按预期运行的唯一方法是注入故障来触发故障。

  • 断路器是否具有适当的敏感度阈值，以便在需要时将其打开。 故障注入可能会强制延迟或断开依赖关系，以观察断路器的响应能力。 请务必验证不仅会出现正确的行为，而且能足够快速的出现。

示例：测试 Redis 缓存断路器

Redis 缓存通过加快对常用数据的访问来提高产品性能。 请考虑使用针对 Redis 的非关键依赖关系的场景。 如果 Redis 出现故障，系统应继续工作，因为它可以回退到使用原始数据源进行请求的状态。 若要确认 Redis 故障触发了断路器且回退在生产环境中有效，请定期针对这些行为运行测试。

下图显示了针对 Redis 断路器回退行为的测试。 其目标是确保当断路器打开时，调用最终会转到 SQL。

Diagram showing tests for the Redis circuit breaker and fallback behavior.

上图显示了三个 AT，同时断路器位于对 Redis 的调用之前。 其中一个测试会迫使断路器通过配置更改来打开，然后观察调用是否会转到 SQL。 然后，另一测试会检查相反的配置更改，其方法是关闭断路器以确认调用会返回 Redis。

此测试可验证当断路器打开时回退行为是否有效，但不会验证断路器配置在应打开断路器时是否会将其打开。 测试该行为需模拟实际故障。

故障代理可在转到 Redis 的调用中引入故障。 下图显示了使用故障注入进行的测试。

Diagram showing Redis circuit breaker testing with fault injection.

  1. 故障注入程序会阻止 Redis 请求。
  2. 断路器打开，且测试可观察回退是否有效。
  3. 故障已移除，且断路器向 Redis 发送测试请求。
  4. 如果请求成功，调用将恢复到 Redis。

后续步骤可测试断路器的敏感度、阈值过高还是过低，以及其他系统超时是否会干扰断路器行为。

在本例中，如果断路器未按预期打开或关闭，则可能会导致实时现场事件 (LSI)。 如果没有故障注入测试，此问题可能无法发现，因为很难在实验室环境中执行此类测试。

后续步骤