SiteGuard4 ноября 202617 мин чтения

SLA, SLO и SLI: как задать измеримые требования к работе сайта

Разница между SLA, SLO и SLI — в том, что мы измеряем, к какому результату стремимся и какие условия обслуживания согласовали. SLI показывает фактическое качество работы сервиса, SLO задаёт целевое значение этого показателя, а SLA закрепляет условия и последствия выполнения или нарушения договорённостей. Для сайта такая связка помогает заменить требование «чтобы всё работало» проверяемыми правилами: какие действия посетитель должен выполнить, за какое время и как подтвердить результат.

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

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

SLA, SLO и SLI простыми словами

Эти термины относятся к разным частям управления качеством. Необязательно сразу создавать большой регламент: даже для небольшого сайта полезно записать показатель, цель и способ проверки на одной странице. Общие определения приведены в руководстве Google SRE о целях уровня обслуживания.

Термин	Что означает	Пример для сайта	На какой вопрос отвечает
SLI — Service Level Indicator	Измеримый показатель определённого свойства сервиса	Доля отправок формы, обработанных по согласованным правилам	Как сервис фактически работал?
SLO — Service Level Objective	Целевое значение показателя за установленный период	Не менее 99,9% таких запросов за календарный месяц	Какой уровень считаем достаточным?
SLA — Service Level Agreement	Согласованные условия обслуживания, включая последствия выполнения или нарушения обязательств	Какие функции покрываются, как считается показатель, кто рассматривает инцидент и что предусмотрено условиями	О чём договорились стороны?

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

SLI тоже не обязан быть процентом. Это может быть задержка или другой количественный показатель. Для практической спецификации сайта часто удобна доля хороших событий: так видны и результат, и объём наблюдений. Главное — чтобы число описывало существенное для посетителя свойство, а не просто было доступно в красивом отчёте.

Начните с действия посетителя, а затем выбирайте метрику

Фраза «доступность сайта 99,9%» может означать ответ одной страницы, работу всего каталога или завершение покупки. Это разные объекты измерения. Сначала перечислите действия, ради которых человек приходит на сайт, и выберите те, отказ которых действительно требует реакции.

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

Функция	Полезный результат для пользователя	Что можно измерять
Каталог	Открывается нужная категория с ожидаемыми товарами	Корректность ответа и долю ответов быстрее выбранного порога
Форма заявки	Верные данные приняты и сохранены; ошибки ввода объяснены	Долю корректно обработанных отправок, время подтверждения, сохранность результата
Личный кабинет	Пользователь входит и видит свои данные	Успешность проверки авторизации и получения разрешённой информации
Обновление остатков	В карточке отображаются данные допустимой давности	Возраст доступного пользователю результата, а не только запуск задачи

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

Запишите границу операции. «Заявка сохранена в базе сайта» и «заявка появилась в CRM у менеджера» — два возможных результата с разными зависимостями. Выбирать следует тот, который нужен бизнесу и который удаётся наблюдать. Если измеряется только первый этап, это ограничение должно быть видно в названии показателя.

Как описать SLI без двусмысленного знаменателя

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

В руководстве Google SRE по внедрению SLO отдельно рассматриваются смысл показателя и его реализация. Для сайта это полезное разделение: сначала договориться, что важно посетителю, затем проверить, насколько выбранные журналы, метрики или внешние тесты способны это увидеть.

1. Выберите единицу учёта

Единицей может быть HTTP-запрос, попытка выполнения действия, завершённый сценарий или интервал времени. Не смешивайте их в одном расчёте. Один посетитель может отправить несколько запросов, а повтор после тайм-аута — создать ещё одно событие в журнале.

Если считаете запросы, каждый повтор входит в расчёт по тем же правилам, что и исходное обращение. Если считаете логические операции, потребуется устойчивый идентификатор и заранее определённое объединение повторов. Число уникальных заявок, посещений и HTTP-запросов обычно различается; ни одно из них нельзя подставлять вместо другого только потому, что оно доступно в аналитике.

