SLI, SLO и error budget: основы надежности SRE на практике
Продвинутое3 минРедакция Innovialabs
Коротко
SLI — измеряемый показатель качества сервиса, SLO — целевое значение для него, а error budget — допустимая доля сбоев, которую команда может «потратить» на релизы и эксперименты.
Короткий ответ
- SLI (Service Level Indicator) — метрика, которая отражает опыт пользователя. Например, доля успешных запросов или доля запросов быстрее заданного порога.
- SLO (Service Level Objective) — цель для SLI за период. Например, 99,9% успешных запросов за 30 дней.
- SLA (Service Level Agreement) — договор с клиентом с последствиями за нарушение. SLA обычно мягче SLO, чтобы у команды был запас.
- Error budget — это
100% − SLO. При SLO 99,9% бюджет составляет 0,1% неудачных запросов или около 43 минут недоступности за 30 дней.
Смысл в том, чтобы договориться: какая надежность достаточна, и перестать спорить на эмоциях.
Как выбрать хорошие SLI
Хороший SLI измеряет то, что чувствует пользователь, а не состояние сервера. Загрузка CPU — плохой SLI: она может быть высокой, а пользователи довольны.
Типичные SLI по типу сервиса:
| Тип сервиса | SLI |
|---|---|
| API, веб-сайт | Доступность (доля ответов не 5xx), задержка (доля запросов быстрее порога) |
| Очередь, фоновые задачи | Свежесть данных, доля задач, обработанных вовремя |
| Хранилище | Долговечность, доля успешных чтений |
Практические советы:
- Формулируйте SLI как отношение хороших событий ко всем:
хорошие / все. - Измеряйте как можно ближе к пользователю: балансировщик или синтетические проверки лучше логов приложения.
- Начните с 2–3 SLI на ключевой пользовательский путь: вход, оплата, поиск.
- Для задержки используйте перцентили (p95, p99), а не среднее.
Как поставить реалистичный SLO
- Посмотрите на историю. Если сервис стабильно держит определенный уровень, начните с цели чуть ниже текущего факта.
- Не ставьте 100%. Это недостижимо и блокирует любые изменения. Каждая дополнительная «девятка» резко увеличивает стоимость.
- Учтите зависимости. Ваш сервис не может быть надежнее облака или базы, на которых работает, без резервирования.
- Выберите окно. Скользящее окно в 28 или 30 дней — частый выбор.
- Пересматривайте SLO раз в квартал вместе с продуктом.
Как использовать error budget
Error budget превращает надежность в ресурс, который можно тратить:
- Бюджет есть — команда спокойно выпускает фичи и экспериментирует.
- Бюджет кончается — приоритет смещается на стабильность: фиксы, тесты, улучшение деплоя.
- Бюджет исчерпан — заморозка рискованных релизов до восстановления.
Зафиксируйте это в error budget policy — коротком документе, который заранее согласован с бизнесом. Тогда решение «тормозить релизы» принимается по правилам, а не после конфликта.
Полезная практика — алерты по burn rate (скорости сжигания бюджета): если бюджет тратится в разы быстрее нормы, нужно реагировать сейчас, даже если SLO формально еще не нарушен.
Частые ошибки
- Слишком много SLO. Никто не следит за двадцатью целями.
- SLI на внутренних метриках вместо пользовательского опыта.
- SLO без политики. Если превышение бюджета ни на что не влияет, это просто график.
- Одинаковые цели для всего. Админка и оплата требуют разной надежности.