Три буквы, от которых зависит стабильность сервиса и спокойный сон команды поддержки. В этой статье разберём, что именно скрывается за аббревиатурами, какие метрики действительно важны и как превратить сухие числа в управляемые соглашения и рабочие правила.
Чем отличаются SLA, SLO и SLI и почему это важно
SLI — это конкретная метрика: процент успешных запросов, средняя задержка, число ошибок на миллион. Она отвечает на вопрос «что мы измеряем». SLO — цель по этой метрике: например, 99.95% доступности за 30 дней. SLA — договор с клиентом, который иногда включает штрафы за нарушение SLO.
Разделение ролей важно: SLI помогает объективно оценивать поведение системы, SLO задаёт ориентир для команды, а SLA связывает бизнес-риски с техническими обязанностями. Путаница между этими уровнями рождает либо неоправданно строгие требования, либо бессмысленные соглашения.
Если ограничиться только SLA, команда будет фокусироваться на юридических последствиях. Если останавливаться только на SLIs, то цели могут оказаться несвязаны с потребностями пользователей. В идеале все три уровня работают вместе и задают понятную структуру ответственности.
Какие метрики надёжности действительно считаются SLI
Не все измерения полезны. Хорошая SLI отражает пользовательский опыт и при этом поддаётся надёжному сбору. Основные кандидаты — доступность, время отклика, процент ошибок, пропускная способность и сохранность данных.
Ниже таблица с примерами SLI, их формулами и объяснением, когда использовать.
| Метрика | Пример SLI | Формула | Когда уместна |
|---|---|---|---|
| Доступность | Процент успешных HTTP-запросов | успешные запросы / все запросы | Внешние веб-сервисы, API |
| Задержка | Процент запросов < 300 мс | количество запросов с latency < порога / все запросы | Интерактивные приложения |
| Ошибка | Ошибки 5xx на миллион запросов | число ошибок / миллион запросов | Сервисы с высокой нагрузкой |
| Долговечность | Процент корректно сохранённых объектов | успешные записи / все записи | Хранилища данных |
Таблица упрощает выбор; важно помнить, что одна система обычно требует нескольких SLIs, потому что надёжность — это многогранное свойство.
Как формулировать SLO: правила и практические приёмы
SLO должен быть конкретным, измеримым и привязанным ко времени. «Высокая доступность» не годится — «99.9% за 30 дней» — уже рабочая формулировка. При этом цель должна быть достижима с учётом архитектуры и бюджета на поддержку.
Ниже несколько пошаговых рекомендаций, которые я использую при формировании SLO в командах.
- Выберите ограниченное число SLIs — 2–4 главных показателя.
- Определите окно наблюдения: 7, 30 или 90 дней в зависимости от сервиса.
- Привяжите SLO к пользовательскому сценарию, а не к отдельной внутренней метрике.
- Установите политики на случай нарушения: уведомления, отложенные релизы, дополнительный мониторинг.
Пара полезных приёмов: считать SLO по скользящему окну, а не по суммарному времени с начала года, и явно зафиксировать правила агрегации данных. Это снимает неопределённости и делает измерения воспроизводимыми.
Необходим баланс: слишком жёсткое SLO создаёт постоянное давление и частые инциденты, слишком мягкое — не даёт мотивации улучшать сервис. Лучший подход — начать чуть щедрее, затем корректировать по мере накопления данных.
Окна и агрегация
Окно наблюдения выбирают исходя из характера нагрузки и бизнес-потребностей. Для веб-сервисов обычно подходят 30 дней; для критичных API — 7 дней, чтобы быстрее реагировать. Иногда разумно вести параллельно несколько окон.
Агрегация должна учитывать аномалии: кратковременные всплески не обязательно отражают реальный пользовательский опыт. Часто используют пороговую агрегацию: считать процент успешных запросов по минутным интервалам, затем усреднять по окну.
Бюджет ошибок: как он рвёт тупики и направляет приоритеты
Ошибка бюджета — это практический инструмент. Если SLO 99.9% в месяце, значит допустимо примерно 43 минуты простоя. Этот «бюджет» можно тратить на релизы, эксперименты и даже плановый риск; когда бюджет заканчивается, команды замедляют изменения и фокусируются на стабильности.
Бюджет ошибок превращает абстрактные цели в конкретные действия. Он помогает решать конфликты между разработкой фич и борьбой с техническим долгом: когда бюджет на исходе, приоритет смещается в пользу исправлений.
В моём опыте одна команда сократила число регрессий вдвое, просто введя видимый дашборд остатка бюджета ошибок и правило «без новых релизов, пока бюджет не восстановится хотя бы на 20%».
Мониторинг, алертинг и то, как метрики обманывают
Метрики действительны только при корректном измерении. Частая ошибка — полагаться на агрегированные значения без учёта кардинальности и распределения. Например, средняя задержка может быть нормальной, но 1% запросов — очень медленные, что портит впечатление реальным пользователям.
Настройки алертов нужно связывать с SLO, а не только с порогами операционной метрики. То есть тревоги для инженеров должны срабатывать тогда, когда рисуется реальная угроза нарушить SLO, а не при каждом кратковременном всплеске.
Полезный приём — две линии: «оперативный» алерт для быстрых инструментов и «SLO-алерт» для решений о приостановке изменений и переключении на режим устранения причин. Это снижает шум и направляет усилия.
Проблемы данных и как их решать
Ошибки в сборе метрик — обычное дело: от сбоев агентов до пропусков в логах. Всегда документируйте источники данных и наличие слепых зон. Проверяйте, что метрика SLIs собирается с того же уровня, на котором пользователь испытывает эффект.
Рекомендую периодически проводить аудит метрик: сверять логи, трассировки и пользовательские отчёты. Это помогает обнаружить рассинхронизации до того, как они станут причиной неверных управленческих решений.
Примеры SLO и расчёты на практике
Приведу несколько практических формулировок, которые можно адаптировать под свой сервис. Каждая формулировка содержит SLI, окно и цель.
- 99.95% успешных HTTPS-запросов к API за 30 дней.
- 95% страниц рендерятся быстрее 500 мс по 7-дневному окну.
- Не более 10 ошибок 5xx на миллион запросов в месячном окне.
Числа хорошо переводить в «время простоя». Например, 99.9% доступности — это максимум ~43 минуты недоступности в месяц. Такие переводы помогают бизнес-стейкхолдерам понять масштаб риска.
Организация работы: ответственность и процессы
Технология измерений важна, но не менее важна организация: кто следит за SLO, кто принимает решения при нарушении и какова роль продуктовой команды. Рекомендуется закрепить владельца SLO и установить регулярные ревью состояния метрик.
Инцидентные процессы должны быть без обвинений и с чётким фокусом на восстановление и исправление причин. Постинцидентные разборы дают конкретные улучшения в SLO-цели или инструментах измерения.
Лично я видел, как регулярные «SLO-ревью» и прозрачные дашборды выстраивали доверие между разработчиками и продуктом. Когда показатели видны всем, решения становятся быстрее и понятнее.
Что важно помнить при внедрении метрик надёжности
Не гонитесь за большим количеством SLI — лучше несколько точных и полезных. Начинайте с простых метрик, собирайте данные, корректируйте цели. SLO — живой документ; он меняется по мере роста системы и изменения потребностей пользователей.
Не превращайте SLO в инструмент наказания. Правильно организованный процесс использует его как маяк и ограничитель риска. Тогда метрики действительно помогают принимать обоснованные решения, снижать количество инцидентов и улучшать пользовательский опыт.
Если вы начинаете внедрять эти практики впервые, сосредоточьтесь на прозрачности, воспроизводимости измерений и на том, чтобы SLO приносил пользу команде, а не был ещё одним отчётом для бухгалтерии.
Короткое напутствие
Продуманные показатели и простые процессы работают лучше сложных схем. Начните с пары надежных SLIs, сформулируйте SLOы по реальным сценариям и используйте бюджет ошибок как практический механизм управления риском. Это даст систему, где надёжность — не абстракция, а управляемый параметр.