2. Определите события, входящие в расчёт

Знаменатель — число событий, к которым применяются выбранные требования. Например, это все рабочие обращения к обработчику формы на согласованных доменах. Отдельно можно выделить известные технические проверки и тестовую среду, если они не входят в пользовательский показатель.

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

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

3. Установите критерий хорошего события

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

Нельзя объявить все ответы 4xx хорошими или удалить их из расчёта без разбора. Ожидаемый отказ по действительно неверному вводу отличается от ошибочного запрета доступа для обычного клиента. Аналогично HTTP 200 не заменяет проверку прикладного результата: значение успешного ответа зависит от метода и действия, что описано в справке MDN о 200 OK. Если приложение возвращает 200 вместе с сообщением о внутренней ошибке, это нужно отразить в критерии.

4. Запишите формулу и правила округления

SLI = хороших событий / всех учитываемых событий × 100%

Пример:
19 960 / 20 000 × 100% = 99,8%

Рядом с процентом сохраняйте числитель и знаменатель. Решение о выполнении цели принимайте по исходному отношению, а не по округлённой подписи. Показатель, округлённый до 99,90%, может оказаться немного ниже порога 99,9%; точность отображения не должна менять вердикт.

Запросы, время и внешние проверки: какой результат вы получаете

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

Способ	Что входит в расчёт	Что важно учесть
По запросам	Хорошие запросы относительно всех учитываемых запросов	Час с большим трафиком влияет сильнее часа с несколькими обращениями
По временным окнам	Окна, удовлетворяющие условию, относительно всех оцениваемых окон	Нужно определить длину окна, критерий качества и обработку отсутствующих данных
По внешним HTTP-проверкам	Успешные проверки выбранного URL из заданных точек	Сбой между проверками может остаться незамеченным; результат относится к наблюдаемому адресу и маршруту
По пользовательскому сценарию	Тестовые прохождения действия с проверкой результата	Нужно документировать сценарий, данные, авторизацию и отличие теста от реального использования

Различие между request-based и windows-based подходами описано в документации Google Cloud по мониторингу сервисов. При первом подходе агрегируют события обслуживания, при втором — оцениваемые интервалы. Период, за который проверяется цель, задаётся отдельно.

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

События на границе сервиса тоже не дают полного обзора. Журнал приложения не увидит обращение, которое не дошло до него из-за DNS или TLS. Внешняя проверка, в свою очередь, обычно не показывает все действия настоящих пользователей. Для важных функций полезно сопоставлять несколько источников, сохраняя отдельное значение каждого показателя.

Проверяйте доступность, скорость и корректность отдельно

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

Доля корректных и достаточно быстрых ответов

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

В учебном примере из 20 000 обращений 19 960 обработаны корректно. Из них 19 600 завершены не более чем за две секунды, а 360 — медленнее. Получаем два разных показателя:

Корректная обработка: 19 960 / 20 000 = 99,8%.
Корректная обработка не более чем за две секунды: 19 600 / 20 000 = 98%.

Если цель для первого показателя — 99,9%, а для второго — 99%, обе цели не выполнены. Деление 19 600 на 19 960 ответит на другой вопрос: насколько быстрыми были только корректно обработанные обращения. Такой показатель тоже можно использовать, но его название и смысл должны явно отличаться.

Где начинается и заканчивается время

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

Также определите единицы и границу сравнения. «Не более двух секунд» означает включённое значение 2,000 с; условие «меньше двух секунд» — другое правило. Для фонового действия отдельно укажите допустимое время до результата: быстрый ответ «принято в обработку» ещё не доказывает завершение задания.

Как учитывать частичную деградацию

Не объединяйте все адреса в один процент, если главная страница получает большую часть трафика, а оформление заказа — небольшую. Хороший результат массового маршрута может скрыть серьёзную проблему редкого, но важного действия. Для каталога, заявки и кабинета разумно иметь отдельные показатели.

