PSP-X latency & loss

(Розділ: Технології та Інфраструктура)

Коротке резюме

Chaos Engineering - це науковий метод для продакшну: ви формулюєте гіпотезу про стабільність, порушуєте оточення контрольованим чином і доводите, що призначена для користувача цінність (SLO/бізнес-метрики) зберігається. Для iGaming це перевірки платежів (PSP), ініціалізації ігор, черг висновків, мультирегіону і пікових навантажень - в умовах затримок, відмов і «шторму» ретраїв - до того, як це трапиться з живими користувачами.

1) Принципи хаос-інжинірингу

1. Від steady-state до гіпотези. Визначте норму: Availability, p95/p99, TTW, конверсію платежів.
2. Малий blast radius. Експеримент спочатку в staging/канарі, 1-5% трафіку/1-2 пода/один регіон.
3. Спостережуваність перш за все. Метрики/логи/трейси + анотації експерименту.
4. Guardrails и abort. Жорсткі пороги SLO/бізнес-KPI для автоматичної зупинки.
5. Повторюваність і автоматизація. Експерименти як код (IaC/GitOps), план game-day.
6. Blameless культура. Експеримент - не пошук винних, а пошук слабких місць.

2) Steady-state і метрики успіху

TexSLI: p95/p99 API, error-rate, saturation (CPU/IO), queue lag (withdrawals/deposits), latency провайдеров.
Бізнес-SLI: конверсія'attempt→success', TTW p95, успішність'game init', частка відмов PSP за кодами.

3) Класи експериментів (що «ламаємо»)

Мережа: latency/jitter/packet loss/blackhole, DNS-збої, MTU-аномалії.
Ресурси: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
Процеси та майданчики: kill/evict подов, node failure, zone/region failover.
Залежності: PSP-таймаути/помилки, недоступність провайдера ігор, деградація CDN/кешу.
Черги/стрімінг: зростання Kafka lag, пауза консьюмерів, розрив партій/лідера.
Дані/БД: затримки реплікації, деградація індексів, read-only режим.
Релізи/фічефлаги: промахи міграцій, помилкові конфіги, kill-switch.
Фронт/RUM: падіння LCP/INP, краші клієнта в піку.
Data/ML: старіння фічів, збільшення latency моделі, падіння tokens/s, деградація якості.

4) Процес: від гіпотези до поліпшень

1. Сформулювати гіпотезу (конкретні SLO/бізнес-KPI + очікувана поведінка захистів).
2. Спроектувати експеримент: вид збою, тривалість, blast radius, guardrails/abort.
3. Підготувати спостережуваність: дашборди «release/experiment compare», анотації.
4. Запустити під контролем IM/TL, повідомити on-call/бізнес (якщо зачіпає).
5. Виміряти результат: SLO, p95/p99, TTW, конверсію, лаги, ретраї.
6. Сформувати action items: ліміти, таймаути, ретраї з джиттером, outlier-ejection, PDB/HPA/KEDA, флоу відкатів.
7. Автоматизувати (включити в reg-пакет game-day/CI-перевірки інфраструктури).

5) Guardrails і критерії зупинки

• SLO fast-burn активований (наприклад, 14 × бюджет за 1 год),
• конверсія платежів ↓ більш ніж на 0. 3 п.п.,
• TTW p95> 3 хв поспіль 10-15 хв,
• error-rate > 1. 5% і росте в двох вікнах.
• Комунікації: заздалегідь затверджений канал/шаблон статусу, «червона кнопка» в ChatOps ('/experiment abort').

6) Приклади експериментів (Kubernetes/хмара)

6. 1 Мережеві затримки до PSP (канарний деплою)

Мета: перевірити ретраї/таймаути/маршрутизацію.
Ін'єкція: + 200 мс RTT і 3% packet loss тільки для'payments-api'→'pspX'.

yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius

Очікуване: p95 '/deposit'< 250 мс, error-rate <1%, конверсія ≥ baseline − 0. 3 п.п.; при погіршенні - авто-перемикання маршруту PSP.

6. 2 Відмова вузла і PDB

Мета: перевірити PDB/anti-affinity/HPA.
Ін'єкція: drain/terminate одного нода з подами'games-api'.

Очікування: немає втрати доступності, піковий p99 не виходить за SLO, autoscaler добирає репліки, PDB запобігає «подвійний удар».

6. 3 Kafka lag и KEDA

Мета: стійкість виведення коштів при накопиченні повідомлень.
Ін'єкція: заморозити консьюмерів на 5-10 хв, потім включити.

