Что такое SLI, SLO и SLA. В чём разница и как выбрать правильные показатели доступности

Современный мониторинг давно перестал ограничиваться графиками загрузки процессора и объёма свободной памяти. Для бизнеса важно понимать не только то, работает ли сервер, но и насколько качественно сервис выполняет свою задачу для пользователей. Именно поэтому в инженерной практике появились три тесно связанных понятия: SLI, SLO и SLA.

Их часто путают между собой или используют как синонимы. На практике это три разных уровня оценки качества сервиса: метрики, внутренние цели и юридические обязательства. Разберёмся, чем они отличаются и как использовать их при построении системы мониторинга.

Что такое SLI

SLI (Service Level Indicator) — это измеряемый показатель качества работы сервиса.

Проще говоря, SLI отвечает на вопрос:

Что именно мы измеряем?

В отличие от системных метрик вроде загрузки CPU или объёма оперативной памяти, SLI описывает сервис с точки зрения пользователя.

Например:

• процент успешных HTTP-запросов;
• среднее и 95-й процентиль времени ответа API;
• время загрузки страницы;
• процент успешно отправленных писем;
• доля успешных платежей;
• время обработки задачи в очереди.

Например, интернет-магазин может использовать следующие SLI:

• успешность оформления заказа;
• время ответа API каталога;
• скорость открытия карточки товара;
• доступность поиска.

Важно понимать, что не каждая метрика является SLI. Загрузка процессора в 90% сама по себе ничего не говорит пользователю. А вот рост количества ошибок HTTP 500 напрямую влияет на качество сервиса.

Что такое SLO

SLO (Service Level Objective) — это целевое значение выбранного SLI.

Если SLI отвечает на вопрос «что измеряем», то SLO отвечает:

Какое значение считаем приемлемым?

Например:

• 99,95% HTTP-запросов должны завершаться успешно;
• 95% запросов должны выполняться быстрее 300 мс;
• среднее время обработки заказа не должно превышать 2 секунд;
• поиск должен быть доступен не менее 99,9% времени.

Именно вокруг SLO обычно строятся алерты и процессы эксплуатации.

Например, если целью является обработка 95% запросов быстрее 300 мс, то постепенный рост задержек становится поводом для расследования ещё до того, как пользователи начнут массово жаловаться.

Хороший SLO обладает несколькими свойствами:

• измеряется автоматически;
• связан с пользовательским опытом;
• имеет конкретное числовое значение;
• достижим для команды эксплуатации;
• отражает реальные ожидания бизнеса.

Что такое SLA

SLA (Service Level Agreement) — это соглашение между поставщиком сервиса и его клиентом.

В отличие от SLI и SLO, SLA является не техническим, а бизнес-документом.

Обычно он содержит:

• гарантированный уровень доступности;
• сроки реакции на обращения;
• время устранения инцидентов;
• компенсации при нарушении условий.

Например, облачный провайдер может гарантировать доступность виртуального сервера не ниже 99,95% в месяц. Если показатель окажется ниже, клиент получает компенсацию согласно условиям договора.

Таким образом:

• SLI — измеряем показатель;
• SLO — определяем внутреннюю цель;
• SLA — закрепляем обязательства перед клиентом.

Как эти понятия связаны между собой

Процесс обычно выглядит следующим образом.

Сначала команда определяет, какие показатели действительно отражают качество работы сервиса. Это будущие SLI.

После этого для каждого показателя устанавливается целевое значение — SLO.

И только затем, если сервис предоставляется внешним клиентам, часть этих целей может быть отражена в SLA.

Получается своеобразная цепочка:

Метрика → SLI → SLO → SLA

Например:

• SLI — процент успешных запросов API;
• SLO — не менее 99,95% успешных запросов;
• SLA — клиенту гарантируется доступность сервиса 99,9%.

Обратите внимание, что внутренний SLO обычно делают строже, чем SLA. Это создаёт запас прочности и позволяет устранять проблемы до того, как будут нарушены обязательства перед заказчиками.

Как выбрать хорошие SLI

Главная ошибка — выбирать показатели, которые удобны инженерам, но ничего не говорят о качестве сервиса.

Например:

Загрузка CPU — 95%.

Это может быть как абсолютно нормальной ситуацией, так и признаком серьёзной проблемы.

А вот такие показатели гораздо полезнее:

• процент успешных пользовательских запросов;
• задержка ответа API;
• время обработки операций;
• количество ошибок приложения;
• успешность бизнес-операций.

Хороший вопрос для проверки SLI звучит так:

Если показатель ухудшится, заметит ли это пользователь?

Если ответ отрицательный, скорее всего, перед вами обычная техническая метрика, а не показатель качества сервиса.

Типичные ошибки при выборе SLO

Самая распространённая ошибка — пытаться сделать систему «идеальной».

Например, устанавливать цель:

100% запросов должны выполняться быстрее 100 мс.

В реальных распределённых системах подобные требования практически недостижимы. Даже кратковременные сетевые задержки, обновления инфраструктуры или работа внешних API могут привести к единичным отклонениям.

Не менее опасна и другая крайность — слишком мягкие цели.

Если пользователи начинают жаловаться значительно раньше, чем срабатывают внутренние алерты, значит выбранный SLO не отражает реальное качество сервиса.

Ещё одна распространённая ошибка — строить цели исключительно вокруг инфраструктуры. Пользователя не интересует, сколько процентов памяти свободно на сервере. Его интересует, открывается ли сайт, проходит ли оплата и работает ли поиск.

Почему важно измерять сервис снаружи

Внутренний мониторинг инфраструктуры помогает понять, что происходит с серверами, приложениями и базами данных. Однако он не всегда показывает реальное состояние сервиса для конечного пользователя.

Например, все серверы могут быть доступны, CPU и память находятся в норме, а пользователи при этом сталкиваются с медленной загрузкой сайта или ошибками при выполнении операций.

Поэтому SLI часто строят не только на внутренних метриках, но и на данных внешнего мониторинга.

С помощью Statuser можно регулярно проверять доступность веб-приложений и API, измерять время ответа, отслеживать процент ошибок и получать уведомления при ухудшении показателей. Такие проверки позволяют видеть сервис с точки зрения пользователя и использовать полученные данные при построении SLO.

Например, вместо цели «сервер работает без ошибок» можно сформировать более полезный показатель:

• 99,9% HTTP-проверок должны завершаться успешно;
• среднее время ответа страницы не должно превышать установленный порог;
• API должно отвечать быстрее заданного значения в 95% случаев.

Такой подход помогает связать технический мониторинг с реальным качеством сервиса и быстрее обнаруживать проблемы, которые уже влияют на пользователей.

Итоги

SLI, SLO и SLA — это не три разных способа измерить одно и то же, а три уровня управления качеством сервиса.

SLI показывает, что именно измеряется. SLO определяет, какой уровень качества считается нормой. SLA фиксирует, какие обязательства компания берёт на себя перед клиентами.

Грамотно выбранные показатели помогают строить мониторинг вокруг пользовательского опыта, а не отдельных серверов. В результате команда быстрее обнаруживает реальные проблемы, эффективнее расставляет приоритеты при расследовании инцидентов и получает понятные критерии того, насколько сервис соответствует ожиданиям бизнеса.