Эксплуатация
SLA: как проверить обещанный уровень обслуживания сайта
Соглашение об уровне обслуживания: какие свойства услуги и в каких условиях обещаны, как их измеряют и что происходит при невыполнении согласованных условий.
Редакция:
В предложении написано «доступность 99,9%». Чтобы оценить это обещание, нужны объект проверки, период, формула и правила исключений. Доступность сервера, открытие каталога и доставка обращения могут измеряться по-разному. Сначала выясните, какое действие посетителя покрывает условие.
Эта страница помогает читать техническую часть предложения. Учебные числа ниже не являются SLA CoreWeb, условиями конкретного поставщика или шаблоном договора.
SLA, цель и фактический показатель
SLI — измеряемый показатель качества работы услуги. SLO — целевой уровень этого показателя за определённый период. SLA связывает согласованные условия обслуживания с последствиями их выполнения или нарушения. Такое разделение используется в книге Google SRE.
Например, доля успешных проверок каталога — показатель; требование «не ниже выбранного значения за календарный месяц» — цель. В соглашении дополнительно выясняют, какие доказательства принимаются, кто разбирает расхождение и какие действия предусмотрены при нарушении. Само число в презентации не отвечает на эти вопросы.
Учебный расчёт SLA-32: что попало в знаменатель
Для вымышленного каталога задали проверку раз в минуту: страница отвечает и содержит контрольный товар. Окно — с 1 сентября 2026 года 00:00 до 1 октября 00:00, UTC+3, то есть 30 суток и 43 200 минутных интервалов. Данные прочитаны 2 октября в 12:00, журнал полностью обработан по конец окна. Условная цель — не менее 99,9% успешных учитываемых интервалов. Это пример расчёта, не рекомендация по частоте проверок или целевому уровню.
| Часть журнала | Интервалы | Как учитываем в этом примере |
|---|---|---|
| Плановые работы | 60 | Заранее согласованное исключение; убраны из числителя и знаменателя |
| Проверка успешна | 43 100 | Входят в числитель и знаменатель |
| Проверка неуспешна | 30 | Входят только в знаменатель |
| Результат наблюдения отсутствует | 10 | Сохраняются как неизвестные; решение о них нельзя придумать после расчёта |
| Всего | 43 200 | Четыре непересекающиеся группы покрывают всё окно |
После исключения работ остаются 43 140 интервалов. Если все десять неизвестных были успешны, доля составила бы 43 110 / 43 140 ≈ 99,9305%. Если все были неуспешны — 43 100 / 43 140 ≈ 99,9073%. Обе границы выше учебной цели, но пробел наблюдения нужно сохранить в отчёте. Формальная оценка соглашения зависит от заранее установленных правил полноты данных и неизвестных результатов.
Если молча выбросить десять неизвестных интервалов, получится 43 100 / 43 130 ≈ 99,9304%. Это уже другой знаменатель. Такой процент не доказывает, что наблюдение покрывало весь согласованный период. Если плановые работы не исключены условиями, вычитать их тоже нельзя.
Для этой формулы 0,1% от 43 140 составляет 43,14 интервала. При целочисленном учёте 43 неуспешных интервала укладываются в цель, 44 — уже нет. Это арифметика учебной модели; пропущенная между проверками короткая авария могла остаться незамеченной. Один замер в минуту не доказывает непрерывную доступность всех действий сайта.
Какие условия меняют смысл процента
Попросите поставщика заполнить паспорт показателя до начала наблюдения:
- Объект: сервер, конкретная страница или законченный сценарий; какие зависимости входят в границы ответственности.
- Успех: ожидаемый статус, содержимое и допустимое время; откуда выполняется проверка.
- Окно: календарный или скользящий период, часовой пояс и время готовности отчёта.
- Состав данных: какие запросы или интервалы считаются, как отделяются тесты, повторы и некорректные запросы.
- Исключения и пробелы: условия плановых работ, отсутствие наблюдения, подтверждение и источник каждой исключённой записи.
- Разбор нарушения: кто получает уведомление, предоставляет журнал и согласует дальнейшие действия по условиям услуги.
Доля успешных запросов и доля успешных временных интервалов могут дать разные результаты. Документация Google Cloud описывает обе модели. В первом случае длительность сбоя нельзя получить простым умножением процента ошибок на число минут месяца: нагрузка в разные моменты может различаться.
Реакция поддержки и восстановление — разные события
Учебное обращение зарегистрировано в 10:00, специалист подтвердил начало работы в 10:20, сценарий восстановлен в 12:10. Прошло 20 минут до реакции и 130 минут до восстановления, если в условиях отсчёт обоих сроков начинается с регистрации. Обещание ответить за 30 минут само по себе не задаёт срок исправления.
Уточните рабочие часы, категории обращений, событие начала отсчёта и условия приостановки. Попросите показать, где фиксируются регистрация, реакция и проверенное восстановление. Автоматическое письмо «мы получили запрос» может не означать начало работы специалиста — значение каждого события должно быть определено.
Возвращение страницы в сеть также не подтверждает сохранность данных. Для допустимой потери изменений и проверки восстановления используйте разбор резервного копирования. Границы ответственности размещения описаны в термине «хостинг».
Вопрос, который стоит задать поставщику
«Покажите на одном обезличенном или учебном периоде исходные данные и расчёт нашего показателя: что считается успехом, что исключено, где пробелы, кто подтверждает результат и что предусмотрено при нарушении. Отдельно покажите отсчёт реакции и восстановления».
Сохраните ответ рядом с редакцией предложения. Для сравнения исполнителей внесите показатель, исключения, доказательство и открытые вопросы в сравнение предложений. Если метод измерения или условия ещё не определены, оставьте этот пункт неподтверждённым.