Если сервис “вроде работает”, но пользователи всё равно жалуются — значит, надёжность не измерена правильно. Здесь и нужны SLI и SLO.
Что такое SLI
SLI (Service Level Indicator) — это метрика, которая показывает реальное качество сервиса глазами пользователя.
Примеры SLI:
- процент успешных запросов
- время ответа API
- доступность сайта
- доля ошибок при оплате
- задержка доставки сообщений
Важно: SLI должен отражать пользовательский опыт, а не только внутреннее состояние системы. Например, загрузка CPU в 95% — это тревожный сигнал, но не SLI.
Что такое SLO
SLO (Service Level Objective) — это целевое значение для SLI.
Пример:
- доступность API — 99,9% за 30 дней
- 95% запросов обрабатываются быстрее 300 мс
- успешность платежей — не ниже 99,95%
Проще говоря:
- SLI — что измеряем
- SLO — какого результата хотим добиться
Как правильно выбрать SLI
Ошибка многих команд — измерять всё подряд. Хороший SLI должен быть:
- понятным — без сложных трактовок
- измеримым — данные собираются автоматически
- связанным с пользователем — отражает качество сервиса
- стабильным — не зависит от случайных шумов
Обычно выбирают 1–3 ключевых SLI на критичный пользовательский путь:
- вход в систему
- оформление заказа
- вызов API
- загрузка страницы
Как определить адекватный SLO
SLO нельзя брать “с потолка”. Слишком высокий порог демотивирует команду, слишком низкий — не защищает бизнес.
Практичный подход:
- проанализировать исторические данные
- определить, где сбои реально влияют на пользователей
- согласовать цель с бизнесом и продуктом
- учитывать стоимость повышения надёжности
Например, 99,999% звучит красиво, но требует серьёзных затрат на инфраструктуру, процессы и on-call. Не каждому продукту это нужно 💸
Используйте error budget
Если SLO задан, появляется error budget — допустимый объём деградации.
Пример:
SLO = 99,9% доступности в месяц
Это значит, что сервис может быть недоступен примерно 43 минуты в месяц.
Error budget помогает принимать решения:
- выпускать ли рискованный релиз
- когда замораживать новые фичи
- где нужен фокус на стабилизации
Частые ошибки
- выбирать технические метрики вместо пользовательских
- ставить слишком много SLI
- копировать чужие SLO без учёта своего продукта
- не пересматривать цели со временем
- не связывать SLO с инцидентами и приоритетами команды
Итог
SLO и SLI — это не “формальность для DevOps”, а способ договориться, что такое надёжный сервис.
Хорошая цель надёжности:
- понятна бизнесу
- измерима для инженеров
- полезна для пользователей
Сначала определите критичный пользовательский сценарий, затем выберите SLI, и только после этого задавайте реалистичный SLO 🚀
Подборку каналов про IT, архитектуру, DevOps и разработку стоит посмотреть отдельно — там часто публикуют полезные практики, кейсы и разборы инструментов 👀