沙盒和測試環境

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，嚴格的安全和完全自動化。

簡短的結論

設計正確的沙箱和測試環境是「安全氣囊」和「加速器」供應。隔離、生產平價、提供商模擬器、確定性測試數據、強大的可觀察性和預覽環境自動化可實現快速、可靠的「代碼→驗證→發布」循環,從而降低回歸風險並簡化平臺擴展。