Алертинг и реагирование на сбои
(Раздел: Технологии и Инфраструктура)
Краткое резюме
Сильный алертинг — это сигнал о нарушении пользовательской ценности, а не просто «красная метрика». Для iGaming важны SLO-гейты (латентность, доступность, конверсия платежей, Time-to-Wallet), multi-burn правила, четкие роли on-call, эскалации, ChatOps и runbooks. Цель — быстро увидеть отклонение, сообщить тем, кто сможет исправить, и зафиксировать знания, чтобы в следующий раз реагировать еще быстрее и дешевле.
1) Основы: от метрик к действиям
SLI → SLO → Alert: измеряемое качество → целевой уровень → условия «бюджет горит».
Severity (SEV): SEV1 — критическое (выручка/GGR под угрозой), SEV2 — серьезное, SEV3 — умеренное, SEV4 — минор.
Impact/Urgency: кто страдает (все/регион/тенант/канал) и насколько срочно (TTW↑, p99↑, error-rate↑).
Actionability: на каждую тревогу — конкретное действие (runbook + владелец).
2) Таксономия сигналов
ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
БизнесSLO: конверсия платежей (attempt→success), Time-to-Wallet (TTW), успешность ставок, запускаемость игр.
Платежные маршруты: PSP-специфические метрики (timeout/decline spikes).
Фронт/мобайл: RUM-метрики (LCP/INP), crash-rate, синтетика сценариев (логин/депозит/ставка/вывод).
3) Политика алертинга: SLO и burn-rate
Примеры SLI/SLO
Доступность `payments-api` ≥ 99.9% / 30d p95 `/deposit` ≤ 250 ms / 30d
Конверсия `payments_attempt→success` ≥ baseline − 0.3% / 24h
TTW p95 ≤ 3 мин / 24h
Multi-window / Multi-burn (идея PromQL)
Fast burn: нарушение SLO в 5–10× быстрее нормы (алерт-пейдж за 5–15 мин).
Slow burn: медленное выгорание бюджета (тикет + анализ за 1–3 ч).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4) Шумоподавление и качество сигналов
Правильный источник правды: алертить по агрегатам (recording rules), а не тяжелым «сырым» выражениям.
Дедупликация: Alertmanager группирует по `service/region/severity`.
Иерархия: сначала алерт на бизнес/SLI, ниже — техметрики как диагностика.
Супрессия: во время planned-maintenance/релиза (аннотации), при upstream-инцидентах.
Кардинальность: не используйте `user_id/session_id` в метках алертов.
Тест-алерты: регулярные «учебные» триггеры (проверка каналов, ролей, рунабук-ссылок).
5) Alertmanager: маршрутизация и эскалации
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]Идея: SEV=page → PagerDuty/SMS; остальное — Slack/тикет. Ингибиция подавляет «шумиху» низших уровней при активном SEV выше.
6) Grafana Alerting (как доп. слой)
Централизованные Alert rules на дашбордах (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silences: плановые работы, миграции, релизы.
Snapshots с авто-скриншотом панели в тикет.
7) On-call и «живые» процессы
Ротация: 1-я линия (SRE/платформа), 2-я линия (владелец сервиса), 3-я (DB/Payments/Sec).
SLA реакции: признание ≤ 5 мин (SEV1), диагностика ≤ 15 мин, коммуникации каждые 15–30 мин.
Дежурные каналы: `#incident-warroom`, `#status-updates` (только факты).
Runbooks: ссылка в каждом алерте + быстрые команды ChatOps (`/rollback`, `/freeze`, `/scale`).
Учебные тревоги: ежемесячно (проверка людей, каналов, рунабук-актуальности).
8) Инциденты: жизненный цикл
1. Детект (алерт/репорт/синтетика) → Acknowledge on-call.
2. Триаж: определить SEV/затронутых/гипотезу, открыть war-room.
3. Стабилизация: рулбуки/откат/масштабирование/фичефлаги.
4. Коммуникации: шаблон статуса (см. ниже), ETA/следующие шаги.
5. Закрытие: подтверждение восстановления SLO.
6. Post-Incident Review (RCA): через 24–72 ч, без обвинений, action items.
- Что сломано / кого затронуло (регион/тенант/канал)
- Когда началось / SEV
- Временные меры (mitigation)
- Следующее обновление статуса через N минут
- Контакт (Инцидент-менеджер)
9) Специфика iGaming: «болевые» зоны и алерты
Payments/TTW: доля таймаутов PSP, рост отказов по коду, TTW p95>3м.
Пики турниров: p99 API/время старта игр/queue lag; пропагация лимитов/авто-скейл.
Выводы средств: SLA бэкофиса/ручных проверок, лимиты по странам.
Провайдеры игр: доступность по студиям, время инициализации сессии, падение запусков.
RG/Compliance: всплески длительных сессий/«догон», превышение порогов — не пейдж, а тикет + уведомление RG-команде.
10) Примеры правил (дополнительно)
Высокая латентность p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"Очередь выводов «горит»
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"Конверсия платежей просела
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11) ChatOps и автоматизация
Авто-постинг алертов с кнопками действий: Stop canary, Rollback, Scale +N.
Командные сокращения: `/incident start`, `/status update`, `/call
Боты подтягивают контекст: последние деплои, граф зависимостей, трейс-примеры (exemplars), связанные тикеты.
12) Пост-инцидентная работа (RCA)
Факты: таймлайн, что видели/что пробовали, что сработало.
Root cause: технические и организационные причины.
Detections & Defenses: какие сигналы помогли/подвели.
Action items: конкретные задачи (SLO/алерты/коды/лимиты/тесты/рунабук).
Due dates & owners: сроки и ответственные; follow-up-сессия через 2–4 недели.
13) Чек-лист внедрения
1. Определите SLI/SLO для ключевых потоков (API/Payments/Games/TTW).
2. Настройте recording rules и multi-burn алерты + маршрутизацию Alertmanager.
3. Введите on-call с ротацией, SLO реакций и эскалациями.
4. Привяжите алерты к runbooks и ChatOps-командам.
5. Настройте подавления/тихие окна, аннотации релизов/работ.
6. Сделайте учебные тревоги и game-day сценарии (падение PSP, рост p99, рост queue lag).
7. Мерьте Alert Quality: MTTA/MTTR, % noisy/false, coverage по SLO.
8. Регулярные RCA и пересмотр порогов/процессов.
9. Введите статус-коммуникации с бизнесом/саппортом (шаблоны).
10. Документируйте все как код: правила, маршруты, рунабук-ссылки.
14) Анти-паттерны
Алертинг по «каждой метрике» → алерт-фэтиг, игнор.
Нет SLO → непонятно, что «норма» и что «горит».
Отсутствие подавлений/ингибиции → лавина дубликатов.
Пейдж ночью за минорные события (SEV несопоставим с Impact).
Алерты без runbook/владельца.
«Ручные» действия без ChatOps/аудита.
Нет RCA/Action items → повтор инцидентов.
Итоги
Алертинг и реагирование — это процесс, а не набор правил. Свяжите SLO с multi-burn-алертами, выстроите ясную on-call-эскалацию, добавьте ChatOps и живые рунабук-и, регулярно проводите RCA и учебные тренировки. Тогда инциденты будут реже, короче и дешевле, а релизы — предсказуемее даже в горячие часы iGaming.