SLA, SLO и SLI для цифрового сервиса: метрики и бюджет ошибок

Ситуация, когда мониторинг показывает штатную загрузку процессоров и памяти, а служба поддержки перегружена жалобами пользователей на недоступность сервиса, знакома большинству IT-команд. Этот разрыв возникает из-за подмены понятий: техническое состояние отдельных узлов инфраструктуры не отражает реальное качество клиентского опыта.

Чтобы устранить несоответствие между восприятием пользователей и отчетами инженеров, в современной разработке и практике Site Reliability Engineering (SRE) используется трехуровневая модель: SLI, SLO и SLA. Она позволяет разложить надежность на измеримые индикаторы, определить допустимый уровень сбоев и синхронизировать ожидания бизнеса, продуктовой команды и клиентов.

Разница между SLI, SLO и SLA: цепочка от метрики к договору

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

Инфраструктура и логи генерируют сырые данные о событиях.
SLI (Service Level Indicator): объективный факт происходящего. Отвечает на вопрос: «Что именно мы измеряем?»
SLO (Service Level Objective): внутренняя планка надежности. Отвечает на вопрос: «К какому качеству работы стремится инженерная команда?»
SLA (Service Level Agreement): внешнее обязательство перед клиентом. Отвечает на вопрос: «Что мы юридически гарантируем пользователю и чем рискуем при нарушении?»

SLI: объективный факт происходящего

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

SLI = (Успешные события) / (Все учтенные события) ×100%

Пример: доля вызовов API оформления заказа, завершившихся HTTP-кодом 200 с задержкой не более 500 миллисекунд.

SLO: внутренняя планка качества

SLO задает целевое значение для SLI на фиксированном временном интервале. Пример: «99,9% запросов на авторизацию должны завершаться успешно в рамках 28-дневного скользящего окна».

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

SLA: внешнее обязательство

SLA — официальный документ или пункт коммерческого договора, фиксирующий обязательства поставщика перед заказчиком. Он привязывает доступность сервиса к финансовой или юридической ответственности: сервисным кредитам, скидкам или компенсациям.

Правило безопасности: целевой уровень SLO внутри команды всегда должен быть строже, чем порог SLA в договоре. Если клиенту гарантирована доступность 99,5%, внутренний ориентир SLO должен составлять не менее 99,9%. Этот зазор формирует технологическую подушку безопасности, позволяя обнаружить и купировать сбой до наступления юридических последствий. Все коммерческие условия (размеры штрафов, компенсаций и процедура их выплат) не являются универсальными и всегда согласуются индивидуально юристами и финансистами.

Выбор критических пользовательских сценариев (User Journeys)

Попытка измерить доступность всех микросервисов, баз данных и фоновых очередей одновременно перегружает систему мониторинга ложными сигналами. Метрики надежности должны строиться вокруг критических пользовательских сценариев (Critical User Journeys, CUJ).

Почему нельзя усреднять «всю систему целиком»

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

Критические пути разделяют на ключевые цепочки взаимодействия:

вход в учетную запись (аутентификация);
работа поиска и навигация по каталогу;
добавление позиций в корзину;
проведение платежной транзакции.

Для каждого шага определяется собственный изолированный набор индикаторов.

Базовые метрики: доступность и задержка ответа

Для синхронных клиентских запросов используются два ключевых индикатора:

Доступность (Availability). Процент запросов, завершившихся корректным ответом (без ошибок 5xx на стороне бэкенда).
Задержка ответа (Latency). Доля запросов, обработанных быстрее установленного порога.

При анализе задержки средние значения (Average) использовать нельзя: они сглаживают пики и скрывают серьезные проблемы у части аудитории. Стандартом является оценка квантилей:

p90: 90% запросов отрабатывают быстрее 400 мс;
p99: 99% запросов отрабатывают быстрее 850 мс.

Комбинация нескольких порогов позволяет контролировать длинный хвост задержек (tail latency), от которого клиенты чаще всего страдают при пиковых нагрузках.

