Алерти в реальному часі
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 «stavka→settl»> 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> X днів.
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: domen→kanal→eskalatsii, резервні контакти.
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, захищає виручку і одночасно береже он-колл від «пейджер-пекельної» рутини.