Как SLI, SLO и SLA делают сервис надёжным, а бизнес — предсказуемым

Вечер пятницы. Вы предвкушаете большой наплыв заказов в своем сервисе доставки еды и уже прикидываете прибыль. Но вдруг что-то ломается! В чате поддержки — шквал сообщений:

• «Где мой заказ?! Я жду уже час!»
• «Деньги списали, а еда не приехала!»
• «В приложении ошибка 502, вообще не работает!»

Радость улетучивается — вместе с деньгами, репутацией и лояльностью клиентов… После «тушения пожара» возникают вопросы: «Почему мы не увидели проблему раньше?» и «Как вообще понять, что работает плохо, а что — нормально?».

Еще недавно многие работали по принципу «пока гром не грянет»: о проблемах узнавали только от разгневанных клиентов или когда система уже лежала. SLA (Service Level Agreement) существовал формально, а про SLO и SLI почти не слышали. Но времена меняются. Сегодня SLI, SLO и SLA — это инструменты, которые позволяют вывести надёжность на новый уровень и предсказывать проблемы до того, как они ударят по бизнесу. Разбираемся, что означают эти аббревиатуры и как с их помощью превратить хаос в управляемый процесс.

SLI: измеряем, что происходит с сервисом

SLI (Service Level Indicator) — это числовой показатель, который отражает, насколько хорошо система работает с точки зрения пользователя. Проще говоря, SLI — это метрика состояния сервиса здесь и сейчас, «спидометр» для ИТ-продукта. 

Рассмотрим несколько конкретных SLI-метрик для нашего примера с доставкой еды.

• Процент успешных заказов. Показывает, сколько попыток оформить заказ заканчиваются успехом. Например: за 12 часов из 2000 пользователей, пытавшихся сделать заказ, у 1960 все прошло гладко, а у 40 произошла ошибка. Тогда SLI успешности = 1960 / 2000 * 100% ≈ 98%. Это высокий показатель стабильности. Если же он падает ниже, скажем, 95% – явный сигнал: что-то мешает людям оформить заказ, надо чинить.
• Аптайм (доступность) приложения. Процент времени, когда сервис работает штатно: приложение загружается, кнопки нажимаются, страницы не выдают ошибок. Например: за 30 дней (43 200 минут) приложение было недоступно 60 минут. Тогда SLI доступности = (43 200 − 60) / 43 200 * 100% ≈ 99,86%. Отлично! Но падение до 97% (~1300 минут простоя в месяц) означает, что пользователи массово не могут войти в сервис – проблема.
• Доля своевременной доставки. Оценивает, какой процент заказов приезжает вовремя. Например: за день было 500 заказов, из них 460 доставлены в срок до обещанных 60 минут. Тогда SLI по времени доставки = 460 / 500 * 100% = 92%. Оставшиеся 8% заказов опоздали.

SLI нужны, чтобы измерять качество сервиса не на глаз, а на основе объективных данных. SLI-мониторинг сразу показывает, где сбоит: проблемы в доставке, сбой в приложении или сбой платежей. Кроме того, прозрачные SLI помогают команде и партнерам: можно показать «У нас всё работает на 98% успешно» – и это звучит весомо. 

SLI – основа для понимания текущей надёжности сервиса: это данные, на которые потом опираются цели (SLO) и обещания клиентам (SLA).

SLO: ставим цели надёжности для команды

Если SLI — это измеряемый факт, то SLO (Service Level Objective) — это цель по качеству сервиса, которую вы устанавливаете на основе этих фактов. SLO — внутренняя договоренность, ориентир для команды, определяющий порог допустимого состояния системы. По сути, SLO отвечает на вопрос: «Какой уровень показателей мы хотим и готовы обеспечить?» 

Например, можно сформулировать несколько SLO на базе указанных выше метрик.

• Оформление заказов: «Не менее 99,5% заказов должны проходить без ошибок в оплате, подтверждении и т.д.». То есть из 2000 попыток заказа максимум 10 могут закончиться сбоем. Если платежный шлюз или другой компонент начнёт глючить, вы заметите просадку до того, как тысячи клиентов напишут в поддержку.
• Доступность приложения: «Приложение должно быть доступно 99,9% времени в месяц». Это означает максимум ~43 минуты простоя в месяц. Если приложение недоступно дольше, нужно принимать меры: оптимизировать инфраструктуру, увеличивать ресурсы, настраивать резервирование.
• Срок доставки: «95% заказов доставляются в течение 60 минут». Команда ставит цель, чтобы опоздания случались не чаще чем в 5% случаев. Если метрика падает ниже 95%, значит, где-то сбой: не хватает курьеров, рестораны не успевают готовить или подводит логистика – нужно разбираться и улучшать процессы.

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

Благодаря SLO вы фактически задаёте планку качества. Эта планка должна быть реалистичной: не стоит из головы ставить 99.999% аптайма, если вы не Google. Цель должна основываться на данных и возможностях команды (например, на текущих SLI плюс некоторый запас на улучшение). 

Ещё одно понятие, тесно связанное с SLO, – error budget (бюджет на ошибки). Проще говоря, это время на ошибки, которое вы можете «потратить» без серьёзных последствий. Error budget позволяет балансировать между развитием и стабильностью: вы знаете, сколько сбоев или простоя можете допустить. Если бюджет на ошибки начинает исчерпываться, пора переключаться с внедрения новых фич на усиление надёжности. Такой подход помогает команде быть проактивной и избегать крупных инцидентов. 

Важно понимать, что SLO – это внутренний ориентир, а не публичное обещание. Но они становятся основой для SLA.

SLA: обещаем надёжность и несём ответственность

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

