SLI, SLO и SLA: в чём разница простыми словами

Три аббревиатуры, которые различаются одной буквой и постоянно путаются — даже в договорах. Объясняем на примере интернет-магазина: что измеряем, что себе обещаем и за что отвечаем перед клиентом деньгами. И показываем, как пользоваться этой системой без SRE-команды.

Коротко, одной строкой каждое:

SLI (Service Level Indicator) — индикатор: то, что вы измеряете. Конкретная метрика качества сервиса: доля успешных запросов, время ответа, аптайм. SLI — это число, которое приходит из мониторинга.

SLO (Service Level Objective) — цель: то, что вы себе обещаете. Внутренний порог для SLI: «доступность не ниже 99,9% за месяц», «95% страниц открываются быстрее 2 секунд». SLO — планка, по которой команда судит, всё ли в порядке.

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

Как это выглядит у интернет-магазина

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

Бюджет ошибок: зачем SLO ставят ниже 100%

Самая полезная идея из этой системы — бюджет ошибок (error budget). Если ваш SLO — 99,9% доступности, то 0,1% — это разрешённый простой: около 43 минут в месяц. Это не «допустимая халтура», а осознанный резерв: на выкатку обновлений, эксперименты, перезагрузки, неизбежные мелкие сбои.

Бюджет превращает вечный спор «стабильность против новых фич» в арифметику. Бюджет цел — можно рисковать: обновлять движок, менять хостинг, выкатывать новую версию. Бюджет сожжён за первую неделю — стоп всем экспериментам, месяц живём тихо и чиним причины. Стремиться к 100% при этом невыгодно: каждая лишняя девятка стоит кратно дороже, а пользователи разницу между 99,9% и 99,99% в большинстве случаев не замечают.

Как завести SLI/SLO без SRE-команды

Вся система в минимальном виде — это три решения и полчаса настройки.

Шаг 1. Выберите 2–4 индикатора, которые видит клиент. Не CPU и не память сервера — клиенту всё равно, что у вас с CPU, пока корзина открывается. Хороший стартовый набор: доступность главной, доступность ключевой страницы сценария (корзина, форма заявки, личный кабинет), срок SSL-сертификата, время ответа. Первые два измеряются проверкой доступности (GET), третий — проверкой SSL-сертификата.

Шаг 2. Назначьте каждому индикатору реалистичную цель. Для обычного сайта на виртуальном хостинге честное SLO — 99,5–99,9%: выше не даст сам хостинг (см. его SLA). Ставить себе 99,99%, покупая хостинг с гарантией 99,9%, бессмысленно — вы обещаете себе больше, чем вам обещает фундамент.

Шаг 3. Раз в месяц сверяйте факт с целью. Мониторинг сам накапливает статистику: сколько было инцидентов, какой длины, из каких регионов. Если факт стабильно хуже SLO — это аргумент менять хостинг или архитектуру, причём аргумент с цифрами, а не с ощущениями. Как считается сам показатель — в статье про uptime.

Готовый стартовый набор SLO для типовых сайтов

Числа нарочно скромные — это стартовые планки, которые типовая инфраструктура способна выдержать. Прожив с ними квартал, вы будете знать свой реальный уровень и сможете двигать цели осознанно. Для API-сценариев пригодится наш разбор мониторинга API.

Три ошибки, которые обесценивают систему

Слишком много индикаторов. Двадцать SLI — это ноль SLI: никто не смотрит на панель из двадцати графиков. Начните с трёх-четырёх, которые напрямую видит клиент; остальное добавляйте, только когда эти три перестанут отвечать на ваши вопросы.

SLO, списанное с чужого блога. «У Google пять девяток, поставим и себе» — путь к самообману. Цель, которую инфраструктура физически не может выдержать, будет вечно красной, и на неё быстро перестанут смотреть. Планка должна быть достижимой в хороший месяц и нарушаемой в плохой — только такая планка информативна.

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