Cutii de nisip și medii de testare

1) De ce avem nevoie de contururi selectate

• testează rapid ipoteze și integrări fără a risca producția;
• accelerarea ciclului de feedback (PR → preview-link în câteva minute);
• reproduce erorile și incidentele pe o copie sigură;
• Efectuați teste de contract, integrare, încărcare și haos
• echipele de tren și să echipeze partenerii de pe „loc de joacă”.

Principii cheie: izolare, paritate de configurare, determinism de testare, securitatea datelor, observabilitate implicită.

2) Ierarhia mediilor și scopul acestora

Local (Dev) - dezvoltare locală: Docker Compose/Testcontainers, simulatoare ușor furnizor.
Sandbox este un stand pentru integrări externe (PSP, KYC, agregatoare de jocuri) cu date false și protocoale reale.
QA/Test - integrare și teste e2e, remedieri de date stabile, regresii.
Etapa/Pre-Prod - conturul cât mai aproape de producție (configurații/limite/topologie).
Ephemeral Preview - mediu „on PR” (trăiește ore/zile), resurse offline și URL, auto-demolare după îmbinare/închidere.

Regula parității este "setări, politici și dependențe de infrastructură în Test/Stage ≈ Prod', diferențele sunt doar în secrete și limite.

3) Tipuri de cutii de nisip

1. Cutii de nisip furnizor: externe PSP/KYC/jocuri oferi puncte finale de testare; adăugăm un strat de simulatoare pentru a simula cazuri rare și eronate (timeout, 5xx, semnături instabile).
2. Cutii de nisip funcționale: instanțe autonome de servicii de domeniu (plăți, bonusuri, realizări) + remedieri.
3. Training/demo sandboxes: API „showcase” pentru parteneri cu DevPortal, chei, cote și limita ratei.

4) Contracte, simulatoare și moki

Testarea contractelor (Pact/Buf): consumatorul/furnizorul convin asupra sistemelor; modificările incompatibile sunt blocate pe CI.
Simulatoare furnizor: reda cazuri de margine (ciocniri duble, derivă ceas, semnătură HMAC cu timestamp expirat).
Corecții de evenimente (Kafka/NATS): plata bibliotecii de caz. autorizat „,” kyc. verificat „,” joc. rotund. stabilit ".
Injecție de eroare: întârzieri controlate, drop-rate, mesaje out-of-order.

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

5) Date de testare, GDPR/PCI și anonimizare

Nu utilizați niciodată PII/PAN real în afara producției.
Anonimizare: generarea de sintetice + tokenizarea câmpurilor sensibile; whitelisting pentru conturi demo numai.
Fabrici de date: fabrici de utilizatori/tranzacții/sesiuni cu ID-uri și stări previzibile.
Semințe deterministe: remedieri identice între cursele de testare și miercurea.
Politica de retenție: auto-curățarea mediilor de previzualizare și bazele de date de testare.

6) Secretele și accesul

Secrete separate în zilele de miercuri; credite temporare și roluri restrânse.
KMS/HSM și rotații; exclus secrete în Git.
RBAC/ABAC pentru QA/Stage; audit de acces, pauză de sticlă numai prin negociere.

7) Observabilitate în medii neindustriale

Busteni - structurati, fara PII, cu mascare;

Metrics latency p50/p95/p99, error-rate, throughput, DLQ, retrai;

Urmărirea (OTel): end-to-end "trace _ id' de la cererea de intrare la simulator;

Tablouri de bord ca cod - tablouri de bord și alerte sunt versionate lângă serviciu.

8) Medii de previzualizare efemere (per-PR)

• PR → CI colectează o imagine, generează migrații, ridică namespace 'pr- ' în Kubernetes;
• Sunt emise URL-uri de previzualizare și jetoane ale utilizatorilor de testare;
• trasare/măsurare activată; când PR-ul este închis, mediul este eliminat.

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

9) Dezvoltare locală: Compune/Testcontainere

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

Pentru ridicarea automată a dependențelor în teste - Testcontainere cu remedieri.

10) Încercări de sarcină și stabilitate

Profiluri de încărcare: „turnee”, „valuri de plată”, „fluffuri de masă”.
KPI: RPS, p95/p99, limitele resurselor (CPU/memorie), TTFB, Time-to-Wallet.
Injecții de haos: deconectări ale furnizorilor, o creștere a latenței, rețele „flaky”.
Politicile de întrerupere/backoff sunt verificate pe Stage; dips du-te la DLQ și replica.

11) Politici de rollback și reluare

Replay gateway pentru evenimente de la DLQ (moduri manuale/auto, filtre după taste).
Baze de migrare: curățați în sus/în jos și uscați în previzualizare/etapă; protecție împotriva schimbărilor perturbatoare.

12) Integrarea cu DevPortal

Catalog de cutii de nisip și furnizori, cerințe de teren, exemple de interogări.
Butonul „Deschidere previzualizare” pentru fiecare PR/ramură; Widget metric SLO/SLA.
Generarea colecțiilor SDK și Postman/Insomnia din contracte.

13) Securitatea perimetrului Sandbox

WAF + IP-allowlist pentru cutii de nisip externe;

cote și limite de rată per cheie;

domenii/subdomenii individuale; îndepărtarea automată a cheilor inactive;

scanarea vulnerabilităților imaginii și a dependențelor de fiecare construcție.

14) Procese: cine folosește și cum

Dezvoltatori - local și previzualizare, feedback rapid.
QA - Test stabil/Etapa cu date și simulatoare gestionate.
Parteneri - Sandbox extern cu DevPortal, cote și monitorizare.
SRE/Platform - profile de încărcare, haos, verificare SLO.

15) Lista de verificare a lansării Sandbox

• Contractele în Registry, simulatoarele acoperă succesul/erorile/timeout-urile/repetițiile.
• Testați datele sintetice, deterministe, fără PII/PAN.
• Secretele de la KMS, roluri limitate, audit activat.
• Metrica/trasee/busteni sunt disponibile; alerte la eroare-buget și DLQ.
• Previzualizări efemere merge în sus pe PR și auto-demolate.
• Profilurile de încărcare și scenariile de haos sunt descrise prin cod.
• Politicile de migrație și reluarea evenimentelor verificate pe Stage.
• DevPortal publică ghiduri și colecții de interogări.

16) Foaia de parcurs privind implementarea

M0-M1 (MVP): medii locale (Compose), simulator de bază PSP/KYC, teste de contract în CI, spații de previzualizare în K8s.
M2-M3: cataloage de fixare, tablouri de bord ca cod, reluare manuală DLQ +, profile de încărcare.
M4-M6: Sandbox extern cu chei/cote, infrastructură haos, autogen SDK, „două versiuni în paralel” politica de migrare.
M6 +: Etapa geo-distribuită cu failover, rutarea inteligentă a furnizorilor prin SLA în teste, scripturi automate de instruire în DevPortal.

17) Modelul maturității mediului (scurt)

1. Basic - există Test/Stage, date manuale, izolare slabă.
2. Avansat - simulatoare, teste de contract, observabilitate, previzualizări parțiale.
3. Expert - medii per-PR, haos/încărcare ca cod, DevPortal, securitate puternică și automatizare completă.

Scurtă concluzie

Cutii de nisip proiectate în mod corespunzător și medii de testare sunt „airbag” și „accelerator” de livrare. Izolarea, paritatea cu producția, simulatoarele furnizorului, datele de testare deterministe, observabilitatea puternică și automatizarea mediilor de previzualizare oferă un cod rapid și fiabil → verificarea ciclului → eliberare, reducând riscul de regresii și simplificând scalarea platformei.