Алертинг і реагування на збої
(Розділ: Технології та Інфраструктура)
Коротке резюме
Сильний алертинг - це сигнал про порушення користувальницької цінності, а не просто «червона метрика». Для 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) Таксономія сигналів
TexSLO: 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. Комунікації: шаблон статусу (див. нижче), ЕТА/наступні кроки.
5. Закриття: підтвердження відновлення SLO.
6. Post-Incident Review (RCA): через 24-72 год, без звинувачень, action items.
- Що зламано/кого торкнулося (регіон/тенант/канал)
- Коли почалося/SEV
- Тимчасові заходи (mitigation)
- Наступне оновлення статусу через N хвилин
- Контакт (Інцидент-менеджер)
9) Специфіка iGaming: «больові» зони та алерти
Payments/TTW: частка таймаутів PSP, зростання відмов за кодом, TTW р95> 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.