Очікування: KEDA масштабує воркери, TTW p95 залишається ≤ 3 хв після розсмоктування, немає дублікатів (ідемпотентність, ключі).

6. 4 DNS-збій провайдера ігор

Мета: fallback/кешування/ретраї.
Ін'єкція: NXDOMAIN/timeout для домену'providerA. example`.

Очікування: швидкий фолбек на'providerB', в UI - деградаційний режим і банер статусу;'game init success'≥ 99. 5%.

6. 5 Read-only БД

Мета: поведінка при втраті запису.
Ін'єкція: перемикання репліки в read-only на 10-15 хв.

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

7) Автоматизація та GitOps

Експерименти як код: зберігайте сценарії/параметри/guardrails в Git, рев'ю через PR.
План game-day: розклад, власники, метрики, abort-умови, чек-лист комунікацій.
Анотації в Grafana: старт/кінець експерименту, конфіг, підсумкові SLO.

8) Спостережуваність під час хаосу

Exemplars: з p95/p99 - в конкретні'trace _ id'.
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
Трейси: зовнішні виклики позначені'fault. injected = true', видно ретраї/таймаути.
Дашборди: «SLO-карта», release/experiment compare, Payments/Game init/Queues.

9) Специфіка iGaming: що перевіряти в першу чергу

1. Платежі і TTW: таймаути PSP, фолбек маршруту, ідемпотентність.
2. Ініціалізація ігор: недоступність/повільність студій, CDN-збої.
3. Черги висновків/бонусів: зростання lag, повторна обробка.
4. Мультирегіон: відмова зони/РОР, зміна лідера, реплікація БД.
5. Піки: авто-скейл, rate-limit, circuit-breaker, прогрівши кешів.
6. RG/Compliance: коректність логування при збоях, відсутність PII в телеметрії.

10) Управління ризиком (governance)

Календар та вікна: експерименти поза піковими турнірами, узгодження з бізнесом.
Ролі: Experiment Lead, Observer (SRE), Business Rep; IM на гарячій лінії.
Політики даних: ніякого PII в артефактах; WORM-сховища для аудиту.
Юридичні межі: виключити сценарії, що порушують SLA, без узгодження.

11) Game-day: шаблон сценарію

12) Типові знахідки та дії

Занадто агресивні ретраї → шторм запитів → додати таймаути/джиттер/ліміти.
Немає outlier ejection → «отруйний» інстанс псує p99 → включити вибраковку.
Крихкі міграції → read-only ламає потік → expand→migrate→contract + фічефлаги.
Неправильний HPA-сигнал → скейлиться пізно → перемкнути на метрики RPS/lag.
Кеш загальний для версій → відкати псують дані → версійні ключі.

13) Чек-лист зрілості хаос-практики

1. Steady-state і SLO описані, дашборди готові.
2. Експерименти як код, рев'ю/аудит в Git.
3. Guardrails/abort автоматизовані (Alertmanager/ChatOps).
4. Спостережуваність: exemplars, trace/log correlation, анотації.
5. Game-day щоквартально, сценарії покривають платежі/ігри/черги/мультирегіон.
6. Пост-експериментні action items входять в план спринту; контроль виконання.
7. Порогові політики ретраїв/таймаутів/circuit-breaker в конфіг-репо.
8. Сек'юріті/PII-політики дотримані, артефакти без чутливих даних.
9. Авто-ремедіації по SLO (rollback/scale/reroute) протестовані хаосом.
10. Метрики процесу: % пройдених без abort, MTTR на вправах, зниження інцидентів класу.

14) Анти-патерни

«Ламаємо все в проді» без SLO/guardrails/спостережуваності.
Експерименти без гіпотез і вимірних цілей.
Великий blast radius в перший запуск.
Ретраї без таймаутів/джиттера → каскадні відмовостійкості.
Хаос замість профілактики: лікуємо симптоми, ігноруємо кореневі причини.
Відсутність RCA/action items після вправ.
Експерименти в пікові години без узгодження з бізнесом.

Підсумки

Хаос-інжиніринг - це методичний доказ стійкості: ви заздалегідь відтворюєте реальні збої, вимірюєте вплив на SLO і бізнес-метрики і зміцнюєте архітектуру - від ретраїв і circuit-breaker до мультирегіональної оркестрації і auto-ремедіацій. При регулярних game-day і дисципліні guardrails платформа iGaming зберігає p95/p99, конверсію і TTW навіть в найгарячіші періоди.