SLA – это формализованное обещание, в котором прописано, какой уровень услуг мы гарантируем, и что произойдет, если эти условия нарушаются. Если SLO – «мы обещаем сами себе достичь», то SLA – «мы гарантируем вам, а если нет – понесем ответственность». SLA – внешняя рамка, SLO – внутренняя цель, а SLI – измерение реальности. 

Рассмотрим, как SLA работает в доставке.

1. Вы – клиент банка. Предположим, пользуетесь сервисом эквайринга для онлайн-оплаты. Вы заключаете с ним SLA, где оговаривается:
   • Аптайм платежного API не менее 99,9% в месяц.
   • Время реакции на инцидент – например, не более 15 минут с момента обнаружения.
   • Компенсация: например, если сервис оплаты простаивает дольше 1 часа подряд, провайдер возвращает вам, скажем, 10% комиссии за этот месяц.

Без SLA вы остаетесь один на один с проблемой. В нашей истории как раз этот случай: платежи легли в прайм-тайм, а поддержки со стороны партнёра нет. SLA страхует ваш бизнес: провайдер обязан оперативно реагировать при сбоях и компенсировать потери. У него есть стимул держать свои SLO, потому что на кону деньги и его репутация.

2. Вы — поставщик. Допустим, крупная сеть ресторанов подключилась к вашей платформе доставки. Для них вы – поставщик услуги, и они хотят гарантий. Вы составляете SLA для клиента-ресторана:
   • Время доставки – в 95% случаев не превышает 60 минут.
   • Обязательство: если ваш сервис оказывается недоступен более часа (например, сбой приложения) и из-за этого заказы не могут оформляться, вы возвращаете партнёру часть агентской комиссии.

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

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

Практические советы: как внедрить SLI/SLO/SLA

1. Определите, какие функции сервиса наиболее важны для пользователей и бизнеса. Это могут быть регистрация, добавление товара в корзину, оплата, оформление заказа, загрузка главной страницы. Не все компоненты системы равны по значимости – сфокусируйтесь на тех, от которых напрямую зависит заработок или удовлетворённость клиентов.
   
2. Определите ключевые метрики (SLI) для этих сценариев. Под каждую критичную функцию выберите 3-5 показателей, которые отражают её качество с точки зрения пользователя. Например, для мобильного приложения – скорость загрузки экрана, процент вылетов, потребление памяти и т.д. Главное, чтобы метрика была понятна и имела связь с опытом пользователя.
   
3. Замерьте текущее состояние и установите SLO. Соберите статистику по выбранным SLI за последние недели или месяцы: как они колеблются, какое среднее значение, худший случай. На основе этого определите реалистичный порог. SLO должно чуть превышать текущий уровень, но быть достижимым без чудес.
   
4. Оформите SLA. Если вы предоставляете сервис внешним клиентам или внутренним пользователям других подразделений – обсудите с ними приемлемые уровни сервиса. Заключите SLA: пропишите, какой уровень доступности или производительности вы гарантируете. Согласуйте, какие будут действия, если требования не выполняются (коммуникация, сроки исправления) и будет ли какая-то компенсация.
   
5. Настройте мониторинг и алерты. Метрики и цели не имеют смысла без постоянного контроля. Инструментов масса: от классической связки Prometheus + Grafana для сборки и визуализации метрик до самописных решений и дашбордов. Настройте оповещения не на каждое событие, а именно на нарушение ваших SLO. Например, не нужно получать 100 писем при каждой ошибке оплаты – лучше одно, когда успешность заказов падает ниже установленного порога.
   
6. Отслеживайте error budget. Сделайте практикой команды проверку, сколько «бюджета на ошибки» потрачено. Это можно визуализировать на дашборде: например, месяц начался с 43 минут допускаемого простоя, из них уже использовано 20 минут на несколько мелких инцидентов – осталось 23. Такой счетчик дисциплинирует. Если видите, что error budget тает быстрее, чем планировалось, примите меры: временно остановите релизы, сконцентрируйтесь на стабильности, найдите и устраните узкие места.
   
7. Регулярно пересматривайте SLI/SLO. Раз в квартал или при значимых изменениях продукта задавайтесь вопросами: «А правильные ли мы метрики измеряем? Может, появились новые болевые точки у клиентов?» Метрики эволюционируют вместе с вашим сервисом. Главное – не забывать их обновлять и улучшать.
   
8. Вовлеките всю команду. SLI/SLO – это не только забота SRE-инженера или отдела мониторинга. Донесите их значение до всех: разработчиков, тестировщиков, менеджеров продукта, службы поддержки. Когда SLO становится общим договором всей команды, появляется совместная ответственность за надежность. Люди начинают думать, как их работа влияет на итоговые показатели. Например, QA-инженер, зная про цель «не больше 3% жалоб», будет более тщательно проверять сложные кейсы, а продукт-менеджер подумает дважды, прежде чем выпускать сырую фичу 31 декабря.

Пусть поначалу это кажется дополнительной бюрократией, на деле эти практики экономят время и деньги. Поэтому методика SLI → SLO → SLA постепенно становится нормой. Она привносит культуру измерения и ответственности, которой раньше не хватало. Бизнес, научившийся говорить языком этих метрик, выглядит профессиональнее и привлекает клиентов, зная что надёжность = доверие = прибыль.

P.S. Если тема надёжности и управления сервисами вас заинтересовала, рекомендуем почитать другие материалы в нашем блоге. Например, ознакомьтесь со статьёй о том, как инженеры Google и Amazon внедряют практики SRE (Site Reliability Engineering). Также советуем материал про концепцию «двухскоростного ИТ», где разбираем баланс между стабильностью и инновациями в развитии IT-систем. 

И подписывайтесь на наш Telegram-канал – там мы регулярно делимся опытом, кейсами и полезными советами для IT-директоров и технических специалистов.