SLO-based alerting
Тема дорожной карты · Observability
Алертинг на основе SLO — также известный как алертинг по скорости сжигания бюджета ошибок — срабатывает, когда сервис слишком быстро расходует бюджет ошибок, а не когда превышается статический порог. Эту концепцию популяризировала книга Google SRE Workbook: вместо того чтобы получать алерт при превышении частоты ошибок 1%, вы получаете алерт, когда скорость сжигания за короткое окно (например, 1 час) достаточно высока, чтобы исчерпать месячный бюджет ошибок в течение суток. Это даёт меньше, но более actionable алертов, поскольку непосредственно связывает алерт с влиянием на пользователей и риском для SLO. Алертинг на основе SLO обычно реализуется с помощью правил с несколькими временны́ми окнами и несколькими скоростями сжигания, выраженных в alerting_rules.yml Prometheus; фреймворки sloth или pyrra генерируют эти правила из простой спецификации SLO. Интеграция алертинга на основе SLO с Alertmanager и PagerDuty гарантирует, что нужная команда получит уведомление с нужным уровнем срочности до того, как бюджет ошибок иссякнет.
Как это работает
SLO-based alerting: SLI (Service Level Indicator) — измерение здоровья сервиса (например "доля HTTP 200"). SLO (Objective) — таргет для этого SLI ("99.9% за 30 дней"). SLA (Agreement) — контрактное обещание клиентам ("99.5% или refund"). Error budget = 1 - SLO; тратится на релизы + эксперименты. Burn-rate alerts (multi-window, multi-burn-rate) ловят fast + slow burn с подходящей чувствительностью.
Когда применять
Определите SLI + SLO до масштабирования reliability-работы — без них спорите вечно про "достаточно хорошо". Начните с availability + latency SLI (probe_success_ratio, request_latency_p99). SLO на 99% / 99.9% — 99.99% звучит хорошо, но цена экспоненциальная. Алерты на основе SLO (burn rate), не threshold-алерты на сырых метриках. Прочтите главу про SLO в SRE-книге Google.
Типичные ошибки
Ловушки SLO-based alerting: SLO без buy-in от продукта + инженерии ("бумажный SLO"); SLO, которые никто не трекает (дрейф); путаница SLA (юридическое) и SLO (инженерный таргет) — должны быть разными (SLO жёстче); error budget никогда не тратится ("слишком осторожны"); SLO-таргеты заданы случайной надеждой, не cost-анализом.