Sandkästen und Testumgebungen

1) Warum Sie dedizierte Konturen benötigen

• schnelle Überprüfung von Hypothesen und Integrationen ohne Risiko für die Produktion;
• Beschleunigung des Feedback-Zyklus (PR → Preview-Link in Minuten);
• Fehler und Vorfälle auf einer sicheren Kopie reproduzieren;
• Durchführung von Vertrags-, Integrations-, Last- und Chaos-Tests;
• Trainieren Sie Teams und Onbord Partner auf dem „Spiel“ Spielplatz.

Schlüsselprinzipien: Isolation, Konfigurationsparität, Testdeterminismus, Datensicherheit, Standardbeobachtbarkeit.

2) Hierarchie der Umgebungen und deren Zweck

Local (Dev) - lokale Entwicklung: Docker Compose/Testcontainer, die leichtgewichtigen Simulatoren der Anbieter.
Sandbox ist ein Stand für externe Integrationen (PSP, KYC, Spielaggregatoren) mit gefälschten Daten und echten Protokollen.
QA/Test - Integrations- und e2e-Tests, stabile Datenfixturen, Regressionen.
Stage/Pre-Prod - möglichst produktionsnahe Kontur (Konfigurationen/Limits/Topologie).
Ephemeral Preview - Umgebung „on PR“ (lebt für Stunden/Tage), autonome Ressourcen und URLs, Auto-Abbruch nach Merge/Close.

Parity-Regel: "Einstellungen, Richtlinien und Infrastrukturabhängigkeiten in Test/Stage ≈ Prod', Unterschiede - nur in Geheimnissen und Grenzen.

3) Sandkastentypen

1. Anbieter Sandboxes: Externe PSP/KYC/Spiele bieten Test Endpunkte; Wir fügen eine Schicht von Simulatoren hinzu, um seltene und fehlerhafte Fälle (Timeouts, 5xx, instabile Signaturen) zu simulieren.
2. Funktionale Sandboxes: autonome Instanzen von Domain-Diensten (Zahlungen, Boni, Abzeichen) + Fixtures.
3. Training/Demo Sandboxes: API „Schaufenster“ für Partner mit DevPortal, Schlüssel, Quoten und Rate Limit.

4) Verträge, Simulatoren und Moks

Vertragsprüfung (Pact/Buf): Verbraucher/Anbieter vereinbaren Regelungen; inkompatible Änderungen werden auf der CI blockiert.
Anbieter-Simulatoren: spielen Edge-Cases ab (doppelte Kollbecks, Uhrendrift, HMAC-Signatur mit abgelaufenem Timestamp).
Ereignis-Fiktionen (Kafka/NATS): Fallbibliothek 'Zahlung. authorized`, `kyc. verified`, `game. round. settled`.
Fehlerbehebung: kontrollierte Verzögerungen, Drop-Rate, Out-of-Order-Nachrichten.

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

5) Testdaten, DSGVO/PCI und Anonymisierung

Verwenden Sie niemals echte PII/PAN außerhalb der Produktion.
Anonymisierung: Erzeugung von Synthetik + Tokenisierung empfindlicher Felder; Whitelists nur für Demo-Konten.
Data factories: Benutzer-/Transaktions-/Sitzungsfabriken mit vorhersehbaren IDs und Status.
Deterministische Samen: identische Fiktionen zwischen Testlauf und Medium.
Retenschna Politik: Auto-Bereinigung Vorschau Umgebungen und Test-DBs.

6) Geheimnisse und Zugang

Getrennte Geheimnisse am Mittwoch; Temporäre Credits und begrenzte Rollen.
KMS/HSM und Rotation; Geheimnisse in Git ausgeschlossen.
RBAC/ABAC für QA/Stage; Zugangsprüfung, Bruch-Glas nur durch Abstimmung.

7) Observability in nicht-prod Umgebungen

Protokolle - strukturiert, ohne PII, mit Maskierung;

Latency metrics p50/p95/p99, error-rate, throughput, DLQ, retrays;

Tracing (OTel): Ende-zu-Ende' trace _ id 'von der Eingabeaufforderung zum Simulator;

Dashboards als Code - Dashboards und Alerts werden neben dem Service versioniert.

8) Ephemere Vorschauumgebungen (per-PR)

• PR → CI sammelt das Bild, generiert Migrationen, hebt namespace' pr- 'in Kubernetes;
• die Preview-URL und die Token der Testbenutzer werden ausgegeben;
• Tracing/Metriken enthalten; Beim Schließen von PR wird die Umgebung gelöscht.

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

