沙盒和测试环境

1）为什么需要专用路径

• 快速验证假设和整合，没有生产风险；
• 加快支线循环（PR →分钟内预览参考）；
• 将错误和事件复制到安全副本；
• 执行合同，整合，负载和混沌测试；
• 在"游乐场"培训团队和追逐合作伙伴。

关键原则：隔离、配置均等、测试确定性、数据安全、默认可观察性。

2）环境的层次结构及其目的

本地（Dev）是本地开发：Docker Compose/Testcontainers，轻量级提供商模拟器。
Sandbox是具有假数据和真实协议的外部集成（PSP，KYC，游戏聚合器）的展位。
QA/Test-集成和e2e测试，稳定的数据虚拟化，倒退。
Stage/Pre-Prod-最接近生产的轮廓（配置/限制/拓扑）。
Ephemeral Preview是"在PR上"的环境（生活数小时/天），独立资源和URL，merge/close后自动拆除。

亲和力规则："测试/舞台≈探测器中的设置，策略和基础架构依赖性"，区别仅限于秘密和限制。

3）沙盒类型

1.提供商沙箱：外部PSP/KYC/游戏提供测试结束；我们添加了一层模拟器来模拟罕见和有缺陷的桉例（timeouts，5xx，不稳定的签名）。
2.功能沙箱：自主实例域服务（支付，奖金，吸盘）+虚构。

3.培训/演示沙盒： "展示"API的合作伙伴与DevPortal,密钥,配额和利率限制.

4）合同，模拟器和洗涤器

合同测试（Pact/Buf）：消费者/提供商同意方案；CI阻止不兼容的更改。
提供商模拟器：播放边缘桉例（双回路、时钟漂移、带有过期时间戳的HMAC签名）。

事件文件库（Kafka/NATS）： 案例库的付款。authorized`, `kyc.verified`, `game.round.settled`.

断层喷射：受控延迟,下降,排序消息。

X-Timestamp: 1730812800
X-Signature: sha256=hex(hmac_sha256(secret, body + timestamp))

5）测试数据，GDPR/PCI和匿名

从不使用生产之外的实际PII/PAN。
匿名：合成生成和敏感场标记化；仅用于演示帐户的白名单。
数据设施：具有可预测ID和状态的用户/事务/会话工厂。
确定性种子：测试运行与环境之间的相同虚构。
还原政策：通过环境预览和测试DB自动清洁。

6）秘密和访问

星期三分开的秘密；临时信用和有限角色。
KMS/HSM和轮换；不包括Git中的秘密。
QA/Stage的RBAC/ABAC；访问审核,只有通过协商才能打破玻璃。

7）非数据环境中的观察力

Logs是结构化的，没有PII，带有蒙版。

Latency p50/p95/p99，error-rate，throughput，DLQ，retrai；

跟踪（OTel）： 从输入查询到模拟器的端到端"trace_id"；

Dashboards as Code-dashboards和Alerts在服务旁边进行转换。

8）短暂的预览环境（公关前）

• PR → CI收集图像，生成迁移，在Kubernetes中提高namespace'pr- "；
• 预览URL和测试用户令牌；
• 启用Tracing/度量标准；当PR关闭时,环境将被移除。

yaml apiVersion: v1 kind: Namespace metadata:
name: pr-4821 labels:
env: preview owner: team-payments

9）本地开发： Compose/Testcontainers

yaml version: "3. 9"
services:
api:
build:.
environment:
- DB_URL=postgres://postgres:postgres@db:5432/app? sslmode=disable
- KAFKA_BROKER=kafka:9092 ports: ["8080:8080"]
depends_on: [db, kafka]
db:
image: postgres:16 environment: [POSTGRES_PASSWORD=postgres]
ports: ["5432:5432"]
kafka:
image: bitnami/kafka:latest environment:
- KAFKA_ENABLE_KRAFT=yes
- KAFKA_CFG_PROCESS_ROLES=controller,broker
- KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093
- KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@localhost:9093 ports: ["9092:9092"]

要自动执行测试中的依赖项，请使用伪造的Testcontainers。

10）负载和稳定性测试

负荷配置文件："锦标赛"，"支付浪潮"，"质量大炮"。
KPI：RPS，p95/p99，资源限制（CPU/内存），TTFB，时间到钱包。
溷沌注入：提供商断开连接，潜伏期上升，网络的"flaky"。
在舞台上检查电路断路器/背面政策；失败进入DLQ并重新出现。

11）回滚和倒带政策

用于DLQ事件的Replay网关（手动/自动模式、按键过滤器）。
迁移基础：在预览/舞台上清晰up/down和dry-run；防止破坏性变化。

12）与DevPortal的集成

沙盒和提供商目录，字段要求，查询示例。
每个PR/分支上的"开放预览"按钮；SLO/SLA指标小部件。
从合同中生成SDK和Postman/Insomnia收藏品。

13）沙箱周边安全

用于外部沙箱的WAF+IP allowlist；

按键的配额和等级限制；

单个域/子域；自动删除非活动密钥；

扫描每张钞票上的图像漏洞和依赖关系。

14）流程： 谁以及如何使用

开发人员-本地和预览,快速支架。
QA是具有数据驱动和模拟器的稳定Test/Stage。
合作伙伴是具有DevPortal，配额和监视功能的外部Sandbox。
SRE/平台-负载配置文件、溷乱、SLO检查。

15）沙盒启动支票清单

• 在Registry中的合同，模拟器涵盖成功/错误/计时/重播。
• 测试数据是合成的，确定性的，没有PII/PAN。
• 来自KMS的秘密，角色有限，审计包括在内。
• 有度量/traces/logs可用；错误预算和DLQ上的差异。
• Ephemeral预览在PR上升并自动拆除。
• 负载配置文件和混沌脚本由代码描述。
• 迁移策略和事件重播已在Stage上验证。
• DevPortal发布海德和查询集合。

16）实施路线图

M0-M1（MVP）：局部环境（Compose），基本的PSP/KYC模拟器，CI中的合同测试，K8s中的预览空间。
M2-M3：虚构目录,Dashboards as Code, DLQ+手动反射,载荷配置文件。
M4-M6：一个完整的外部Sandbox，带有钥匙/配额，混沌基础设施，SDK自动化，"两个并行版本"迁移策略。
M6+：具有故障传递的地域分布式阶段，测试中的SLA提供商智能路由，DevPortal中的自动化培训脚本。

17）环境成熟度模型（简述）

1.基本是测试/阶段，手动数据，弱隔离。
2.高级模拟器，合同测试，可观察性，部分预览。
3.专家-周围环境的per-PR，混乱/负载作为代码，DevPortal，严格的安全和完全自动化。

简短的结论

设计正确的沙箱和测试环境是"安全气囊"和"加速器"供应。隔离、生产平价、提供商模拟器、确定性测试数据、强大的可观察性和预览环境自动化可实现快速、可靠的"代码→验证→发布"循环,从而降低回归风险并简化平台扩展。