Операції та Управління → Запобігання інцидентів

Запобігання інцидентам

1) Навіщо це потрібно

Найкраща реакція на інцидент - це його відсутність. Для iGaming/фінтеху кожна хвилина простою - втрачені ставки/депозити, штрафи від провайдерів, репутаційні ризики. Системна профілактика знижує Change Failure Rate, стабілізує SLO і вивільняє час команд для розвитку, а не гасіння пожеж.

• Звести до мінімуму ймовірність інцидентів на критичних шляхах (депозит, ставка, запуск гри, висновок).
• Перехоплювати деградації до удару по SLO і гаманцю.
• Обмежити радіус відмови (blast radius) і прискорити відновлення.

2) Базові принципи профілактики

1. SLO-first и error budget: зміни не випускаються, якщо ризикують вибити SLO і спалити бюджет.
2. Defence in depth: шари захистів - від схем даних і конфігів до мережевих політик і фічефлагів.
3. Design for failure: брейкери, таймаути, ретраї з джиттером, ідемпотентність, деградації.
4. Small & reversible changes: маленькі інкременти + швидкий відкат (feature flags/канарка).
5. Observability by design: метрики/логи/трейси для кожного критичного кроку і зв'язку.

3) Карта ризиків і критичних шляхів

Складіть «карту болю» за доменами: Payments, Bets, Games, KYC, Promotions, Jackpots, Content.

• Бізнес-метрики (конверсія, GGR, середній чек).
• Технічні SLO (latency p95/p99, uptime, success rate).
• Залежності (внутрішні/зовнішні), ліміти/квоти.
• «Safe mode» поведінка (що відключаємо/спрощуємо).
• Runbook власника.

4) Guardrails (захисні бар'єри)

Таймаути і брейкери: у викликаючого сервісу таймаут коротше суми внутрішніх; брейкер відкривається при зростанні помилок/латентності.
Bulkhead-ізоляція: окремі пули з'єднань/воркерів на даунстрими.
Rate limit & backpressure: захист від лавин і ретрай-штормів.
Фічефлаги деградації: «мінімальний режим» - легкі відповіді, кеш-реплаї, відключення важких фіч.
Мульти-вендор і фейловер: альтернативні PSP/KYC, перемикання маршрутів.
Валідація конфігів: схеми/лінери/політики для безпечної зміни фіч і лімітів.

5) Управління змінами (Change Management)

Pre-release gates: тести, безпека, CDC (consumer-driven contracts), сумісність схем.
Канарний реліз + автогейти: 1% → 10% → 100%; авто-стоп при зростанні p99/error rate/бюджету згоряння.
Feature flags: миттєвий відкат/перемикання поведінки без деплоя.
Release calendar: уникаємо пікових вікон спорту/турнірів і maintenance у провайдерів.
Post-deploy checks: автосмок, порівняння метрик «до/після» з порогами.

6) Тестування як превентивна міра

Unit/contract/integration: контракти OpenAPI/AsyncAPI, CDC проти провайдера/мока.
Load & stress: профілі трафіку для прайм-тайму; тести на ліміти конектів/IOPS/квот.
Soak/long-haul: витоку ресурсів, зростання затримок на горизонті годин/днів.
Chaos/game-days: падіння брокера/PSP/KYC, розрив регіону, «повільний провайдер».
Disaster Recovery Drills: регулярні тренування перемикання регіонів і відновлення БД.

7) Раннє виявлення деградацій

Capacity-alerts: headroom, лаги черг, коннекти БД, eviction в кешах.
SLO-burn-rate: сигнал при небезпечній швидкості «спалювання» бюджету.
Адаптивні пороги: сезонність/добові шаблони для зниження помилкових.
Складові алерти: «lag ↑ + HPA at max + open circuit» ⇒ високий ризик.
Vendor health: квоти/таймаути/помилки по кожному провайдеру + вартість викликів.

8) Робота з зовнішніми провайдерами

