Операції та Управління → Передбачення інцидентів

Передбачення інцидентів

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

Інциденти рідко «вибухають з нізвідки». Перед відмовою платформа подає сигнали: прискорене зростання p99, повільне вигорання error-бюджету, лаги черг, зростання ретраїв на конкретному даунстрімі, наближення квот провайдера. Системне передбачення інцидентів переводить реакцію з «гасіння пожежі» в «раннє втручання», знижуючи MTTR, Change Failure Rate і втрати виручки.

• Виявляти патерни провісників і автоматично ініціювати профілактичні дії.
• Зменшити частку P1/P2 за рахунок зсуву вліво (pre-incident detect rate).
• Вбудувати передбачення в процеси релізів, фейловера і capacity-попереджень.

2) Карта сигналів (lead indicators)

• Прискорення p95/p99 (градієнт), «хвости» затримок, зростання варіації.
• Черги/стріми: зростання'lag'і позитивна похідна lag; HPA на максимумі.
• БД/кеш: `active_conns/max_conns`, `replication_lag`, `evictions`, падение `cache_hit`.
• Мережа: помилки mTLS/handshake, зростання 5xx/timeout назовні.

• 'outbound _ error _ rate '/' retry _ rate'до конкретного провайдера,'circuit _ open','quota _ usage> 0. 9`.
• SLA провайдера: планові вікна, деградації.

• Аномальне навантаження (кампанії/матчі), стрибки RPS/TPS, незвичайні мікси регіонів/каналів.
• Конверсія депозитів/ставок падає при зростанні p99 → квазі-проксі інциденту.

• Burn-rate error-бюджету> порогу (наприклад,> 4 × протягом 10-15 хв).
• Часті дрібні порушення SLO (мікро-деградації) як маркер збою, що наближається.

3) Джерела та вітрини даних

Онлайн-телееметрія: Prometheus/OTel (метрики, логи, трейси).
Події інцидентів: тікети/статуси/постмортеми (істина для таргета).
План/факти змін: релізи, фічефлаги, міграції, вікна провайдерів.
Довідники: карта залежностей, квоти, власники.
DWH-знімки: агрегати для навчання/валідації (синхронна віконність!).

Вимоги до якості: повнота ≥99%, годинне/хвилинне вирівнювання TZ, єдині визначення p95/p99.

4) Підходи до передбачення

4. 1 Непараметричні/правила (швидкий старт)

Порогові алерти на швидкість зміни: 'deriv (p99)','z-score'для коротких вікон.
Композитні умови: `lag↑ + HPA=max + circuit_open(to="PSP-X")`.
SLO-burn-гейти: останів релізу/канарки при burn-rate> X.

4. 2 Детекція аномалій

Seasonal baselines (STL/Prophet-подібні ідеї), rolling медіана + MAD.
Multivariate: спільна аномалія'p99 + retry + open_circuit + quota'.
Change-point detection: CUSUM/BOCPD для зрушень трендів.

4. 3 ML-моделі (supervised)

Класифікація «інцидент в T + K?» по вікну ознак (наприклад, за 10-30 хв до).
Ознаки: статистики, похідні, сезонні залишки, one-hot провайдерів/регіонів, прапори релізів.
Мітки: 'incident{severity∈[P1,P2]}'в інтервалі [t, t + K].
Explainability: SHAP/Permutation importance для довіри та операційності.

4. 4 SRE-first гібрид

Модель → скоринг ризику (0-1) → політика дій (фічефлаги/фейловер/пред-скейл), з HITL для критики.

5) Проектування ознак (feature engineering)

Ковзні вікна (1/5/15 хв): mean, p95/p99, std, max, slope.
Відносні показники: `p99/baseline_1d`, `error_rate_delta`.
Когортні фічі: провайдер, регіон, тип гри/матчу, канал пристрою.
«Навантажувальні» фічі: RPS, payload size, кількість відкритих WS.
Системні: `hpa_desired/max`, `db_conn_ratio`, `redis_evictions>0`.
Подієві прапори: «йде реліз», «канарка 10%», «вікно провайдера».

6) Механіка передбачень і дії

1. Скоринг ризику кожні N секунд по доменах (Payments/Bets/Games/KYC).

• ризик ≥ 0. 8 + підтверджуючі сигнали → page власника домену;
• 0. 6–0. 8 → попередження + підготовка заходів.

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

4. HITL: людина підтверджує заходи рівня «зміна бізнес-поведінки».

7) Інтеграція в щоденні процеси

Релізи: предиктивні гейти на канарках (порівняння «до/після» і ризик-скоринг).
Фейловер: автоматична підготовка/прогрів резервного маршруту при ризику провайдера.
Capacity: «early uplift» при падінні headroom і зростанні лагів.
Сповіщення: окрема стрічка «pre-incident» + анотації в дашбордах.

8) Спостережуваність і дашборди

Risk Overview: ризик по доменах і провайдерам, тенденції, внесок ознак.
Lead Signals: top-N провісників (градієнт p99, lag, відкриті брейкери).
Actions & Outcomes: що включилося, ефект на p95/error, скасовані інциденти.
Model Health: precision/recall/latency, drift ознак, частота автодій.

