Операции и Управление → Предсказание инцидентов

Предсказание инцидентов

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: Безопасные и обратимые: пред-скейл, включение кэшей/деградации, пауза/роллбек канарейки, переключение провайдера при подтвержденных сигналах.