OLA/SLA ↔ SLO: прив'язка домовленостей до наших цілей.
Playbooks фейловера: маршрути PSP-X ⇆ PSP-Y, кеш токенів, grace-режими депозитів.
Сендбокси та контракти: тестові флоу перед кожною мажорною зміною.
Вікна провайдерів: анотації на дашбордах і автоматичні suppress-правила.

9) Дані, конфіги та секрети

Політики змін: code-review двох пар очей, валідація схем/JSON/YAML.
Секрети: KMS/Secrets Manager, ротація, поділ по оточеннях/ролях.
Прапори/ліміти: зміна через API з аудитом і миттєвим відкатом.
Міграції: «двошагові» (expand → migrate → contract), сумарна зворотна сумісність.

10) Навчання та готовність команд

On-call тренінги: симуляції інцидентів, Shadow-чергування, централізовані runbook'і.
Єдині формати комунікацій: шаблони статусів/хендоверів/інцидент-апдейтів.
Безпечна культура: постмортем без звинувачень, механістичні причини і превентивні дії.

11) Дашборди профілактики (мінімум)

Risk & Readiness: SLO/бюджет, headroom по шарах, «топ вразливих зв'язків».
Change Safety: відсоток канарок, відкати, алерти «після релізу», CTR автогейтів.
Vendor Panel: p95/error/квоти/вартість по кожному провайдеру, час відповіді саппорту вендора.
Chaos/DR Readiness: частота вправ, час перемикання регіону, успішність відновлень.
Config/SecOps: зміни прапорів/лімітів/секретів, аномалії.

12) Приклади превентивних алертів

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) Чек-лист запобігання (щодня/перед піками)

• Актуальний календар піків (матчі, турніри, кампанії, вікна провайдерів).
• Headroom по API/БД/кешам/чергах, готовність HPA/VPA, прогрівши кешів.
• Стан провайдерів (квоти, ліміти, деградації за 24год), налаштований фейловер.
• Канарські гейти включені, фічефлаги відкату доступні власникам.
• Алерти SLO/Capacity активні, suppression прописаний на планові роботи.
• Runbook'і оновлені, on-call підтверджений, канали ескалацій робочі.

14) Анти-патерни (чого уникати)

«Великі нічні релізи» без канарки і прапорів.
Загальні пули потоків на всі даунстрими (head-of-line blocking).
Ретраї на неідемпотентні операції і на таймаути вузьких місць.
Відсутність гістерезису в алертах → пиляння по порогу.
Сліпа віра в SDK вендора без спостережуваності і управління таймаутами.
«Зробимо в проді» без стейджа/сандбокса і CDC.

15) KPI профілактики

Change Failure Rate (мета ≤ 10-15% або ваша цільова).
Pre-Incident Detect Rate: частка інцидентів, попереджених на стадії деградації.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage захистів: % критичних шляхів з прапорами/брейкерами/таймаутами/канаркою.
Chaos/DR cadence: частота і успішність навчань.
Vendor readiness: середній час перемикання на резервного провайдера.

16) Швидкий старт (30 днів)

Тиждень 1: карта критичних шляхів, SLO і власники; включити SLO-burn-алерти і capacity-алерти.
Тиждень 2: канарні гейти + фічефлаги; базові chaos-сценарії (провайдер/черга).
Тиждень 3: дашборди «Change Safety» і «Vendor Panel», фейловер-плейбуки.
Тиждень 4: DR-навчання (часткове), ретроспектива і план hardening'a на квартал.

17) Шаблони (фрагменти)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

Q: Що впровадити в першу чергу, якщо ресурсів мало?
A: SLO-burn-алерти на критичних шляхах, канарські гейти і фічефлаги відкату; потім - карта ризиків і фейловер провайдерів.

Q: Як зрозуміти, що профілактика «працює»?
A: Знижується Change Failure Rate, зростає частка попереджених інцидентів, падає MTTR і шум алертів, зменшується кількість «нічних» пейджів.

Q: Чи потрібні регулярні chaos-навчання?
A: Так. Без тренування фейловер і DR майже завжди довше і болючіше, ніж здається на папері.