SLA, SLO и SLI простыми словами: базовое руководство

Три аббревиатуры — SLA, SLO, SLI — встречаются в каждом разговоре о надёжности сервисов, в договорах с клиентами и в работе SRE-команд. И почти так же часто их путают между собой, используют как синонимы или применяют неправильно. Между тем разница между ними принципиальна: она определяет, как вы измеряете надёжность, какие цели ставите и какие обязательства берёте перед клиентами.

Эти три понятия образуют логическую иерархию: от того, что вы измеряете, к тому, к чему стремитесь, и к тому, что обещаете. В этой статье разберём каждое из них простыми словами, на конкретных примерах, покажем, как они связаны между собой, как их правильно определять и каких ошибок избегать. Это базовое руководство для всех, кто отвечает за надёжность сервиса — от инженеров до руководителей.

Три уровня надёжности: общая картина

Начнём с того, как эти понятия соотносятся. Представьте их как три уровня одной системы:

• SLI (Service Level Indicator) — что мы измеряем. Конкретная метрика: например, доля успешных запросов.
• SLO (Service Level Objective) — какую цель ставим по этой метрике. Например, 99.9% успешных запросов.
• SLA (Service Level Agreement) — что обещаем клиенту в договоре и что будет, если обещание нарушено.

Логика проста: SLI — это измерение, SLO — внутренняя цель, SLA — внешнее обязательство. Нельзя поставить осмысленную цель (SLO) без метрики (SLI), и нельзя дать честное обещание клиенту (SLA), не имея внутренней цели с запасом (SLO).

SLI: что мы измеряем

SLI — это конкретный количественный показатель качества сервиса. Он отвечает на вопрос «насколько хорошо сервис работает прямо сейчас» в измеримых числах.

Примеры SLI

• Доступность: доля успешных запросов от общего числа (например, 99.95% запросов вернули корректный ответ).
• Латентность: доля запросов, обработанных быстрее порога (например, 99% запросов быстрее 200 мс).
• Частота ошибок: доля запросов, завершившихся ошибкой.
• Пропускная способность: число успешно обработанных операций в единицу времени.
• Свежесть данных: насколько актуальны данные, которые отдаёт сервис.

Как выбирать SLI

Хороший SLI отражает то, что реально важно для клиента. Метрика «загрузка CPU на сервере» — это не SLI с точки зрения клиента: ему всё равно, насколько загружен ваш процессор, ему важно, отвечает ли сервис и быстро ли. Поэтому SLI формулируют с позиции пользовательского опыта: успешность запросов, скорость ответа, доступность функции.

Типичная форма SLI — отношение «хороших» событий к общему числу: (успешные запросы / все запросы) × 100%.

SLO: какую цель ставим

SLO — это целевое значение SLI, к которому стремится команда. Это внутренняя планка качества, которую вы считаете достаточной.

Примеры SLO

• Доступность API не ниже 99.9% за месяц.
• 99% запросов обрабатываются быстрее 300 мс.
• Частота ошибок не выше 0.1%.

Почему SLO не должен быть 100%

Главная и контринтуитивная идея: стремиться к 100% надёжности неправильно. Причины:

• 100% недостижимо. Всегда есть факторы вне вашего контроля: сети, провайдеры, оборудование.
• Каждая «девятка» дорожает экспоненциально. Путь от 99.9% к 99.99% требует кратно больше ресурсов, чем от 99% к 99.9%.
• Избыточная надёжность тормозит развитие. Если цель — 100%, любое изменение становится риском, и команда перестаёт выпускать новое.

Поэтому SLO задаётся осознанно ниже 100%, исходя из реальных потребностей клиентов и разумного баланса между надёжностью и скоростью развития.

Error budget: бюджет на ошибки

Из SLO рождается важное понятие — error budget (бюджет ошибок). Если SLO = 99.9%, то 0.1% — это допустимая доля сбоев, ваш «бюджет» на неудачи. Пока вы укладываетесь в бюджет, команда может смело выпускать новое и рисковать. Если бюджет исчерпан — пора притормозить с изменениями и сосредоточиться на стабильности.

Error budget превращает надёжность из расплывчатого «надо, чтобы работало» в конкретный измеримый ресурс, которым можно управлять.

SLA: что обещаем клиенту

SLA — это формальное соглашение с клиентом, в котором вы обещаете определённый уровень сервиса и описываете последствия его нарушения (обычно компенсации или штрафы).

Примеры условий SLA

• «Доступность сервиса составит не менее 99.9% в месяц. При нарушении клиент получает компенсацию в виде процента от платежа.»
• «Время реакции поддержки на критичный инцидент — не более 1 часа.»

Ключевое правило: SLA мягче SLO

Здесь кроется частая и дорогая ошибка. SLA, который вы обещаете клиенту, должен быть менее строгим, чем ваш внутренний SLO. Если ваша внутренняя цель 99.9%, обещать клиенту тоже 99.9% опасно: малейшее отклонение от цели сразу означает нарушение договора.

Правильный подход: внутренний SLO ставится с запасом выше, чем внешний SLA. Например, SLO = 99.95%, а SLA = 99.9%. Этот зазор — буфер безопасности, который защищает вас от штрафов при нормальных колебаниях.