То же относится к заметно различающимся регионам, типам устройств и группам пользователей. Сегментировать всё до единичных обращений не нужно, но уже известная зона риска заслуживает отдельного просмотра. Общий SLI показывает масштаб по выбранному весу событий; локальная проблема может требовать действий даже при выполненной общей цели.

Как выбрать SLO и период оценки

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

Опишите последствия отказа. Какие пользователи не выполнят действие и какие операции им доступны вместо него?
Соберите исходные измерения. Период должен включать характерные дни и нагрузки, а для сезонного проекта — учитывать соответствующие ограничения данных.
Проверьте наблюдаемость. Видны ли тайм-ауты, незавершённые запросы, частичные отказы и ошибки измерения?
Выберите достижимую цель. Зафиксируйте, почему она соответствует потребностям проекта и какие изменения нужны для её поддержания.
Назначьте владельца. Кто принимает решение, если качество ниже цели, и кто может пересмотреть требования?

Не устанавливайте 100% только потому, что любое отклонение неприятно. Такая запись не объясняет, какие ресурсы и решения потребуются для её поддержания. Наблюдаемые 100% на небольшом числе проверок также не доказывают отсутствие сбоев за пределами выборки.

Календарный период и скользящее окно

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

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

Что делать при небольшом трафике

При малом числе запросов один отказ сильно меняет процент. Если за период было 50 учитываемых обращений и одно завершилось технической ошибкой, показатель равен 98%. Такой результат нельзя объяснять исключительно процентом: рядом нужны абсолютные числа, тип отказа и длительность проблемы.

Когда событий не было, отношение 0/0 не определено. Не подставляйте автоматически 100%. Показывайте «нет событий» и используйте отдельные регулярные проверки для наблюдения за работоспособностью в паузах между реальными обращениями. При этом результаты тестов должны оставаться отличимыми от пользовательской статистики.

Пропуски измерений и исключения: как сохранить честный отчёт

Отсутствие записи может означать отсутствие обращения, поломку сборщика или потерю события. Эти состояния требуют разных действий. Если считать любой пропуск успешной работой, отказ наблюдения улучшит статистику; если всегда считать его отказом сайта, сбой системы измерения будет ошибочно приписан приложению.

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

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

Последний пункт особенно важен для объединения дней и серверов. Допустим, за первый день успешно выполнены 9 000 из 9 000 запросов, а за второй — 500 из 1 000. Общая доля успешных запросов составит 9 500 / 10 000 = 95%. Простое среднее двух дневных процентов, 100% и 50%, даст 75% — это уже показатель с одинаковым весом дней, а не запросов.

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

Пример SLI и SLO для формы заявки

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

Объект измерения здесь выбран намеренно узко: «обработать отправку по правилам». Поэтому штатный отказ по действительно неверным полям может быть хорошим техническим результатом. Он не считается принятой заявкой и не должен увеличивать показатель бизнес-конверсии.

Поле спецификации	Учебный пример
Функция	Обработка отправки основной формы обратной связи
Граница	Получение запроса на контролируемой границе сервиса → отправка корректного результата обработчика; предельный срок — 10 с
Единица	Один HTTP-запрос POST к условному маршруту /api/contact рабочего домена; повторный запрос учитывается отдельно
Знаменатель	Все учитываемые рабочие отправки формы на этот маршрут, включая технические ошибки и запросы без результата через 10 с
Хороший результат	Не позднее 10 с верная заявка сохранена с идентификатором и отправлено корректное подтверждение либо действительно неверный ввод получил предусмотренный ответ валидации
Плохой результат	Технический отказ, неверный прикладной ответ, необоснованный запрет доступа, потерянная запись либо превышение тайм-аута
SLI корректной обработки	Хорошие результаты / все учитываемые отправки
SLI быстрой корректной обработки	Хорошие результаты не более чем за 2 с / все учитываемые отправки
SLO	Не менее 99,9% корректных и не менее 99% корректных быстрых обработок
Период	Календарный месяц, UTC. Принадлежность определяется временем получения запроса: от 00:00 первого числа включительно до начала следующего месяца, не включая его. Итог фиксируется после классификации всех событий с учётом предела 10 с и задержки доставки измерений
Источники	Счётчик обращений на границе, результат обработчика и подтверждение сохранения; записи сопоставляются по идентификатору запроса
Исключения	Только заранее отмеченные технические тесты и обращения тестовой среды; правила классификации сохраняются вместе с версией документа
Недостаток данных	Отдельный статус и описание пробела; выполнение SLO не подтверждается по неполной выборке без установленного правила восстановления
Ответственный	Назначенный владелец функции и контакт технической поддержки

