SLI, SLO и SLA: в чём разница и зачем это поддержке
Три похожие аббревиатуры, которые постоянно путают между собой — в том числе на собеседованиях. Разберёмся, чем они отличаются, и что за ними стоит, кроме красивых процентов в презентации.
Спор, из которого всё выросло
Представьте разговор. Бизнес говорит: сервис работает плохо, пользователи жалуются. Разработка отвечает: всё в порядке, мы за неделю ничего не ломали. Поддержка знает, что утром сорок минут были ошибки, но на общем фоне это выглядит незначительно.
Все трое правы и не могут договориться, потому что у них нет общего числа. «Работает плохо» — не аргумент, «всё в порядке» — тоже.
SLI, SLO и SLA — это способ превратить спор о качестве в разговор о цифрах. Одна аббревиатура отвечает за измерение, вторая за цель, третья за обязательство. Дальше — подробнее, но если нужна короткая версия: SLI измеряем, SLO хотим, SLA обещаем.
SLI: что мы вообще меряем
Service Level Indicator — числовой показатель, описывающий качество работы сервиса с точки зрения того, кто им пользуется.
Последние четыре слова здесь ключевые. Загрузка процессора на сервере — важная метрика, но не SLI: пользователю безразлично, сколько там процентов, пока страница открывается. А вот доля запросов, завершившихся успешно, — уже SLI.
Типичные показатели:
- доля успешных запросов от общего числа;
- время ответа, обычно не среднее, а процентиль — например, значение, в которое укладываются 95% запросов;
- доступность сервиса за период;
- для очередей и фоновых задач — задержка обработки: сколько прошло от постановки задачи до её выполнения.
Среднее время ответа стоит упомянуть отдельно, потому что его любят и оно почти всегда врёт. Если девятьсот запросов отработали за 50 мс, а сто висели по 5 секунд, среднее будет около 545 мс — число, которого не было ни у кого. Процентиль честнее: он показывает, что у каждого десятого пользователя всё плохо.
SLO: к какому значению стремимся
Service Level Objective — целевое значение выбранного SLI за период. Например: 99,9% успешных запросов за календарный месяц. Или: 95% запросов обрабатываются быстрее 500 мс.
Это внутренняя цель команды, а не обещание внешнему заказчику. Отсюда и главное практическое различие: за недостижение SLO не штрафуют, по нему принимают решения.
Заманчиво поставить SLO поближе к ста процентам, но так не делают, и причина не в лени. Каждая следующая девятка после запятой стоит кратно дороже предыдущей: резервирование, дублирование каналов, автоматическое переключение, круглосуточное дежурство. Для внутреннего сервиса отчётности 99,5% — разумно. Для платёжного шлюза — недопустимо. Цифра берётся не из красоты, а из того, во что обходится простой.
Бюджет ошибок: самое полезное следствие
Если SLO равен 99,9%, то оставшиеся 0,1% — это не досадная погрешность, а разрешённый объём сбоев. За тридцать дней получается около 43 минут. Это и есть бюджет ошибок.
Механика простая. Пока бюджет не израсходован, команда может рисковать: катить релизы чаще, экспериментировать, проводить учения. Когда бюджет исчерпан, приоритеты меняются — сначала стабилизация, потом новые фичи.
Что это даёт на практике:
Во-первых, исчезает спор о том, «часто ли мы падаем». Есть число, и оно либо в рамках, либо нет.
Во-вторых, появляется общий язык между разработкой и эксплуатацией. Раньше разговор шёл в терминах «вы слишком часто релизите» против «вы слишком осторожничаете». Теперь — в терминах остатка бюджета.
В-третьих, у инцидентов появляется вес. Сорокаминутная деградация — это не «неприятность», а весь месячный бюджет разом.
Инженеру поддержки полезно помнить: бюджет тратится не только на аварии. Плановые работы, неудачный релиз с откатом, миграция базы — всё это тоже расход, если в это время пользователи видели ошибки.
SLA: то, что подписано
Service Level Agreement — формальное соглашение между поставщиком услуги и заказчиком. В отличие от SLO, это юридический документ с последствиями за нарушение: компенсации, продление подписки, штрафы.
Помимо целевых показателей доступности, в SLA обычно входят время реакции на обращение по каждому уровню критичности, время решения, окна плановых работ, которые из расчёта исключаются, и порядок эскалации.
Важная деталь, которую часто упускают: SLA почти всегда мягче внутреннего SLO. Если наружу обещано 99,5%, внутри команда будет держать 99,9% — запас нужен, чтобы обычный рабочий сбой не превращался сразу в нарушение договора с финансовыми последствиями.
Что с этим делает инженер поддержки
Вопрос «зачем мне это, я не менеджер» возникает закономерно. Но на второй линии эти цифры всплывают чаще, чем кажется.
Приоритет инцидента перестаёт быть вопросом ощущений. Когда вы видите, что за двадцать минут выгорела половина месячного бюджета, решение о срочном откате принимается быстрее и обосновывается легче.
Мониторинг тоже настраивается от SLO. Алерт имеет смысл вешать не на абстрактный порог, а на скорость расходования бюджета: если такими темпами он кончится за сутки вместо месяца, реагировать нужно сейчас.
В постмортеме потери фиксируются в тех же единицах — сколько бюджета съел инцидент. Это превращает разбор из пересказа событий в оценку ущерба.
И отдельная ситуация — когда нарушение SLA уже произошло. Тогда нужно быстро поднять точные границы: во сколько началось, во сколько закончилось, попадало ли это в согласованное окно работ, какой доли пользователей коснулось. Эти данные собирает именно поддержка, и собирать их лучше сразу, а не через неделю по просьбе юристов.