Дополнительные индикаторы качества

Для асинхронных процессов и систем пакетной обработки стандартных метрик доступности недостаточно. В таких архитектурах контролируют:

Свежесть данных (Freshness): отставание информации от момента ее генерации (например, синхронизация остатков на складе не должна задерживаться более чем на 3 секунды).
Полнота (Completeness): процент корректно сохраненных записей при фоновой передаче массивов данных.
Корректность (Correctness): отсутствие логических ошибок валидации и искажений структуры данных при парсинге.

Окно расчёта: почему скользящие 4 недели надежнее календарного месяца

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

Параметр	Календарный месяц	Скользящее окно (28 дней / 4 недели)
Поведение на границе периодов	1-го числа сбои автоматически списываются	Данные обновляются непрерывно день за днем
Оценка пользовательского опыта	Искаженная: инцидент 31-го числа забывается утром следующего дня	Объективная: авария учитывается в статистике ровно 28 дней
Управление бюджетом ошибок	Сложно планировать темп релизов в начале периода	Стабильный горизонт прогнозирования в любой момент
Основная область применения	Юридическая и финансовая отчетность по SLA	Инженерный мониторинг и управление качеством (SLO)

Проблема календарного окна

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

Преимущества скользящего 28-дневного окна

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

Совмещение временных срезов

На практике инженерные команды используют трехуровневую шкалу:

1 неделя (оперативный срез): для разбора недавних деградаций и оперативной корректировки задач текущего спринта.
4 недели (тактический срез): базовый интервал для отслеживания SLO и расходования бюджета ошибок.
1 квартал (стратегический срез): основа для принятия решений об архитектурных изменениях и пересмотре договоренностей с бизнесом.

Правила исключений: как отделить системный сбой от внешних факторов

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

Что допустимо исключать из расчёта

Нагрузочные испытания и пентесты. Запросы синтетических генераторов трафика при проверках на безопасность или устойчивость исключаются из SLO, если они изолированы и не затрагивают продуктовых клиентов.
Глобальные сбои интернет-магистралей. Проблемы на уровне трансграничных операторов связи или масштабные аварии корневых DNS-серверов, сделавшие сеть недоступной целиком в масштабах региона.
Согласованные инциденты внешних платформ. Если отказ произошел на стороне внешней платежной системы, при условии, что интеграционный контур отработал штатно (сработали очереди, резервирование или режим graceful degradation).
Невалидные клиентские события. Сетевые таймауты, вызванные переключением клиентского устройства между вышками сотовой связи, которые не привели к сбою бэкенда.

Фиксация исключений в спецификации SLO

Любое исключение фильтруется алгоритмически на уровне системы сбора метрик, а не применяется вручную постфактум. В техническом описании SLO заранее закрепляются:

Точка сбора телеметрии: балансировщик трафика, ingress-контроллер или трекинг событий в клиентском SDK.
Классификация кодов ошибок: ошибки серверов (500, 502, 503, 504) относятся к внутренним деградациям, а ошибки клиента (400, 401, 404) не списывают бюджет надежности.
Селекторы трафика: фильтрация по служебным HTTP-заголовкам или User-Agent для надежного отделения синтетического трафика от живых сессий.

Error Budget: баланс между скоростью релизов и стабильностью

Бюджет ошибок (Error Budget) — математический инструмент управления балансом между продуктовыми амбициями и надежностью системы.

Расчёт бюджета ошибок

Бюджет ошибок определяет допустимый объем неудачных событий, не нарушающий целевой уровень качества:

Error Budget = 100% - SLO

Если для ключевого сервиса установлен SLO доступности 99,9% в рамках 28-дневного окна, бюджет ошибок составляет:

100% - 99,9% = 0,1%

При нагрузке в 10 000 000 запросов за 28 дней допустимое число неуспешных операций составит:

10 000 000 ×0,001 = 10 000 ошибок

Пока суммарный объем сбойных событий за скользящий период не превышает 10 000, система находится в допустимом диапазоне риска.

