是时候终结 Staging：在生产环境中测试的必要性
Source: Dev.to
（请提供需要翻译的正文内容，我才能为您完成简体中文翻译。）
介绍
Staging 长期被视为软件开发中的必要之恶。它曾是验证更改在进入生产环境前的首选环境。然而，更新的隔离方法和按需沙箱使得 Staging 更像是一种负担而非好处。是时候淘汰你的 Staging 环境了。
为什么 Staging 成为瓶颈
- 共享队列： 当许多开发者合并代码时，staging 成为争用点，测试因冲突的更改而失败，而不是实际的 bug。
- 保真度差距： Staging “类似生产”，但从未匹配真实的数据规模、流量模式或 IAM 策略，导致危险的 bug 隐藏。
- 速度损失： 提交代码、等待 CI、等待部署槽位、运行冗长的测试套件的循环破坏了流动状态。
- 维护被忽视： 团队常把不稳定的构建倾倒到 staging，导致它进一步偏离生产。
过时的假设
传统工作流假设测试必须在 environment level：要测试服务的新版本，需要将其与所有依赖项（购物车、用户、认证等）一起部署在一个独立的环境中。这个假设已不再成立。
请求级隔离：一种新模型
而不是克隆整个环境，您只启动正在更改的服务。Kubernetes 原生平台可以为每个请求提供按需沙箱。
工作原理
- 沙箱创建： 在隔离的沙箱中启动新的服务版本。
- 标头标记： 测试请求带有唯一的标头。
- 路由： 标头将请求路由到沙箱中的服务。
- 依赖调用： 沙箱服务对其依赖的调用会被路由回生产环境中的稳定基线服务。
- 隔离： 测试请求在整个堆栈中保持隔离，而其他所有流量正常进行。
这种方法提供了高保真度的测试（真实的依赖、真实的网络策略），而没有共享环境的缺点——没有冲突、没有排队，成本显著降低。
安全生产测试的防护措施
严格的数据隔离
路由头部将测试流量隔离，并将所有数据库写入定向到独立的测试数据库。测试用户仅与测试数据交互；生产数据保持不受影响。
多租户与网络控制
- VPN 限制确保测试流量来自授权的内部网络。
- 审计日志跟踪每个沙箱会话，以满足合规要求。
请求路由与影响范围控制
沙箱请求在请求层面被隔离，防止对同事工作产生影响，并保持生产流量不受影响。
渐进式发布
沙箱负责预生产验证，但仍需使用金丝雀部署、功能标记和可观测性，以安全地向真实用户推送。
常见问题
-
如何保证测试流量不会破坏生产数据？
测试写入被重定向到临时、非生产的数据存储，测试结束后这些存储会被销毁。 -
那冲击范围呢？坏的测试会对下游服务进行 DDoS 吗？
沙箱是配备了熔断器和网络策略的“影子”部署。失控的请求会被限流并被限制在沙箱内部。 -
这对 Kafka 或 gRPC 等协议有效吗？
隔离模型与协议无关。隔离标头可以在 gRPC 中传播，或作为 Kafka 消息头部传递，使得沙箱消费者只处理带有其唯一沙箱 ID 的消息。 -
合规性和审计要求如何满足？
每个沙箱都绑定到特定的用户和 pull‑request/开发会话。所有测试流量都会标记沙箱 ID 和用户身份，生成的审计日志比共享的预发布环境更细粒度。
好处与实际采用
- 成本节约: 消除维护预发布环境的直接基础设施成本。
- 开发者体验: 更快的反馈循环，降低摩擦。
- 上市速度: 团队能够比竞争对手更快迭代和发布。
- 可靠性: 更高保真度的测试能够捕获预发布环境可能遗漏的错误。
知名的云原生团队，如 DoorDash 和 Uber，已经将测试前移到生产环境，实现了显著的基础设施节约并提升了测试保真度。
结论
预发布环境是一个时代的产物，当时复制基础设施比协调共享资源更困难。那个时代正在结束。未来不在于构建更好的生产近似环境；而是通过强大的防护措施直接在生产环境中进行测试。淘汰预发布环境可以实现更快的交付、更低的成本以及更可靠的代码。