Система повідомлень і алертів

(Розділ: Операції та Управління)

1) Призначення та принципи

Мета - доставляти мало, але влучно: тільки релевантні сигнали, своєчасно і відповідальній людині/роботу зі зрозумілим next-step.

• Actionable by default: у кожного алерта є власник, пріоритет, термін реакції і кнопка дії.
• SLO-first: алерти будуються навколо SLI/SLO, а не навколо довільних метрик.
• Noise-control: дедуп, кореляції, придушення шторму.
• Context-rich: метадані (регіон, тенант, версія, trace_id) і посилання на рунбук.
• Audit-ready: всі алерти і реакції квітуються і зберігаються в незмінному журналі.

2) Джерела сигналів

Тих. телеметрія: доступність, p95/p99, error-rate, лаг черг, ресурсні ліміти.
Бізнес-івенти: PriceMismatch, WebhookLag, RTP Drift, фрод-сигнали.
Безпека/комплаєнс: SoD-порушення, PII-доступ, експірація ключів/сертифікатів.
Планувальник: прострочені SLA завдань, DLQ-лавини, retry-storms.

3) Класифікація та пріоритети

Guardrails: алерти формулюються відносно SLO/бюджету помилок (burn rate).

4) Роутинг і ескалації 24 × 7

Роутинг за контекстом: `region/tenant/product/provider/severity`.
Ескалаційні сходи: on-call інженера → командний лід → Duty Manager → Exec/Legal (для PII/фінансів).
Чергування: ротації за ролями (SRE, App, Data, Security, Payments), резервні контакти (чат/голос/SMS).
Вікна тиші: нічні, релізні, маркетингові; винятки для P1.

5) Шумозаглушення і кореляції

Дедуплікація: по `(fingerprint, region, tenant, route)` и `trace_id`.
Супресія «шторму»: тимчасове придушення дублікатів при активному P1.
Кореляції: групування сигналів навколо кореневої причини (реліз/фіча/провайдер).
Гістерезис: вхід/вихід з порога - різні, щоб уникнути «пилки».

6) Контент алерта (шаблон)

Заголовок: коротко і предметно - "EU/Checkout: p95>250ms (SLO breach)».
Ключові поля: пріоритет, час, регіон, тенант, версія, trace_id, affected%, -. Причина.
Що робити зараз: перші 1-3 кроки + посилання на рунбук/кнопки (Re-route, Rollback, Pause Promo).
Наступна комунікація: через N хвилин, власник (IC/он-колл).

7) Канали доставки

Чат/месенджер: основний канал тріажу (бот-картки з кнопками).
Пейджер/голос/SMS: для P1.
Пошта: звіти і non-urgent (P3/Info).
Вебхуки: інтеграції з тікетингом/оркестраторами.
Статус-сторінка: зовнішнє повідомлення клієнтів і партнерів.

8) Інтеграції та «кнопки дій»

Інцидент-бот: створює картку, призначає IC, відкриває відеоміст, стартує таймери.
Руни (auto-actions): Re-route, Rollback, Raise Limit, Flush Cache, Disable Webhooks, Enable Safe Mode.
Права: запуск рун обмежений ролями; всі дії підписуються і логуються.

9) Мультирегіон і multi-tenant

Незалежні SLO/пороги по регіонах; локальні інциденти не «фарбують» весь світ.
Фільтри видимості: партнери/тенанти бачать тільки своє.
Юрисдикційні вимоги: тексти сповіщень, мови, часові пояси.

10) Політики, розклади, вікна тиші

Політика алертів: власники, пороги, канали, ескалації, шаблони.
Календарі: робочий/неробочий час, релізні/маркетингові вікна.
Change freeze: пом'якшення порогів або придушення «не-P1» під час великих акцій.

11) Аудит та юридична фіксація

Квитанції: для критичних алертів - «receipt _ hash» і DSSE-підпис.
WORM-журнали: незмінне зберігання подій і реакцій (хто підтвердив, що зробив).
Chain-of-custody: трасування ескалацій і рішень.

