Алерти під SLO: error budget, severity і як прибрати шум, не втративши контроль

Алерт має означати “потрібна дія”

Якщо алерти спрацьовують щогодини і нічого не відбувається — команда перестає реагувати. SLO‑підхід робить сигнал сильнішим: ми алертимо, коли продукт реально деградує.

1) SLO і error budget

• SLO: наприклад, “99.9% запитів успішні”.
• Error budget: скільки помилок допустимо в періоді.

2) Severity

• P0/P1 — тільки те, що впливає на гроші/доступ/безпеку.
• P2/P3 — в робочий час або в backlog.

3) Дедуплікація і маршрутизація

Один інцидент — один алерт‑ланцюжок. Маршрутизація: інтеграції → відповідальна команда, БД → infra/бекенд.

4) Практичне правило

Кожен критичний алерт має мати owner і runbook. Якщо owner немає — алерт не критичний.

Підсумок

SLO‑алерти зменшують шум і підвищують швидкість реакції. Це робить SLA реальним, а не “табличкою”.