Запобігання надлишку алертів

1) Проблема і мета

Alert fatigue виникає, коли система шле занадто багато нерелевантних або не actionable повідомлень. Підсумок - ігнорування пейджів, зростання MTTA/MTTR і пропуск справжніх інцидентів.
Мета: зробити сигнали рідкісними, значущими і здійсненними, прив'язавши їх до SLO і плейбуків.

2) Таксономія сигналів (канал = наслідки)

Page (P0/P1) - будить людину; тільки коли потрібна ручна дія зараз і є runbook.
Ticket (P2) - асинхронна робота в години/день; не будить, але трікається по SLA.
Dash-only (P3) - спостереження/тренд без активних дій; не створює шум.
Silent Sentry - метрики/аудит в бекграунді (для RCA/пост-мортемів).

3) Проектування «правильного» алерта

• Мета/гіпотезу (що захищаємо: SLO, безпека, гроші, комплаєнс).
• Умови спрацювання (поріг, вікно, кворум джерел).
• Runbook/Playbook (короткий ID кроку + посилання).
• Власника (команда/рольова група).
• Критерії завершення (коли закривати, авто-резолв).
• Клас уразливості (user-impact/platform/security/cost).

4) SLO-орієнтований моніторинг

SLI/SLO → первинні сигнали: доступність, латентність, успішність бізнес-операцій.

• Короткий: 5% бюджету за 1 годину → Page.
• Довге: 2% бюджету за 6 годин → Ticket.
• Когортність: альберти за регіонами/провайдерами/VIP-сегментами - менше помилкових глобальних тривог.

5) Техніки зниження шуму

1. Кворум зондів: спрацьовування тільки якщо ≥2 незалежних джерела (різні регіони/провайдери) підтверджують проблему.
2. Дедуплікація: групування однакових подій (aggregation keys: service+region+code).
3. Гістерезис/тривалість: «у червоній зоні ≥ N хвилин», щоб відфільтрувати шипи.
4. Rate-limit: не більше X сповіщень/год/сервіс; при перевищенні - один пейдж + зведення.
5. Auto-snooze/інтелектуальне придушення: повторюваний алерт у вікні T → переклад в Ticket до усунення кореня.
6. Кореляція подій: один «майстер-алерт» замість десятків симптомів (наприклад, «БД недоступна» глушить 5xx з мікросервісів).
7. Maintenance вікна: планові роботи автоматично пригнічують очікувані сигнали.
8. Anomaly + guardrails: аномалії - тільки як Ticket, якщо немає підтвердження SLO-сигналом.

6) Маршрутизація та пріоритети

Пріоритети: P0 (Page, 15 хв апдейти), P1 (Page, 30 хв), P2 (Ticket, 4-8 год), P3 (спостереження).
Роутинг за ярликами: service/env/region/tenant → відповідний on-call.
Ескалації за часом: немає ack за 5 хв → P2 → Duty Manager/IC.
Quiet Hours: нічні години для некритичних; Page заборонений для P2/P3.
Fatigue-політика: якщо у інженера> N пейджів/зміну - перерозподілити на P2, ескалувати забруднення сигналів.

7) Якість алертів: домовленості

Actionability ≥ 80%: переважна більшість пейджів ведуть до дії по runbook.
False Positive ≤ 5% для Page-сигналів.
Time-to-Fix-Alert ≤ 7 днів - дефектний алерт повинен бути виправлений/видалений.
Ownership 100% - кожен алерт має власника і репозиторій з його визначенням.

8) Життєвий цикл алерта (Alert as Code)

1. Створити PR (опис мети, умови, runbook, власник, тестовий план).
2. Пісочниця/Shadow: тінь-алерт пише в чат/лог, але не пейджит.
3. Канарка: обмежена аудиторія on-call, вимірюємо FP/TP.
4. Прод: включення з rate-limit + спостереження 2-4 тижні.
5. Щотижневий review: метрики якості, правки/вилучення.
6. Депрекейт: якщо сигнал дублює більш високий або не actionable.

9) Метрики зрілості (покажіть на дашборді)

Alerts per on-call hour (медіана/95-перцентиль).
% actionable (є виконані кроки) і false-positive rate.
MTTA/MTTR навколо пейджів і частка page→ticket (не повинно бути високим).
Top-talkers (сервіси/правила, що генерують ≥20% шуму).
Mean time to fix alert (від першого FP до зміни правила).
Burn-rate coverage: частка сервісів з SLO-алертами в двох вікнах.

10) Чек-лист «Гігієна алертів»

• Алерт прив'язаний до SLO/SLI або до бізнес/безпеки.
• Є runbook і власник; вказані контакт і канал war-room.
• Налаштовані два вікна (коротке/довге) і кворум джерел.
• Включені дедуп, rate-limit, auto-resolve і auto-snooze.
• Вказані maintenance вікна і suppression при релізах/міграціях.
• Пройдено Shadow/Canary; виміряні FP/TP.
• Включений звіт по метрикам якості алертів.

11) Міні-шаблони

Специфікація алерта (YAML-ідея)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Текст апдейта за стандартом (для зменшення шуму)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) Процеси: щотижневий «Alert Review»

1. Топ-галасливі правила (top-talkers) → правимо/видаляємо.

2. FP/TP за Page-сигналами → коригуємо пороги/вікна/кворум.

3. Претенденти на зниження каналу (Page→Ticket) і навпаки.

4. Статус «Time-to-Fix-Alert» - прострочення ескалуються власникам сервісів.

5. Перевірка coverage SLO-алертами і наявності runbook'ів.

13) Зв'язок з релізами та операціями

Анотації релізів автоматично додають тимчасові придушення.
Change windows: в перші 30 хв після релізу - тільки SLO-сигнали.
Плейбуки містять крок «знизити/придушити неключові алерти», щоб концентруватися на корені.

14) Безпека та комплаєнс

Security-сигнали (злом/витік/аномальні доступи) - окремі канали, без quiet hours.
Аудит-лог всіх пригнічень/тихих вікон: хто, коли, чому, термін.
Вимога незмінності для критичних алармів (підпис події).

15) Анти-патерни

«Кожен графік = алерт» → лавина.
Поріг «! = 0 помилок» в проді.
Один зонд/один регіон як джерело істини.
Page без runbook/власника.
Вічні «тимчасові придушення» без терміну.
«Починимо потім» дефектні алерти - копляться роками.
Змішування релізного шуму з продукційними інцидентами.

16) Дорожня карта впровадження (4-6 тижнів)

1. Інвентаризація: вивантажити всі алерти, проставити власників і канали.
2. SLO-ядро: ввести burn-rate правила з подвійними вікнами по критичних сервісах.
3. Шум-контроль: включити кворум, дедуп і rate-limit, завести weekly review.
4. Runbook-покриття: закрити 100% Page-сигналів плейбуками.
5. Фатіг-політика: ліміти пейджів/зміну, Quiet Hours, перерозподіл навантаження.
6. Автоматизація: Alert-as-Code, Shadow/Canary, звітність за метриками якості.

17) Підсумок

Тиша - це не відсутність моніторингу, а якісно спроектовані сигнали, пов'язані з SLO і процесами. Кворум, подвійні вікна, дедуп і сувора маршрутизація перетворюють алерти в рідкісні, точні і здійсненні. Команда спить, користувачі задоволені, інциденти - під контролем.