12) Метрики та SLO системи повідомлень

MTTA (acknowledge): P1 ≤ 5-10 хв; P2 ≤ 30 хв.
Page rate / On-call load: сигналів на зміну - в цільовому діапазоні.
False Positive %: ≤ цільового порогу (зазвичай <10-15%).
Correlation efficiency: частка згрупованих сигналів ≥ 80%.
Delivery SLO: чат ≥ 99. 9%, SMS/голос ≥ 99. 5%.
Time-to-Action: p95 на запуск руни від алерта.

13) Дашборди і репорти

Оперативний: активні інциденти, burn-rate, карта регіонів/тенантів, черга алертів.
Якість алертів: шум, FP, ретести порогів, «німі зони».
Навантаження on-call: частота пейджів, час реакції, «out of hours».
Пост-інцидент: ефективність рун, повторюваність причин.

14) Специфіка iGaming/фінтех

Payments/PSP: P1 - відмова провайдера, зростання відмов авторизацій; авто-роут на резервного PSP.
RTP & Limits: альберти на дрейф спостережуваного RTP, перевищення лімітів, підозрілі патерни виграшів.
Афіліати/вебхуки: лаг доставки, зростання дублів, падіння підтверджених квитанцій.
Price/FX/Tax: невідповідність vitrina↔checkout, розсинхрон версій артефактів.
Відповідальна гра: RG-тригери та їх своєчасна ескалація на підтримку/Compliance.

15) RACI

16) Чек-лист впровадження

• Визначити North-Star і SLI/SLO; зв'язати алерти з burn-rate.
• Ввести каталог політик: пороги, канали, ескалації, вікна тиші.
• Реалізувати дедуп, кореляції, гістерезис, придушення шторму.
• Налаштувати мультирегіональні і multi-tenant правила видимості.
• Підключити «кнопки дій» і рунбуки; обмежити права запуску.
• Включити WORM/квитанції, трасування trace_id і rун-аудит.
• Побудувати дашборди якості (noise, FP, MTTA, page rate).
• Провести GameDay: PSP outage, WebhookLag, PriceMismatch, RTP Drift.
• Регулярно переглядати пороги; A/B порогів на «німих» метриках.
• Звіт по on-call навантаженні і поліпшень щомісяця.

17) Плейбуки (референс)

PSP Outage (P1): авто-роут на резерв, зниження таймаутів клієнтів, карантин «сірих» транзакцій, статус-апдейт через 15 хв.
WebhookLag (P2): збільшити воркери/батч, пріоритизація черг, тимчасова пауза необов'язкових ендпоінтів.
PriceMismatch (P1/P2): форс-інвалідація кешу, звірка'fx _ version/tax _ rule _ version', відкат артефакту, компенсації.
RTP Drift (P2): пауза бонусів/промо, аудит профілів, розширення вікна спостереження.
Security: SoD/MFA fail (P1/P2): блокування операції, JIT-повторна перевірка, форензика і Legal при необхідності.

18) FAQ

Як зменшити помилкові спрацьовування?
SLO-орієнтовані правила, кореляції, гістерезис, навчальні вікна і регулярний перегляд порогів.

Що важливіше - охоплення чи точність?
Для P1 - точність і швидкість (краще менше, але критичних). Для P3 - охоплення трендів і вартості.

Чи потрібен телефонний пейджинг?
Так, для P1; чат може бути недоступний або «зам'ючний».

Як не «спалити» on-call команду?
Ліміти page rate, перерозподіл навантажень, «follow-the-sun», щомісячні рев'ю шумів.

Резюме: Система повідомлень і алертів - це керований конвеєр від сигналу до дії. Будуйте її на SLO, гасіть шум, маршрутизуйте по контексту, давайте кнопки дій і фіксуйте все юридично. Так ви скорочуєте MTTA, знімаєте навантаження з on-call і підвищуєте стійкість бізнесу навіть при різких сплесках і збоях провайдерів.