Проверим согласованность примера. Из 20 000 учитываемых отправок 19 880 создали запись, 80 получили корректный отказ валидации, а 40 завершились технической ошибкой. Число хороших результатов — 19 960; технический SLI равен 99,8%. Доля созданных записей среди всех этих обращений — 99,4%, однако это другая величина, которую нельзя подписывать тем же названием.

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

Оформлять требования полезно как отдельный документ с владельцем, датой утверждения и пересмотра. У Google SRE есть пример документа SLO, показывающий связь показателя, цели и ограничений измерения. Учебная таблица выше использует собственные критерии для формы; её числа не являются рекомендацией Google или универсальной нормой для сайтов.

Как проверить сам расчёт перед использованием

Метрика заслуживает доверия после проверки её поведения на известных исходах. Проведите контролируемые тесты на подходящем тестовом ресурсе или в согласованном режиме, который не создаёт реальные обращения менеджерам и не затрагивает данные клиентов. Заранее запишите ожидаемый вклад каждого события в числитель и знаменатель.

Контрольный случай	Ожидаемая классификация	Что проверить
Верная форма быстро создаёт запись	Учитываемое, корректное и быстрое событие	Запись существует; идентификаторы совпадают; событие не потеряно и не задвоено
Верная форма создаёт запись медленнее порога, но до тайм-аута	Корректное событие; не входит в быстрые	Медленный ответ не исчез из знаменателя
Ожидаемый отказ по ошибочному вводу	Корректная обработка; не созданная заявка	Причина валидации соответствует входу и опубликованным правилам
Технический отказ или истечение тайм-аута	Плохое событие в выбранном SLI	Отказ присутствует в учёте даже без успешной записи приложения
Разрыв сбора измерений	Недостаток данных	Он не превращается автоматически в успешную работу
Два запроса с повторной отправкой	Два запроса при выбранной единице учёта	Счётчик соответствует спецификации; уникальные бизнес-записи считаются отдельно

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

Как связать SLO с поддержкой и условиями SLA

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

И обратная ситуация: сервис уже восстановлен, но общий показатель ещё ниже цели из-за прошлой аварии. Это повод разбирать причины и планировать улучшения, а не бесконечно отправлять одинаковую тревогу о текущей недоступности. Различие между состоянием сервиса и соблюдением цели за период отражено, например, в описании данных SLO в Google Cloud.

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

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

Связанный показатель — бюджет ошибок (error budget): у цели ниже 100% есть допустимая доля плохих событий. Для request-based SLO 99,9% и 20 000 учитываемых запросов это 20 плохих запросов в данном периоде. В нашем примере их 40, поэтому цель нарушена. Какие изменения разрешать или приостанавливать после этого — отдельное управленческое правило, которое стоит согласовать заранее.

Частые вопросы о SLA, SLO и SLI для сайта

Нужны ли SLO небольшому сайту услуг?

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

Можно ли использовать один общий показатель на весь сайт?

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

Является ли конверсия сайта SLI надёжности?

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

Если ошибок не было, можно ли обещать 100% доступности?

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

Достаточно ли внешнего мониторинга для расчёта SLO?

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

Когда пересматривать SLI и SLO?

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

Подключите SiteGuard для внешнего HTTP-контроля доступности важных страниц. Используйте эти наблюдения в SLI, если его условия и границы соответствуют выбранной проверке.