9) Метрики якості передбачень

Recall @P1/P2 (чутливість щодо критичних інцидентів).
Precision (менше «помилкових пейджів»).
Lead Time (медіана «скільки хвилин до факту»).
Intervention Win-rate (частка випадків, де дія знизила ризик/витрати).
Alert Fatigue Index (алертів/зміна/чол).
Drift Score (стат. відмінності розподілів ознак vs навчального періоду).

Типові цілі: Recall(P1) ≥ 0. 7, Precision ≥ 0. 6, Lead Time медіана ≥ 8-10 хв.

10) Управління ризиками моделі (ML Ops/Governance)

Версіонування даних/коду/артефактів, відтворюваність.
Champion/Challenger: нова модель йде паралельно, порівняння оффлайн/онлайн.
Дрейф: PSI/KL-дивергенція, авто-перелік порогів, алерт «модель застаріла».
Explainability: для кожного рішення зберігати важливості ознак і посилання на дані.
Безпека/етика: доступи, PII-маскування, контроль автодействий політиками.

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

policy:
if slo_burn_rate{service="payments"} > 4 for 10m and release_phase in ["canary", "post-deploy_30m"]:
action: pause_release_and_rollback notify: squad-payments

risk_psp_x = sigmoid(
1. 2z(outbound_p99_ms) +
1. 5z(outbound_error_rate) +
0. 8z(retry_rate) +
1. 0I(quota_usage>0. 9) +
0. 7I(circuit_open=1)
)
if risk_psp_x > 0. 8 for 5m -> route_to_psp_y + reduce_features

if (consumer_lag > 5e6 and deriv(consumer_lag) > 5e4) and hpa_desired == hpa_max:
action: scale_consumers + throttle_producers + enable_batching

12) Чек-лист впровадження (30-60 днів)

Каталог сигналів і «істини» по інцидентах (severity, таймлайни).

• Базові лінії і сезонність для ключових метрик (до/після релізу).
• Правила ранніх сигналів (градієнти p99, lag, burn-rate).
• Дашборди Risk/Lead Signals/Actions.
• Інтеграція з фічефлагами/канарками, перед-скейл HPA.
• Пілот ML-класифікатора на одному домені (наприклад, Payments).
• Політики HITL і журнал автодействий.
• Метрики якості та алерти на дрейф/здоров'я моделі.

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

«Кришталеві кулі»: складна ML-модель без базових ліній і простих правил.
Немає actionability: пророкуємо «погано», але не робимо нічого автоматично.
Ігнор сезонності/календаря подій (матчі/турніри) → помилкові тривоги.
Змішування зон часу → невірні вікна метрик/інцидентів.
Відсутність explainability → недовіра, відключення передикту командами.
Єдиний глобальний поріг на всі домени/регіони → низька точність.

14) Специфіка доменів (iGaming)

Payments: провайдери/квоти, зростання'retry _ rate'і'circuit _ open'→ ранній фейловер.
Bets: затримка оновлення коефіцієнтів, зростання WS-фан-ауту → ліміт широкомовлень.
Games/Live: сплески з'єднань, ліміти студій → деградація UI/кеші.
KYC/AML: затримки webhook, черги верифікацій → HITL і відкладена обробка.

15) Приклади метрик і алертів (ідеї)

ALERT PreIncidentRiskHigh
IF risk_score{domain="payments"} > 0. 8 FOR 5m
LABELS {severity="critical", team="payments"}

ALERT LeadSignalP99Slope
IF deriv(api_p99_ms{service="bets"}[5m]) > 15 AND api_p99_ms > baseline_1d 1. 2 FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderEarlyQuota
IF usage_quota_ratio{provider="psp_x"} > 0. 85 FOR 10m
LABELS {severity="info", team="integrations"}

ALERT StreamLagStorm
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"}

16) KPI програми передбачень

Pre-Incident Detect Rate (частка попереджених/пом'якшених інцидентів).
Avg Lead Time до інциденту.
Reduction in P1/P2 кв/кв.
MTTR (очікувано ↓ за рахунок раннього контексту).
False Alarm Rate/Alert Fatigue (стабільно ↓).
Cost Avoidance (оцінка попереджених втрат/штрафів/оверскейлу).

17) Швидкий старт (рецепт)

1. Увімкніть градієнтні правила на p99/lag і SLO-burn;

2. Додайте композитні умови для провайдерів;

3. Зв'яжіть предикт з фічефлагами і пред-скейлом;

4. Звіт «передбачення → дію → ефект»;

5. Пілот ML в одному домені; масштабуйте після зростання Precision/Recall.

18) FAQ

Q: З чого почати без ML?
A: Сезонні базові лінії + градієнти + композитні правила. Це дає помітний приріст Recall без складнощів.

Q: Як не потонути у фолс-позитивах?
A: Комбінувати сигнали, вводити гістерезис і час підтвердження, налаштовувати пороги per-домен/регіон, оцінювати Precision і Alert Fatigue.

Q: Які дії автоматизувати першими?
A: Безпечні та оборотні: перед-скейл, включення кешів/деградації, пауза/ролбек канарки, перемикання провайдера при підтверджених сигналах.