Что такое uptime сайта и как его рассчитывать

Uptime сайта — доля времени, в течение которого выбранный сервис считается доступным по заранее определённому критерию. Обычно показатель выражают в процентах: 99%, 99,9%, 99,99%. Чем ближе значение к 100%, тем меньше времени сервис мог находиться в состоянии недоступности за выбранный период.

Самая распространённая ошибка — считать uptime абстрактной характеристикой «сервера». Без указания периода, точки проверки и условия успеха процент мало что говорит. 99,9% за неделю и 99,9% за год — одинаковый процент, но совершенно разное допустимое время простоя.

Формула uptime

Базовый вариант:

Uptime = (общее время − время недоступности) / общее время × 100%

Если за месяц длительностью 30 дней сайт был недоступен 43 минуты 12 секунд, его доступность примерно соответствует 99,9%.

Важно заранее определить, что считается downtime. Например, только отсутствие TCP/HTTP-ответа или также HTTP 500, превышение времени ответа и неправильный JSON.

Сколько простоя скрывается за процентом доступности

Приблизительные значения для непрерывного периода:

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

Почему период измерения принципиален

Представим один 30-минутный инцидент.

За сутки он даст доступность около 97,9%. За 30 дней тот же инцидент даст примерно 99,93%. Поэтому фраза «наш uptime 99,9%» без периода измерения неполна.

Для эксплуатационной аналитики полезно хранить историю и сравнивать одинаковые окна: день с днём, месяц с месяцем, текущие 30 дней с предыдущими 30 днями.

Что именно считать доступным

Главная страница

Самый простой вариант — периодически выполнять HTTP-запрос к / и считать успешным ожидаемый код ответа.

Но он показывает только доступность конкретного URL.

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

Для SaaS или магазина важнее могут быть:

• /login;
• личный кабинет;
• страница оформления заказа;
• API endpoint;
• webhook;
• JSON health endpoint.

Главная может отвечать 200, пока API авторизации возвращает 500. Формальный uptime главной останется высоким, но бизнес-функция будет недоступна.

Содержимое ответа

Для API одного 200 OK иногда недостаточно. Если endpoint должен возвращать определённую структуру или значение, доступность полезно определять через более содержательный критерий.

Как рассчитывать uptime по результатам проверок

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

доступность по проверкам = успешные проверки / все проверки × 100%

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

Более точные системы учитывают временные интервалы между состояниями и заранее определённую модель начала/окончания инцидента.

Как интервал мониторинга влияет на картину

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

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

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

Uptime сервера и uptime сайта — не одно и то же

Машина может быть включена и отвечать на ping, пока веб-приложение возвращает 500. Nginx может быть запущен, пока upstream-приложение недоступно. Поэтому инфраструктурная доступность узла не заменяет внешнюю HTTP-проверку пользовательского URL.

Полезно разделять уровни:

хост → сеть → reverse proxy → приложение → зависимость → бизнес-функция

Каждый уровень отвечает на свой вопрос.

Чем uptime отличается от SLA, SLO и SLI

Uptime — измеренный показатель доступности.

SLI — конкретный измеряемый индикатор уровня сервиса, например доля успешных HTTP-запросов.

SLO — целевое значение индикатора, например не менее 99,9% успешных запросов за 30 дней.

SLA — соглашение с пользователем или заказчиком, которое может включать обязательства, исключения, методику расчёта и последствия нарушения.

Не стоит использовать эти понятия как полные синонимы.

Какие события не всегда нужно считать downtime

Это зависит от вашей методики. Возможные исключения:

• заранее объявленное техническое обслуживание;
• недоступность тестового endpoint, не влияющего на пользователей;
• ошибка конкретного клиента;
• внешняя проблема, явно исключённая условиями SLA.

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

Как измерять uptime сайта на практике

1. Определите критичный URL.
2. Определите ожидаемый HTTP-код или диапазон кодов.
3. Задайте допустимый timeout.
4. Выберите интервал проверки.
5. Выполняйте проверку из внешней точки, а не только с того же сервера.
6. Сохраняйте результаты во времени.
7. Фиксируйте начало и завершение инцидентов.
8. Рассчитывайте процент за одинаковые периоды.

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

Частые ошибки при оценке uptime

Смотреть только на средний процент

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

Проверять только один URL

Главная страница может не отражать состояние логина, API или оплаты.

Считать ping доказательством работы сайта

Ping проверяет сетевую доступность на другом уровне и не доказывает успешную обработку HTTP-запроса приложением.

Менять критерии задним числом

Если сегодня 500 считается downtime, а завтра его исключили из отчёта ради красивой цифры, сравнение периодов теряет смысл.

Что считать хорошим uptime

Универсального значения нет. Требование определяется стоимостью простоя и архитектурой сервиса. Для личного проекта 99% может быть приемлемым, а для критичного платёжного компонента — нет.

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