Политика действий при исчерпании бюджета ошибок

Бюджет ошибок — это лимит допустимого риска, который расходуется на проверку продуктовых гипотез, архитектурные эксперименты и ускоренную поставку обновлений. При его обнулении вступает в силу утвержденный регламент:

Заморозка функциональных релизов (Feature Freeze). Приостанавливается выкатка новых фичей, способных внести нестабильность в работу платформы.
Перераспределение фокуса команды. До 100% времени спринта перенаправляется на устранение технического долга, оптимизацию запросов к базам данных, рефакторинг и ликвидацию узких мест.
Ужесточение процедур развертывания. Вводится обязательное тестирование по схеме канареечных релизов (canary deployment) с минимальным шагом наращивания трафика и расширенным мониторингом.
Возврат к стандартной разработке. Поставка новых фичей возобновляется только тогда, когда скользящее 28-дневное окно очистится от старых инцидентов и значение SLI вернется в зеленую зону.

Типичные ошибки при внедрении методологии

Стремление установить SLO на уровне 100%. Добиться абсолютной безотказности технически невозможно, а затраты на каждый дополнительный порядок надежности (переход с 99,9% на 99,99%) растут экспоненциально. Кроме того, 100% доступности на стороне сервера обесцениваются нестабильностью каналов связи у самих пользователей.
Единые показатели для разнородных сегментов. В B2B-сервисах целесообразно разделять цели: бесплатные и базовые тарифы могут обслуживаться по общему контуру, в то время как Enterprise-клиентам требуются выделенные ресурсы и повышенные гарантии по задержкам ответа.
Игнорирование регламентов бизнесом. Если продуктовые менеджеры воспринимают бюджет ошибок как внутреннюю метрику инженеров и продавливают релизы во время исчерпания Error Budget, система теряет смысл. Политика должна быть согласована на уровне технического и генерального руководства.

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

Почему SLO должно быть жестче, чем SLA в клиентском соглашении?

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

Почему нельзя ставить цель SLO 100%?

Абсолютная надежность останавливает любые изменения в кодовой базе. При нулевом бюджете ошибок любой деплой или обновление конфигурации несет критический риск срыва цели. Кроме того, инвестиции в создание распределенной инфраструктуры для достижения 100% доступности экономически не окупаются.

Что делать в первую очередь при исчерпании бюджета ошибок?

Первым шагом активируется протокол Feature Freeze: останавливается выкатка нового бизнес-функционала, а усилия инженеров перенаправляются на разбор причин сбоя, исправление технического долга и покрытие проблемных сценариев автотестами.

Кто утверждает показатели SLO: разработка или бизнес?

SLO утверждается совместно продуктовым лидером (CPO / Product Owner) и техническим руководителем (CTO / Head of SRE). Инженеры рассчитывают техническую возможность и стоимость поддержания заданного уровня, а продуктовая команда сопоставляет эти затраты с ожиданиями пользователей и рыночными требованиями.

Как фиксируются коммерческие условия компенсаций по SLA?

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

Как защитить бюджет ошибок, если сервис зависит от внешних платформ?

Зависимость от сторонних вендоров (например, платежных шлюзов) компенсируется внедрением шаблонов отказоустойчивости: очередей асинхронной обработки, таймаутов, паттерна Circuit Breaker и резервных маршрутов (fallback) для переключения на запасных провайдеров.

Вывод

Модель SLI, SLO и SLA переводит абстрактные споры о стабильности в понятные математические метрики и производственные правила. Фокусировка на критических пользовательских сценариях защищает от перегрузки второстепенными данными, 28-дневное скользящее окно гарантирует честную оценку доступности без календарных искажений, а бюджет ошибок становится объективным балансиром между скоростью доставки нового функционала и отказоустойчивостью платформы. В результате компания сохраняет предсказуемость бизнес-процессов, защищает себя от финансовых потерь и удерживает доверие клиентов.

SLA, SLO и SLI для цифрового сервиса: как связать обещания клиенту с метриками