9) Lokale Entwicklung: Compose/Testcontainer

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"]

Zum automatischen Abbilden von Abhängigkeiten in Tests - Testcontainer mit Fixstrukturen.

10) Belastungs- und Belastungstests

Lastprofile: „Turniere“, „Zahlungswellen“, „Massenpuschis“.
KPI: RPS, p95/p99, Resource Limits (CPU/Speicher), TTFB, Time-to-Wallet.
Chaos-Injektionen: Anbieterausfälle, zunehmende Latenz, „flaky“ Netzwerke.
Circuit Breaker/Backoff-Richtlinien werden auf Stage überprüft; Fehler gehen in DLQ und werden repliziert.

11) Rollback- und Replikationsrichtlinien

Replay-Gateway für Ereignisse aus DLQ (manueller/automatischer Modus, Schlüsselfilter).
Migrationsdatenbanken: klares Up/Down und Dry-Run in der Vorschau/Stage; Schutz vor zerstörerischen Veränderungen.

12) Integration mit DevPortal

Sandkasten- und Anbieterverzeichnis, Feldanforderungen, Beispielabfragen.
Schaltfläche „Open Preview“ für jeden PR/Zweig; SLO/SLA-Metrik-Widget.
Generierung von SDK und Postman/Insomnia Sammlungen aus Verträgen.

13) Sandbox Perimeter Sicherheit

WAF + IP-allowlist für externe Sandboxes;

Quoten und Rate-Limits pro Schlüssel;

einzelne Domänen/Subdomains; automatisches Löschen inaktiver Schlüssel;

Scan der Image-Schwachstellen und Abhängigkeiten auf jedem Bild.

14) Prozesse: Wer wie nutzt

Die Entwickler sind lokal und eine Vorschau, ein schneller Fidback.
QA ist ein stabiler Test/Stage mit geführten Daten und Simulatoren.
Partner sind die externe Sandbox mit DevPortal, Quoten und Monitoring.
SRE/Plattform - Lastprofile, Chaos, SLO-Check.

15) Sandbox Start Checkliste

• Verträge in der Registry, Simulatoren decken Erfolg/Fehler/Timeouts/Wiederholungen ab.
• Die Testdaten sind synthetisch, deterministisch, ohne PII/PAN.
• Geheimnisse aus KMS, Rollen begrenzt, Audit aktiviert.
• Metriken/Traces/Logs verfügbar; alerts auf error-budget und DLQ.
• Ephemeral Previews steigen auf PR und Auto-Demolition.
• Lastprofile und Chaos-Szenarien werden durch Code beschrieben.
• Migrations- und Ereignisreplikationsrichtlinien wurden auf Stage validiert.
• Das DevPortal veröffentlicht Hydes und Anfragesammlungen.

16) Fahrplan für die Umsetzung

M0-M1 (MVP): lokale Umgebungen (Compose), Basis-PSP/KYC-Simulator, Vertragstests in CI, Preview-Neymspaces in K8s.
M2-M3: Verzeichnisse von Fixturen, Dashboards als Code, DLQ + manuelle Replikation, Lastprofile.
M4-M6: vollwertige externe Sandbox mit Schlüsseln/Quoten, Chaos-Infrastruktur, Autogen SDK, Migrationspolitik „zwei Versionen parallel“.
M6 +: Geo-verteilte Stage mit Failover, Smart Provider Routing über SLA in Tests, automatisierte Trainingsszenarien im DevPortal.

17) Umgebungsreifemodell (kurz)

1. Basic - es gibt Test/Stage, manuelle Daten, schwache Isolierung.
2. Fortgeschritten - Simulatoren, Vertragstests, Beobachtbarkeit, Teilvorschauen.
3. Expert - per-PR-Umgebung, Chaos/Last als Code, DevPortal, strenge Sicherheit und vollständige Automatisierung.

Kurzes Fazit

Richtig gestaltete Sandkästen und Testumgebungen sind der „Airbag“ und der „Beschleuniger“ der Versorgung. Isolation, Parität mit der Produktion, Anbieter-Simulatoren, deterministische Testdaten, starke Beobachtbarkeit und die Automatisierung von Preview-Umgebungen bieten einen schnellen und zuverlässigen Code → Validierungs- → Release-Zyklus, der das Risiko von Regressionen verringert und die Skalierung der Plattform vereinfacht.