Uptime показывает фактическую доступность сайта, SLO задаёт её целевой уровень, а SLA закрепляет обязательство и последствия нарушения. Термины связаны, но отвечают на разные вопросы — смешивать их в одном проценте опасно.
Короткий порядок: определите важный пользовательский путь и способ измерения, задайте внутренний SLO, затем сравните его с SLA хостинга или подрядчика. Иначе хороший отчёт провайдера может соседствовать с неработающей формой заказа.
Uptime, SLI, SLO и SLA: в чём разница
| Термин | Что означает | Главный вопрос | | --- | --- | --- | | Uptime | Фактическая доля времени или успешных проверок, когда сайт был доступен по принятому правилу | Что произошло за период? | | SLI | Измеримый показатель: доступность, доля успешных запросов, задержка | Что и как измеряем? | | SLO | Целевое значение или диапазон для SLI | Какой результат приемлем? | | SLA | Соглашение с обязательствами и последствиями их невыполнения | Что обещано и что будет при нарушении? |
Uptime может быть одним из SLI, но не заменяет всю систему целей. Главная страница способна отвечать успешно, пока авторизация или оформление заказа не работает: общий процент хорош, а важный путь нарушен.
Формула и границы простоя разобраны в статье как считать uptime сайта. Здесь задача другая — превратить наблюдение в проверяемую договорённость.
Почему SLA хостинга не равно доступности сайта
SLA провайдера относится к описанному в договоре объекту: инфраструктуре, серверу, каналу или конкретной услуге. Пользователь проходит более длинную цепочку: DNS, TLS, CDN, веб-сервер, приложение, база данных и содержимое страницы.
Поэтому провайдер может выполнить свой SLA, а сайт останется недоступным из-за ошибки приложения, сертификата, DNS-записи или внешней зависимости. Условия измерения тоже различаются: в соглашении могут быть свои исключения, точка проверки, расчётный период и порядок подтверждения нарушения.
Внутренний SLO должен опираться на то, что важно посетителю, а не автоматически копировать показатель подрядчика.
Как задать SLO доступности сайта
1. Выберите пользовательский результат
Начните не с процента, а с действия: открыть посадочную, отправить форму, войти в кабинет, положить товар в корзину или получить ответ API. Для путей разной важности могут понадобиться отдельные цели, но не превращайте каждый доступный показатель в SLO.
2. Опишите успешное событие
Запишите URL, допустимый редирект, ожидаемый HTTP-ответ, нужный текст и приемлемое время ответа. Код 200 с технической заглушкой или пустой страницей не обязательно означает, что пользователь получил результат.
3. Зафиксируйте метод и окно измерения
Укажите источник данных, точки и частоту проверки, календарный или скользящий период, способ агрегации. Внешняя проверка с интервалом описывает отдельные наблюдения, а не непрерывное состояние между ними.
Короткие сбои могут не попасть в историю, если начались и закончились между запусками. Выбрать частоту по критичности страницы поможет разбор интервалов мониторинга.
4. Согласуйте исключения
Плановые работы, тестовые среды и ошибочные проверки нельзя удалять из расчёта задним числом ради красивого процента. Допустимые исключения и доказательства должны быть записаны заранее, а исходные события — сохранены для проверки.
5. Назначьте реакцию
Определите, кто разбирает инцидент, когда подключается подрядчик и какие факты нужны для обращения. У SLA последствия указаны в соглашении; у внутреннего SLO это может быть разбор причин, изменение мониторинга или повышение устойчивости критичного пути.
Шаблон измеримого SLO
Вместо «сайт должен почти всегда работать» используйте шаблон:
За [период] не менее [целевой доли] внешних проверок [точного URL или сценария] должны завершаться [критерием успеха] не дольше [порога]. Измерение выполняется [источником и частотой]. Исключаются только [согласованные условия]. При выходе за цель команда [действие].
Что такое бюджет ошибок
Бюджет ошибок — допустимая доля неуспешных событий внутри SLO. Для цели доступности он выражается как 100% − целевая доступность.
Считайте бюджет в тех же единицах, что и SLI. Если доступность определяется долей успешных запросов, бюджет относится к запросам; если длительностью недоступности — ко времени. Смешивать эти способы нельзя.
Бюджет помогает заранее связать отклонение с действием. Пока оно остаётся в согласованных границах, команда следует обычному плану; при быстром расходовании бюджета усиливает диагностику и снижает риск новых изменений.
Как проверить SLA поставщика
Перед сравнением внутреннего SLO с документом провайдера выясните:
- Какой сервис, адрес или компонент входит в обязательство?
- Что считается доступностью и где она измеряется?
- Каковы расчётный период и допустимые исключения?
- Кто фиксирует инцидент и какие доказательства принимаются?
- Каков срок обращения и какие последствия предусмотрены?
Если последствия не определены, это может быть техническая цель или маркетинговое обещание, а не полноценный SLA. Окончательный смысл задаёт текст конкретного договора, поэтому проверяйте условия, а не только процент на странице тарифа.
Какие данные нужны для проверки SLO
Сохраняйте время, URL, точку наблюдения, DNS- и TLS-результат, HTTP-код, конечный адрес после редиректов, время ответа, проверку ожидаемого содержимого, начало и окончание инцидента. Без истории итоговый процент трудно проверить.
Внешний мониторинг показывает сайт с отдельной точки в сети, но не заменяет логи приложения, серверные метрики и наблюдение за реальными сценариями. Для оплаты или сложной формы объединяйте внешние проверки с данными приложения и аналитикой ошибок.
Практический следующий шаг
Возьмите один критичный URL и запишите для него SLI, SLO, период, исключения и ответственного. Затем сопоставьте документ с SLA значимых поставщиков: станет видно, где их обязательство заканчивается раньше пользовательского пути.
Чтобы сравнивать цель с фактом, можно добавить сайт в Web-Puls и настроить регулярную внешнюю проверку ключевого URL. Начните с одного правила, накопите историю и уточняйте SLO, когда данные показывают, что определение не отражает реальный опыт посетителя.