SLA, SLO и SLI помогают связать пользовательское ожидание с измерением и обязательствами сервиса. Путаница между ними приводит к странным требованиям: «у нас SLA 500 миллисекунд», хотя неизвестно, для какой операции, какой доли запросов и за какой период это обещано.
Для QA полезно различать три уровня: что измеряется, какую цель команда выбрала и что именно закреплено в соглашении. Тогда можно построить проверяемые критерии и не выдавать короткий тест за подтверждение месячной надёжности.
SLI: наблюдаемая характеристика сервиса
SLI, service level indicator, — количественный показатель качества обслуживания. Например, доля успешных допустимых запросов или доля сообщений, обработанных в пределах заданного времени. Чтобы показатель имел смысл, нужны точная формула и источник данных.
Запиши, какие события попадают в знаменатель и что считается хорошим исходом. Успех — не обязательно любой HTTP 200: ответ может содержать бизнес-ошибку. Пропущенный timeout тоже не должен исчезать из статистики только потому, что сервер не успел записать завершение запроса. Точка измерения должна отражать выбранную сторону пользовательского опыта.
SLO: целевое значение и окно
SLO, service level objective, задаёт цель для SLI: например, не меньше 99,9% допустимых запросов завершаются успешно за скользящие 30 дней. Для latency можно определить отдельную цель: не меньше 99% успешных запросов выполняются быстрее 500 мс.
Эти формулировки используют разные множества событий, что нужно зафиксировать. Иначе команда начнёт исключать медленные ошибки из времени ответа и случайно улучшит показатель. У цели также должны быть владелец, окно расчёта, правила исключений и смысл для пользователя. «100% всегда» без модели отказов редко помогает выбрать инженерное действие.
SLA: что закреплено соглашением
SLA, service level agreement, описывает согласованный уровень сервиса и условия его предоставления. В нём могут быть указаны методы расчёта, исключения, порядок обращения и последствия нарушения. Конкретное содержание определяется самим соглашением; одна аббревиатура не означает автоматически определённую компенсацию или штраф.
QA использует утверждённые условия как источник требований, а неоднозначности передаёт владельцам соглашения. Не нужно самостоятельно дописывать обещания клиентам. Внутренний SLO часто выбирают строже внешнего обязательства, чтобы оставить запас, но это решение команды, а не универсальное математическое правило.
Зачем нужен error budget
Error budget — допустимая доля или количество плохих событий в рамках выбранного SLO. При цели 99,9% и миллионе допустимых запросов бюджет составляет 1 000 неуспешных запросов. Это способ обсуждать надёжность в тех же единицах, что и цель.
Для временного SLO 99,9% за ровно 30 суток соответствующее допустимое время составляет 43,2 минуты. Но такой расчёт нельзя автоматически переносить на request-based SLO: при разной интенсивности трафика одинаковый простой затрагивает разное число запросов. Используй модель, записанную в требованиях, и не смешивай бюджеты разных показателей.
Как выбирать и проверять источник данных
Метрика на сервере удобна, но может не видеть ошибку DNS, отказ балансировщика или неработающий frontend. Синтетическая проверка видит путь снаружи, но охватывает лишь свои сценарии и точки запуска. Реальные клиентские события дают другую картину и требуют контроля полноты сбора.
Выбор источника зависит от цели. Для готовности отчёта важно событие доступности корректного файла, а не только принятие задания. Для API может быть достаточно наблюдений на входном шлюзе вместе с проверкой результата. QA должен понимать слепые зоны и сверять количество событий между слоями на управляемом тесте.
Практический пример: SLO каталога
Команда определила: допустимые запросы каталога учитываются на входном шлюзе, хороший результат — корректный успешный ответ; окно — скользящие 30 дней; цель — 99,9%. Запросы с заведомо некорректными параметрами исключаются по заранее утверждённому правилу, а технические ошибки и timeout остаются в расчёте.
За окно было 1 000 000 допустимых запросов и 1 200 плохих событий. SLI равен 998 800 / 1 000 000 = 99,88%. Цель нарушена, бюджет превышен на 200 событий. Хорошая средняя latency не меняет этот вывод. Но результат по SLA определяется отдельно, если соглашение использует другую область, окно или исключения.
Как QA проверяет расчёт
На тестовом стенде создай небольшой контролируемый набор: 980 корректных ответов, 10 технических ошибок, 5 timeout и 5 запросов, явно исключаемых правилом. При учёте timeout итоговый знаменатель — 995, число хороших событий — 980, SLI примерно 98,49%.
Сверь сырой журнал и дашборд, проверь отсутствие двойного учёта при retries, переход границы окна и восстановление после задержки доставки телеметрии. Измеримый результат — формула возвращает ожидаемое значение и одинаково трактует каждый класс событий. Если timeout потеряны, это дефект измерения даже при исправном UI.
Что можно подтвердить перед релизом
Нагрузочный тест проверяет выполнение согласованных критериев при конкретном профиле и длительности. Он может показать риск нарушения SLO, но двадцать минут стабильной работы не подтверждают цель за 30 дней в production.
Перед релизом полезно проверить сами измерения, обработку ошибок, деградацию и оповещения на управляемых событиях. В эксплуатации наблюдают окно SLO и скорость расходования бюджета. Краткий всплеск ошибок и устойчивое ухудшение требуют разной реакции, поэтому одна статичная красная граница на графике не всегда достаточна.
Что должен вынести QA из этой темы
SLI описывает измерение, SLO — целевой уровень, SLA — условия соглашения. Для проверки нужны формула, множество событий, окно и источник данных. QA помогает сделать эту систему честной: проверяет не только скорость и ошибки сервиса, но и корректность самого расчёта, сохраняя границы вывода теста.