Алерты в реальном времени
1) Цель и принципы
Цель: вовремя, точно и адресно уведомлять нужных людей/системы о событиях, угрожающих SLO, выручке и комплаенсу, и запускать корректные действия (ручные/автоматические).
Принципы: SLO-first, минимизация шума, объяснимость, контекст, приоритизация по бизнес-влиянию, “один сигнал — одно понятное действие”.
2) Таксономия сигналов
SLO-сигналы: burn-rate бюджета ошибок по критичным путям (логин, депозит, ставка, вывод).
KRI: ранние индикаторы риска (падение auth-success у PSP по банку/GEO, рост consumer-lag, p99↑).
Событийные: флапы зависимостей, failover, ручные переключения, срабатывание защит (rate-limit, WAF).
Безопасность/комплаенс: всплеск чувствительных операций, экспорт PII, нарушения SoD.
3) Уровни и SLA оповещений
4) Источники и корреляция контекста
Телеметрия: метрики/трейсы/логи, синтетика и RUM.
Каталоги: CMDB/сервис-мапа, владельцы, зависимости.
Изменения: релизы, фичфлаги, миграции, плановые работы.
Внешние провайдеры: PSP/KYC/игровые студии/CDN/WAF статусы.
Каждый алерт обогащается: что изменилось рядом? (релиз/фичфлаг), какие зависимости красные?, какой сегмент затронут? (GEO/PSP/банк/тенант).
5) Правила SLO-алертинга (ядро)
Burn-rate: два окна (быстрое 1ч и медленное 6–24ч). Пейджер — только при одновременном превышении.
Guardrails: пороги по p99/error-rate служат лишь триггерами контекстного анализа, не заменяют SLO.
Импакт: оценка “доля аудитории × деньги/мин × регуляторика” → уровень P1–P4.
6) Подавление шума
Дедупликация: группировка по сервису/тенанту/причине; расшариваем один инцидент вместо десятков сигналов.
Гистерезис: N-из-M подтверждений, минимальная длительность аномалии.
Сайленсы/мьюты: плановые работы, известные инциденты, “follow-the-sun” окна.
Рейт-лимиты и квоты: на источник/лейбл/тенант; защита от “шторма”.
Снижение кардинальности: запрещен userId/sessionId в алерт-лейблах.
7) Маршрутизация и эскалации
Роутинг по контексту: домен (Payments/Games/Core), окружение (prod/stage), регион, тяжесть.
Эскалации: t0 — on-call L1; t0+X — L2/доменный владелец; t0+Y — IC/руководство. Время X/Y зависит от P1–P3.
Дублирование по каналам: pager+чат при P1; чат/тикет при P3.
Смена смены: авто-передача контекста (timeline, выполненные действия, гипотезы).
8) Авто-действия (auto-remediation)
Платежи: переключение PSP по health×fee×conversion, ограничение банков/методов, ретраи с джиттером.
Игры/ставки: включить кэш-wedge/ограничить write-операции, queue-page/waiting-room на фронте.
Инфра: эвакуация трафика, рестарт деградирующих воркеров, масштабирование по lag.
Безопасность/комплаенс: временно закрыть экспорт PII, ввести dual-control для операций P1.
Любое авто-действие — с политикой отката и критериями возврата.
9) Runbook-первый опыт
Каждый алерт связан с runbook: цель, быстрая диагностика (3–5 проверок), шаги фикса/отката, контактные лица, ссылки на дашборды и статус-страницу. В чате/пейджере показываем краткую карточку действий.
10) Он-колл политика
Ротация 24×7, покрытие доменами (Payments/Game Core/SRE).
“Second on-call” для P1, правило двух человек в вар-руме.
Quiet-hours и дежурные окна по зонам (follow-the-sun).
Обучение: ежеквартальные учения (tabletop/game-day), shadow-смены.
Пост-инцидентные кредиты (comp-тайм), чтобы избежать выгорания.
11) Интеграции
Инцидент-менеджмент: авто-создание карточек, ленты апдейтов, роли IC/CL, таймеры.
Статус-страница: публикация P1/P2 (через Comms Lead) с шаблонами и локализацией.
Релизы: release-gates по SLI, авто-стоп/rollback при алертах.
Каталоги: владельцы, CMDB, контакты провайдеров.
12) Примеры алертов (iGaming)
1. Auth-success у PSP-1 в TR↓ на 25% за 10 мин
P2→P1 при охвате >30% транзакций.
Авто-действие: перераспределить трафик PSP-2/3; включить упрощенный 3DS; алерт Partner Manager.
2. p99 “ставка→сеттл” > 3× нормы в EU
Причины: lag репликации, очередь воркеров.
Авто-действие: scale-out воркеров, warmup кэша, временно выключить не-критичные фичи.
3. Export PII spikes
P1 при отсутствии тикета/одобрения.
Авто-действие: блок выгрузок, уведомление Compliance, проверка SoD.
13) Метрики качества алертинга (KPI/KRI)
MTTA-Comms / MTTA-Ops: время до реакции/первого действия.
Precision/Recall (алерт ↔ инцидент), False Alarm Rate.
Lead-time до нарушения SLO, TTD (время обнаружения).
Pager fatigue: алертов/чел/нед., ночные вызовы, процент “пустышек”.
Auto-fix rate: доля проблем, закрытых авто-реакцией без человека.
Aging: доля висящих P3/P4>Х дней.
14) Управление стоимостью
Квоты на алерты/источники, отсечение избыточных лейблов.
Downsampling и агрегация метрик, семплинг трасс; ретенции по классам.
Регулярный cost-review: $/алерт, $/SLI-дашборд, “тяжелые” серии.
15) Приватность и комплаенс
Без PII в тексте алертов и лейблах; токенизация идентификаторов.
Политики доступа (RBAC/ABAC), SoD на конфигурации алертов.
Аудит изменений правил, версионирование, тесты и дифф.
16) Дорожная карта внедрения (6–10 недель)
Нед. 1–2: каталог SLI/KRI, карта владельцев, уровни P1–P4, первые SLO-правила (burn-rate).
Нед. 3–4: дедуп/гистерезис/сайленсы, интеграция с инцидент-системой и чатами, runbook-связки.
Нед. 5–6: авто-действия для Payments/Queues, release-gates, статус-страница фид.
Нед. 7–8: контекст (релизы/фичфлаги/провайдеры), теплокарты PSP×банк×GEO, учения P1/P2.
Нед. 9–10: FinOps алертинга, KPI-дашборды, пересмотр порогов и квот, обучение он-колла.
17) Артефакты и шаблоны
Alert Spec: метрика/условие, окна, подавление, владелец, runbook, авто-действия.
Routing Map: домен→канал→эскалации, резервные контакты.
Silence Policy: правила мьюта (плановые/известные инциденты), кто может включать.
On-call Handbook: ротации, смена смены, чек-листы P1/P2, каналы.
Post-Incident Pack: выгрузки алертов/временные линии, анализ качества сигналов.
18) Антипаттерны
Пейджер по “сырым” p95/p99 без SLO → шум и усталость.
Десятки сигналов про одно и то же (нет дедупа/корреляции).
Отсутствие runbook или владельца у алерта.
Порог “в камне” без сезонности/сегментации (GEO/PSP/банк/час).
Без возврата после авто-действий (нет критериев roll-back).
Лейблы с PII и userId → риски и взрыв кардинальности.
Итог
Реально полезный алертинг — это SLO-центричный конвейер: контекстные правила с burn-rate, умное подавление шума, четкий роутинг и эскалации, runbook-первый опыт и безопасные авто-действия. Такой контур ловит критичные события раньше пользователей, снижает MTTR, защищает выручку и одновременно бережет он-колл от “пейджер-адской” рутины.