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 и метрики успеха

ТехSLI: 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. Мультирегион: отказ зоны/POP, смена лидера, репликация БД.
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 даже в самые горячие периоды.