Не каждому сервису нужен SLA

SLA — это юридическое обязательство с финансовыми последствиями. Оно уместно в B2B, в enterprise-контрактах, в инфраструктурных сервисах. Многим продуктам, особенно на раннем этапе, формальный SLA не нужен — достаточно внутренних SLO. Брать на себя SLA-обязательства стоит осознанно, понимая цену их нарушения.

Как всё связано: пример

Соберём всё вместе на примере API-сервиса:

• SLI: доля успешных HTTP-запросов (код ответа < 500).
• SLO (внутренняя цель): 99.95% успешных запросов за календарный месяц.
• Error budget: 0.05% запросов могут завершиться ошибкой — это допустимо.
• SLA (обещание клиенту): 99.9% доступности в месяц; при нарушении — компенсация.

Команда измеряет SLI постоянно. Пока укладывается в SLO 99.95%, всё хорошо, есть запас по error budget. Даже если SLO немного нарушен и доступность упала до 99.92%, клиентский SLA 99.9% всё ещё соблюдён — буфер сработал. Статус-страница при этом показывает реальную картину доступности, а её метрики uptime служат прозрачным подтверждением соблюдения обязательств.

Связь с статус-страницей

Статус-страница — естественное место, где абстрактные SLI/SLO/SLA становятся видимыми. Публичные метрики uptime на статус-странице показывают фактический SLI, а история инцидентов позволяет клиентам и команде отслеживать, как сервис соблюдает свои цели. Платформы вроде StatusMate визуализируют доступность по компонентам, превращая внутренние показатели надёжности в прозрачный аргумент для клиентов.

Лучшие практики

• Начинайте с SLI, отражающих опыт клиента, а не внутренние метрики инфраструктуры.
• Ставьте SLO осознанно ниже 100%, исходя из реальных потребностей, а не из стремления к идеалу.
• Делайте SLA мягче SLO. Внутренняя цель должна быть строже внешнего обещания.
• Используйте error budget как инструмент баланса между надёжностью и скоростью развития.
• Не берите SLA-обязательства без необходимости. Это юридический риск, оправданный не всегда.
• Делайте надёжность видимой через метрики на статус-странице.

Частые ошибки

• Путать SLA, SLO и SLI. Это разные уровни: измерение, цель, обещание. Смешение приводит к неверным решениям.
• Обещать клиенту тот же уровень, что и внутренняя цель. Без буфера между SLO и SLA любое колебание оборачивается нарушением договора.
• Стремиться к 100%. Недостижимо, разорительно и парализует развитие.
• Выбирать SLI по внутренним метрикам. Загрузка CPU не отражает опыт клиента; меряйте успешность и скорость запросов.
• Брать SLA без понимания цены нарушения. Финансовые обязательства требуют осознанной оценки рисков.
• Игнорировать error budget. Без него надёжность остаётся абстракцией, которой невозможно управлять.

Часто задаваемые вопросы

В чём разница между SLA, SLO и SLI простыми словами?
SLI — что вы измеряете (например, доля успешных запросов). SLO — внутренняя цель по этой метрике (например, 99.9%). SLA — обещание клиенту в договоре с последствиями за нарушение. Измерение → цель → обязательство.

Почему SLO не должен быть 100%?
Потому что 100% недостижимо, каждая дополнительная «девятка» дорожает экспоненциально, а стремление к идеальной надёжности парализует развитие — любое изменение становится недопустимым риском.

Что такое error budget?
Это допустимая доля сбоев, вытекающая из SLO. При SLO 99.9% бюджет ошибок — 0.1%. Пока он не исчерпан, команда может рисковать и выпускать новое; когда исчерпан — фокус смещается на стабильность.

Почему SLA должен быть мягче SLO?
Чтобы создать буфер безопасности. Если внутренняя цель строже внешнего обещания, нормальные колебания доступности не приводят к нарушению договора и штрафам.

Нужен ли SLA каждому сервису?
Нет. SLA — юридическое обязательство с финансовыми последствиями, уместное в B2B и enterprise. Многим продуктам достаточно внутренних SLO без формального SLA.

Как выбрать правильные SLI?
Отталкивайтесь от опыта клиента: успешность запросов, скорость ответа, доступность функций. Внутренние метрики вроде загрузки CPU не подходят — клиенту важен результат, а не устройство.

Заключение

SLA, SLO и SLI — не взаимозаменяемые модные термины, а три уровня одной системы управления надёжностью. SLI измеряет реальное качество сервиса с позиции клиента, SLO задаёт осознанную внутреннюю цель ниже недостижимых 100%, а SLA превращает часть этой цели в обязательство перед клиентом — обязательно с буфером безопасности между внутренней целью и внешним обещанием.

Правильно выстроенная иерархия этих понятий даёт команде измеримый язык для разговора о надёжности, инструмент баланса между стабильностью и развитием (error budget) и основу для честных обязательств перед клиентами. А статус-страница с публичными метриками доступности делает всю эту систему видимой и прозрачной — превращая внутреннюю дисциплину надёжности в актив, который клиенты могут проверить.