右移 是稍后在 DevOps 流程中移动一些测试以 在生产环境中进行测试的做法。 在生产环境中进行测试使用实际部署来验证和测量应用程序在生产环境中的行为和性能。
DevOps 团队可以提高速度的一种方法是采用 左移 测试策略。 Shift 向左移动推送 DevOps 管道中的大多数测试，以减少新代码到达生产并可靠地运行的时间。
但是，尽管许多类型的测试（如单元测试）很容易向左移动，但某些测试类在部署部分或全部解决方案的情况下无法运行。 部署到 QA 或过渡服务可以模拟可比较的环境，但生产环境无法完全替代。 Teams 发现某些类型的测试需要在生产环境中进行。
生产中的测试提供：
- 生产环境的广度和多样性。
- 客户流量的实际工作负荷。
- 随着生产需求随时间的变化，配置文件和行为。
生产环境不断变化。 即使应用未更改，它依赖的基础结构也会不断更改。 在生产环境中进行测试可验证给定生产部署的运行状况和质量，以及不断变化的生产环境。
在生产环境中向右移动测试对于以下方案尤其重要：
微服务部署
基于微服务的解决方案可以具有大量独立开发、部署和管理的微服务。 转移测试对这些项目尤其重要，因为不同的版本和配置可以通过多种方式到达生产环境。 无论预生产测试覆盖率如何，都需要在生产环境中测试兼容性。
确保部署后的质量
发布到生产只是交付软件的一半。 另一半是在生产环境中通过实际工作负荷大规模确保质量。 由于环境不断变化，因此团队永远不会在生产环境中进行测试。
生产中的测试数据实际上是来自实际客户工作负荷的测试结果。 生产中的测试包括监视、故障转移测试和故障注入。 此测试跟踪故障、异常、性能指标和安全事件。 测试遥测还有助于检测异常。
部署层
为了保护生产环境，团队可以使用 基于层的部署 和 功能标志以渐进且受控的方式推出更改。 例如，最好捕获一个 bug，防止购物者在不到 1% 客户处于该部署层时完成购买，而不是一次性切换所有客户。 检测到故障的特征值必须超过这些故障的净损失，以有意义的方式测量给定业务。
第一层应该是运行标准集成套件所需的最小大小。 这些测试可能与管道中之前针对其他环境运行的测试类似，但测试会验证该行为在生产环境中是否相同。 此层在影响任何客户之前会识别明显的错误，例如配置错误。
初始层验证后，下一层可以扩大范围，以包含测试运行的实际用户的子集。 如果一切看起来都不错，则部署可以通过进一步的层和测试进行，直到每个人都使用它。 完整部署并不意味着测试已结束。 跟踪遥测对于在生产环境中进行测试至关重要。
故障注入
团队通常使用 故障注入 和 混乱工程 来了解系统在故障条件下的行为。 这些做法有助于：
- 验证实现复原机制是否确实有效。
- 验证一个子系统中的故障是否包含在该子系统中，并且不会级联以产生重大中断。
- 证明先前事件的修复工作具有所需的效果，而无需等待另一个事件发生。
- 为现场工程师创建更真实的培训演练，以便他们能够更好地准备处理事件。
自动执行故障注入试验是一个很好的做法，因为它们是必须在不断变化的系统上运行的昂贵测试。
混沌工程 可以是一种有效的工具，但应该仅限于对客户影响不大或没有影响的 Canary 环境 。
故障转移测试
故障注入的一种形式是 故障转移 测试，以支持业务连续性和灾难恢复（BCDR）。 Teams 应为所有服务和子系统制定故障转移计划。 计划应包括：
- 明确说明服务的业务影响正在下降。
- 平台、技术和设计 BCDR 计划的人员的所有依赖项的地图。
- 灾难恢复过程的正式文档。
- 定期执行灾难恢复演练的节奏。
断路器故障测试
断路器机制从较大的系统切断给定组件，通常防止该组件的故障分散在其边界之外。 可以有意触发断路器来测试以下方案：
断路器打开时回退是否有效。 回退可能适用于单元测试，但确定它在生产环境中是否按预期运行的唯一方法是注入故障来触发故障。
断路器是否具有适当的敏感度阈值，以便在需要时打开。 故障注入可能会强制延迟或断开依赖项，以观察断层响应能力。 请务必验证不仅发生正确的行为，而且要快速执行。
示例：测试 Redis 缓存断路器
Redis 缓存 通过加快对常用数据的访问来提高产品性能。 请考虑采用对 Redis 的非关键依赖项的方案。 如果 Redis 出现故障，系统应继续工作，因为它可以回退到使用原始数据源进行请求。 若要确认 Redis 故障触发断路器，并且回退在生产环境中有效，请定期针对这些行为运行测试。
下图显示了 Redis 断路器回退行为的测试。 目标是确保当断字符打开时，调用最终会转到 SQL。
上图显示了三个 AT，在对 Redis 的调用前面有断点。 一个测试强制断路器通过配置更改打开，然后观察调用是否转到 SQL。 然后，另一个测试会检查相反的配置更改，方法是关闭断路器以确认呼叫返回 Redis。
此测试验证断断器打开时回退行为是否有效，但不会验证断路器配置在应打开断路器时是否打开断路器。 测试该行为需要模拟实际故障。
故障代理可以在转到 Redis 的调用中引入故障。 下图显示了使用故障注入进行测试。
- 故障注入器会阻止 Redis 请求。
- 断路器打开，测试可以观察回退是否正常工作。
- 该故障已删除，断路器将测试请求发送到 Redis。
- 如果请求成功，调用将恢复为 Redis。
进一步的步骤可以测试断路器的敏感度、阈值过高还是过低，以及其他系统超时是否会干扰断路器行为。
在此示例中，如果断路器未按预期打开或关闭，则可能会导致实时站点事件（LSI）。 如果没有故障注入测试，问题可能会未发现，因为很难在实验室环境中执行这种类型的测试。
后续步骤
- [使用单元测试向左移动测试]shift-left
- 什么是微服务？
- 运行到 Azure 的测试故障转移（灾难恢复演练）
- 安全部署实践
- 什么是监视？
- 什么是平台工程？