Объясните SLI, SLO и SLA. Что такое error budget и как он влияет на процесс разработки?
Короткий ответ
- SLI — измеримый показатель качества: доля успешных запросов, латентность
- SLO — внутренняя цель по SLI за окно времени
- SLA — внешнее обязательство с санкциями, мягче SLO
- Error budget — допустимая доля ошибок: 100% минус SLO
- Бюджет тратится на релизы и эксперименты, исчерпан — фокус на стабильность
- Алерты строят на скорости сжигания бюджета (burn rate)
SLO переводит разговор о надёжности в цифры, а error budget превращает их в механизм баланса между фичами и стабильностью.
Как сказать вслух
пример ответаSLI — это конкретная метрика, по которой мы меряем качество сервиса, например доля успешных запросов. SLO — целевое значение этой метрики за период, скажем 99.9% за месяц. SLA — это уже договор с клиентом с финансовой ответственностью, и он обычно мягче внутреннего SLO. Разница между стопроцентной надёжностью и SLO — это бюджет ошибок: пока он есть, команда спокойно катит релизы, а когда сожгли — замораживаем фичи и вкладываемся в стабильность. Это снимает вечный конфликт между скоростью и надёжностью.
Подробный ответ
Основной ответ
SLI формулируется как отношение хороших событий к общему числу: доля запросов быстрее 300 мс, доля ответов не-5xx. SLO — цель по SLI на окне (месяц, квартал), выбранная из потребностей пользователей и стоимости обеспечения; каждая дополнительная девятка стоит кратно дороже. SLA — юридическое обязательство перед клиентами, обычно слабее SLO, чтобы оставался запас. Error budget: при SLO 99.9% за 30 дней допустимо примерно 43 минуты полной недоступности. Политика бюджета фиксируется заранее: при исчерпании — заморозка релизов, приоритизация надёжности, разбор причин. Алертинг делают по burn rate: многооконные правила (например, быстрое окно 5 минут и час) ловят и резкое, и медленное сжигание без шума.
Ключевые моменты
- SLI из пользовательского опыта. Метрика должна отражать то, что чувствует пользователь, а не загрузку CPU на сервере.
- SLO не равно 100%. Абсолютная надёжность не нужна и неокупаема; цель выбирают осознанно и пересматривают.
- Error budget как договор. Это согласованная политика между разработкой и эксплуатацией, снимающая конфликт о скорости релизов.
- Burn rate алерты. Алертить по скорости расходования бюджета в нескольких окнах, а не по каждому всплеску ошибок.
Практический контекст
Ядро SRE-культуры и обязательный вопрос на senior-позиции. На практике инженер определяет SLI вместе с продуктом, реализует подсчёт в Prometheus, настраивает burn-rate-алерты и использует бюджет в споре «катим фичу или чиним техдолг». Интервьюер проверяет и расчёты (сколько минут даунтайма допускает 99.9%), и понимание организационной роли бюджета ошибок.
Частые ошибки
- Путают SLA и SLO или считают их синонимами
- Выбирают SLI по серверным метрикам, а не по пользовательскому опыту
- Не могут объяснить, что происходит организационно при исчерпании бюджета ошибок