Пісочниці і тестові оточення

1) Навіщо потрібні виділені контури

• швидко перевіряти гіпотези та інтеграції без ризику для продакшену;
• прискорювати фідбек-цикл (PR → прев'ю-посилання за хвилини);
• відтворювати помилки та інциденти на безпечній копії;
• виконувати контрактні, інтеграційні, навантажувальні та хаос-тести;
• навчати команди і онбордити партнерів на «ігровому» майданчику.

Ключові принципи: ізоляція, паритет конфігурацій, детермінізм тестів, безпека даних, спостережуваність за замовчуванням.

2) Ієрархія середовищ та їх призначення

Local (Dev) - локальна розробка: Docker Compose/Testcontainers, легковагі симулятори провайдерів.
Sandbox - стенд для зовнішніх інтеграцій (PSP, KYC, агрегатори ігор) з фейковими даними і реальними протоколами.
QA/Test - інтеграційні та e2e-тести, стабільні фікстури даних, регреси.
Stage/Pre-Prod - максимально наближений до продакшену контур (конфігурації/ліміти/топологія).
Ephemeral Preview - оточення «на PR» (живе годинами/днями), автономні ресурси і URL, авто-знесення після merge/close.

Правило parity: «налаштування, політики та інфраструктурні залежності в Test/Stage ≈ Prod», відмінності - тільки в секретах і лімітах.

3) Типи пісочниць

1. Пісочниці провайдерів: зовнішні PSP/KYC/ігри надають test endpoints; ми додаємо шар симуляторів, щоб моделювати рідкісні і помилкові кейси (timeouts, 5xx, нестабільні підписи).
2. Функціональні пісочниці: автономні інстанси доменних сервісів (платежі, бонуси, ачування) + фікстури.
3. Навчальні/демо-пісочниці: «вітрина» API для партнерів з DevPortal, ключами, квотами і rate limit.

4) Контракти, симулятори і моки

Contract-testing (Pact/Buf): споживач/провайдер узгодять схеми; несумісні зміни блокуються на CI.
Симулятори провайдерів: відтворюють edge-кейси (подвійні коллбеки, дрейф годинників, підпис HMAC з простроченим timestamp).
Фікстури подій (Kafka/NATS): бібліотека кейсів'payment. authorized`, `kyc. verified`, `game. round. settled`.
Fault injection: керовані затримки, drop-rate, out-of-order повідомлення.

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

5) Тест-дані, GDPR/PCI і анонімізація

Ніколи не використовуємо реальні PII/PAN поза продакшеном.
Анонімізація: генерація синтетики + токенізація чутливих полів; білі списки тільки для демонстраційних акаунтів.
Data factories: фабрики користувачів/транзакцій/сесій з передбачуваними ID і статусами.
Deterministic seeds: однакові фікстури між прогоном тестів і середовищами.
Політика ретеншна: авто-очищення превью оточень і тестових БД.

6) Секрети і доступ

Роздільні секрети по середах; тимчасові креди та обмежені ролі.
KMS/HSM і ротації; виключені секрети в Git.
RBAC/ABAC для QA/Stage; аудит доступу, break-glass тільки через узгодження.

7) Observability в не-прод середовищах

Логи - структуровані, без PII, з маскуванням;

Метрики latency p50/p95/p99, error-rate, throughput, DLQ, ретраї;

Трейсинг (OTel): наскрізні'trace _ id'з вхідного запиту до симулятора;

Dashboards as Code - дашборди і алерти версіонуються поруч з сервісом.

8) Ефемерні прев'ю-оточення (per-PR)

• PR → CI збирає образ, генерує міграції, піднімає namespace'pr- 'в Kubernetes;
• видається прев'ю-URL і токени тест-користувачів;
• включений трейсинг/метрики; при закритті 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/memory), TTFB, Time-to-Wallet.
Chaos-ін'єкції: відключення провайдерів, зростання латентності, «flaky» мережі.
Circuit breaker/backoff політики перевіряються на Stage; провали йдуть в DLQ і реплеяться.

11) Політики відкату і реплея

Replay-шлюз для подій з DLQ (ручний/авто режими, фільтри по ключах).
Бази міграцій: чіткі up/down і dry-run в прев'ю/Stage; Захист від руйнівних змін.

12) Інтеграція з DevPortal

Каталог пісочниць і провайдерів, вимоги до полів, приклади запитів.
Кнопка «Open Preview» у кожного PR/гілки; віджет метрик SLO/SLA.
Генерація SDK і Postman/Insomnia колекцій з контрактів.

13) Безпека периметра пісочниць

WAF + IP-allowlist для зовнішніх пісочниць;

квоти і rate limits на ключ;

окремі домени/піддомени; автоматичне видалення неактивних ключів;

скан вразливостей образів і залежностей на кожному білді.

14) Процеси: Хто і як користується

Розробники - локально і прев'ю, швидкий фідбек.
QA - стабільний Test/Stage з керованими даними і симуляторами.
Партнери - зовнішня Sandbox з DevPortal, квотами та моніторингом.
SRE/Платформа - профілі навантаження, хаос, перевірка SLO.

15) Чек-лист запуску пісочниці

• Контракти в Registry, симулятори покривають успіх/помилки/таймаути/повтори.
• Тест-дані синтетичні, детерміновані, без PII/PAN.
• Секрети з KMS, ролі обмежені, аудит включений.
• Метрики/трейси/логи доступні; альберти на error-budget і 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+: гео-розподілені Stage з failover, смарт-маршрутизація провайдерів по SLA в тестах, автоматизовані навчальні сценарії в DevPortal.

17) Модель зрілості оточень (коротко)

1. Базова - є Test/Stage, ручні дані, слабка ізоляція.
2. Просунута - симулятори, контракт-тести, спостережуваність, часткові прев'ю.
3. Експертна - per-PR оточення, хаос/навантаження як код, DevPortal, сувора безпека і повна автоматизація.

Короткий висновок

Правильно спроектовані пісочниці і тестові оточення - це «подушка безпеки» і «прискорювач» поставки. Ізоляція, паритет з продакшеном, симулятори провайдерів, детерміновані тест-дані, сильна спостережуваність і автоматизація превью-середовищ дають швидкий і надійний цикл «код → перевірка → реліз», знижуючи ризик регресів і спрощуючи масштабування платформи.