SLO — цели
Тема дорожной карты · Observability
Service Level Objective (SLO) — это целевое значение или диапазон для SLI за определённый временной период, выражающий ожидаемую надёжность сервиса. Например, SLO может гласить, что 99,5% API-запросов должны выполняться успешно в течение 500 мс за скользящие 30 дней. SLO — центральный инструмент SRE-подхода к управлению надёжностью: они превращают расплывчатые стремления к надёжности в измеримые, actionable обязательства, которые определяют как пороги алертинга, так и приоритеты при принятии решений. Когда SLO оказывается под угрозой нарушения, оставшийся бюджет ошибок сокращается, и команды могут решить замедлить выпуск новых функций в пользу работ по надёжности. Определения SLO нередко хранятся как код в YAML или с помощью таких инструментов, как sloth или pyrra, которые автоматически генерируют правила алертинга для Prometheus.
Как это работает
SLO — цели: 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 — цели: SLO без buy-in от продукта + инженерии ("бумажный SLO"); SLO, которые никто не трекает (дрейф); путаница SLA (юридическое) и SLO (инженерный таргет) — должны быть разными (SLO жёстче); error budget никогда не тратится ("слишком осторожны"); SLO-таргеты заданы случайной надеждой, не cost-анализом.