Что такое аптайм сайта и как его правильно считать

Аптайм сайта — доля времени, когда сайт или сервис доступен пользователям и отвечает так, как ожидается. Обычно его выражают в процентах: 99%, 99.9%, 99.99%. На практике вокруг этой простой идеи возникает много вопросов: считать ли медленные ответы сбоем, что делать с ошибками 500, учитывать ли плановые работы, какой интервал проверки выбрать.

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

Что такое аптайм сайта

Аптайм сайта — это время, в течение которого сайт доступен и корректно отвечает на запросы пользователей или внешней системы проверки. Противоположная метрика — даунтайм, то есть время недоступности.

Простой пример:

• за месяц сайт должен был работать 30 дней;
• суммарно он был недоступен 43 минуты;
• остальное время отвечал успешно.

В этом случае аптайм будет близок к 99.9%.

Ключевое слово здесь — «корректно». Сайт может формально принимать TCP-соединение, но отдавать ошибку 500. Или открывать главную страницу, но не давать оформить заказ. Или отвечать через 25 секунд, когда для пользователя это уже практически отказ. Поэтому аптайм всегда зависит от того, что именно вы считаете рабочим состоянием.

Для лендинга доступность может означать успешный HTTP-ответ главной страницы. Для интернет-магазина — возможность открыть каталог, добавить товар в корзину и перейти к оплате. Для API — ответ эндпоинта /health, /ready или реального бизнес-метода с кодом 200.

Аптайм нужен не только devops-команде. Владельцу сайта он показывает, теряются ли заявки и продажи. Разработчику помогает видеть последствия релизов. Поддержке даёт объективный аргумент в диалоге с пользователями. А для подрядчиков и клиентов аптайм часто становится частью SLA.

Аптайм, даунтайм, доступность и SLA: в чём разница

Эти термины часто смешивают, хотя они описывают разные вещи.

1) Аптайм — процент времени, когда система была доступна. Это числовая метрика за конкретный период: день, неделю, месяц, квартал.

2) Даунтайм — суммарное время недоступности. Его обычно считают в минутах или часах. Если аптайм за месяц составил 99.9%, даунтайм — примерно 43 минуты за 30 дней.

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

4) SLA — соглашение об уровне сервиса. В SLA могут быть прописаны целевые значения доступности: 99.5%, 99.9%, 99.99%, исключения, порядок компенсаций, окна обслуживания. Подробнее про допустимый простой при разных уровнях SLA есть отдельный разбор: SLA 99.9% и 99.99%: сколько минут простоя допустимо.

5) SLI и SLO — термины из практики SRE. SLI — показатель, который измеряем; SLO — цель, к которой стремимся. Например, SLI: «доля успешных HTTP-запросов за 30 дней», SLO: «не ниже 99.9%». Если вы строите систему метрик глубже, полезно разобраться в статье Что такое SLI, SLO и SLA.

Главный вывод: аптайм — это измерение факта. SLA — договорённость. SLO — внутренняя цель. Даунтайм — обратная сторона аптайма.

Формула аптайма: как считать процент

Базовая формула выглядит так:

Аптайм % = (общее время - время простоя) / общее время × 100

Или короче:

Аптайм % = доступное время / общее время × 100

Пример для месяца в 30 дней:

• общее время: 30 × 24 × 60 = 43 200 минут;
• простой: 60 минут;
• доступное время: 43 140 минут.

Считаем:

43 140 / 43 200 × 100 = 99.861%

Округлять такую цифру нужно аккуратно. 99.861% — это не 99.9%, если вы используете строгую математику и SLA. Округление до одного знака после запятой может скрыть десятки минут простоя.

Есть и обратная формула — сколько простоя соответствует нужному аптайму:

Допустимый простой = общее время × (1 - аптайм / 100)

Например, для 99.9% за 30 дней:

43 200 × (1 - 99.9 / 100) = 43.2 минуты

То есть 99.9% — это не «почти никогда не падает», а до 43.2 минуты простоя в месяц. Для 99.99% это уже около 4.32 минуты в месяц. Разница в одной девятке сильно меняет инженерные требования.

Есть два распространённых способа считать аптайм.

1) По времени инцидентов — фиксируем начало и конец каждого сбоя, суммируем длительность. Такой способ удобен для отчётов и SLA, но требует точного определения момента начала и восстановления.

2) По результатам проверок — считаем долю успешных проверок. Например, мониторинг делает запрос каждую минуту. За сутки было 1440 проверок, из них 1435 успешных. Аптайм по проверкам: 1435 / 1440 × 100 = 99.65%.

Второй способ проще автоматизировать, но он зависит от интервала проверки. Если сайт упал на 30 секунд между двумя минутными проверками, сбой можно не заметить. При проверке раз в 5 минут короткие инциденты будут выпадать из расчёта ещё чаще. Поэтому для серьёзных сервисов интервал выбирают осознанно, а не «как по умолчанию». Об этом подробнее: Как выбрать интервал проверки сайта.

Что считать простоем

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

1) Полная недоступность — сайт не открывается, соединение не устанавливается, DNS не резолвится, сервер не отвечает, истекает таймаут. Это самый очевидный даунтайм: пользователь не может попасть на сайт вообще.

2) Ошибки сервера — ответы 500, 502, 503, 504 почти всегда нужно считать простоем для соответствующего URL или сервиса. Технически сервер ответил, но полезную функцию не выполнил. Если такие ошибки повторяются, это деградация доступности, а не «сайт работает». Для диагностики полезны материалы про ошибку 502 Bad Gateway и ошибку 503 Service Unavailable.

3) Ошибки клиента — 404, 403, 401, 429 не всегда означают простой. Если мониторинг проверяет публичную главную страницу и внезапно получает 403, это проблема доступности. Но если закрытый эндпоинт без токена отвечает 401, это нормальное поведение. Код ответа нужно оценивать в контексте проверяемого сценария.

4) Таймауты и слишком медленные ответы — если сайт отвечает за 40 секунд, формально он может вернуть 200, но для пользователя это отказ. Поэтому в проверках задают порог: например, считать запрос неуспешным, если ответ не получен за 5 или 10 секунд. Порог зависит от типа сервиса: для API он обычно строже, чем для тяжёлой административной страницы.

5) Частичная недоступность — главная страница открывается, но не работает оплата, личный кабинет или API. Если для бизнеса критичен конкретный сценарий, его нужно мониторить отдельно: один GET / не покажет, что пользователи не могут оформить заказ.

6) Ошибочный контент — сервер возвращает 200, но вместо сайта отдаёт страницу заглушки, ошибку приложения в HTML или пустой ответ. Поэтому иногда проверяют не только статус-код, но и наличие ожидаемой строки в теле ответа. Например, Оформить заказ, account_id, status: ok.

7) Проблемы TLS и сертификатов — истёкший SSL-сертификат, ошибка цепочки доверия или несовпадение имени домена делают сайт недоступным для большинства пользователей. Это тоже влияет на аптайм, если проверка имитирует реальный HTTPS-запрос. Связанная тема — почему важен мониторинг SSL-сертификатов.

Хорошее правило: считайте сайт доступным только тогда, когда пользовательский или API-сценарий действительно может быть выполнен. Не сводите аптайм к тому, что «порт 443 открыт».

Период расчёта и «девятки» доступности

Аптайм всегда считается за период. Одна и та же система может иметь:

• 100% за последние 24 часа;
• 99.7% за неделю;
• 99.95% за месяц;
• 99.5% за год.

Без периода цифра почти ничего не значит. Фраза «у нас аптайм 99.9%» должна сопровождаться уточнением: за какой интервал, по каким проверкам и с какими исключениями.

Чаще всего используют такие периоды:

1) Сутки — удобно для оперативного контроля, но слишком мало для выводов о стабильности: один короткий сбой заметно портит процент.

2) Неделя — полезна для командной ретроспективы и анализа релизов. Если каждый вторник после выкладки падает аптайм, это быстро видно.

3) Месяц — типичный период для SLA, отчётов клиентам и внутренних целей.

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

«Девятки» — это разговорное обозначение уровней доступности:

Каждая следующая девятка стоит дороже предыдущей. Нельзя просто «захотеть 99.99%» — нужны резервирование, балансировка, автоматическое восстановление, контроль зависимостей, безопасные деплои, быстрые откаты и нормальная наблюдаемость.

Высокий аптайм за месяц не гарантирует хороший пользовательский опыт: сайт может не падать полностью, но регулярно тормозить. Поэтому аптайм стоит смотреть вместе с latency, ошибками и насыщением ресурсов — это и есть golden signals (latency, traffic, errors, saturation).

Почему аптайм легко посчитать неправильно

Ошибки в расчёте аптайма часто не связаны с математикой. Формула простая — проблемы начинаются с данных и критериев.

1) Считать только серверный uptime — команда смотрит на uptime Linux и видит, что сервер работает 120 дней. Но сайт мог падать из-за Nginx, приложения, базы данных, DNS, SSL или внешнего API. Аптайм сервера не равен аптайму сайта.

2) Проверять только из одной точки — если мониторинг находится в той же сети или дата-центре, он может видеть сайт доступным, пока пользователи из других регионов сталкиваются с проблемами маршрутизации, DNS или CDN. Для публичных сайтов полезны проверки из разных локаций.

3) Игнорировать короткие сбои — при интервале проверки 5 минут инцидент длительностью 2 минуты может не попасть в статистику. Формально отчёт красивый, но пользователи проблему видели.

4) Считать плановые работы как «не считаются» без правил — иногда плановый даунтайм исключают из SLA, но это должно быть заранее описано: когда можно проводить работы, сколько они длятся, как уведомляются пользователи. Если исключать любые неудобные инциденты задним числом, аптайм теряет смысл.

5) Принимать любой 200 OK за успех — приложение может вернуть 200 со страницей ошибки, пустым JSON или текстом maintenance. Нужна проверка содержимого или бизнес-сценария.

6) Не отличать реальные сбои от false positive — мониторинг тоже может ошибаться: временная проблема сети у точки проверки, DNS-кэш, одиночный пакетный сбой. Поэтому обычно используют повторные проверки, подтверждение из нескольких локаций и разумные правила алертов. Подробнее: Что такое false positive в мониторинге.

7) Смешивать разные сервисы в одну цифру — главная страница, API, админка, CDN-статика и платёжный сценарий имеют разную критичность. Один общий аптайм может скрыть проблему в самом важном месте.

Корректный расчёт начинается не с таблицы, а с определения: что именно проверяем, откуда, как часто, какой ответ считаем успешным и как обрабатываем пограничные случаи.

Как настроить мониторинг аптайма

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

Базовая настройка выглядит так.

1) Выберите критичные URL — не ограничивайтесь главной страницей. Для сайта это может быть /, страница авторизации, корзина, оформление заказа. Для API — /health, /ready и один-два реальных метода. Health check должен отражать состояние зависимостей, но не быть слишком тяжёлым. Практические детали есть в статье про health checks на практике.

2) Определите успешный ответ — задайте ожидаемые HTTP-коды: чаще всего 200, иногда 204, 301 или 302, если редирект ожидаем. Для API проверьте тело ответа: например, {"status":"ok"}. Для HTML-страницы — наличие стабильного текста.

3) Настройте таймаут — решите, сколько можно ждать ответа. Если пользователи считают страницу сломанной после 10 секунд, мониторинг не должен терпеливо ждать минуту.

4) Выберите интервал проверки — чем меньше интервал, тем быстрее обнаружение и точнее статистика коротких инцидентов. Но слишком частые проверки создают лишнюю нагрузку и могут давать больше шума. Для большинства сайтов разумно начинать с 1–5 минут, а критичные API проверять чаще.

5) Используйте подтверждение сбоя — одиночная неудачная проверка не всегда означает реальный инцидент. Повторная проверка через несколько секунд или подтверждение из другой локации помогает снизить false positive.

6) Настройте уведомления — алерты должны приходить туда, где команда реально реагирует: Telegram, email, Slack, webhook, дежурный канал. Но не нужно уведомлять всех о каждом кратком чихе — иначе появится alert fatigue, и важные сигналы начнут игнорировать. См. как настроить алерты без alert fatigue.

7) Храните историю — для расчёта аптайма нужны данные за период: успешные проверки, сбои, длительность инцидентов, время восстановления. Без истории невозможно нормально обсуждать SLA и стабильность.

Отдельно стоит разделять мониторинг доступности и мониторинг инфраструктуры. Первый отвечает на вопрос «может ли пользователь воспользоваться сервисом?». Второй — «что происходит внутри: CPU, RAM, диск, база, очереди, сетевые соединения?». Нужны оба слоя: если доступность упала, инфраструктурные метрики помогают быстро понять причину.

Как улучшать аптайм без самообмана

Повысить аптайм — не значит подкрутить отчёт или увеличить интервал проверки. Цель в том, чтобы пользователи действительно реже сталкивались с отказами.

1) Уберите единые точки отказа — если один сервер, одна база, один балансировщик или один DNS-провайдер ломают весь сайт, аптайм будет ограничен их надёжностью. Не всё нужно сразу дублировать, но критичные компоненты должны быть понятны.

2) Делайте безопасные релизы — часть простоев возникает не из-за железа, а из-за деплоев. Помогают health checks, canary, blue-green deployment, быстрый rollback, миграции БД без блокировок. Если релиз регулярно даёт 502 или 500, проблема не в мониторинге.

3) Следите за зависимостями — база данных, Redis, внешний платёжный API, CDN, объектное хранилище, почтовый сервис могут быть причиной недоступности пользовательского сценария. Аптайм сайта зависит не только от веб-сервера.

4) Настройте резервные копии и восстановление — бэкап сам по себе не повышает текущий аптайм, но сокращает время восстановления после аварии. Для баз данных это критично. Например, для PostgreSQL пригодится инструкция по автоматическому бэкапу PostgreSQL.

5) Анализируйте каждый инцидент — после сбоя нужно понять не только «что упало», но и почему мониторинг сработал именно так, сколько времени заняло обнаружение, кто получил уведомление, почему восстановление заняло столько минут. Для разовых аварий полезен план действий: что делать, если упал сайт.

6) Разделяйте цели по критичности — не все части системы требуют одинакового уровня доступности. Публичный API оплаты и внутренняя админка могут иметь разные SLO. Это снижает стоимость и делает цели реалистичными.

7) Не прячьте деградацию за аптаймом — если ошибок мало, но p95/p99 latency растёт, пользователи всё равно страдают. Аптайм должен быть частью набора метрик, а не единственным индикатором здоровья.

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

FAQ

Что такое аптайм простыми словами?

Аптайм — это процент времени, когда сайт работает и доступен пользователям. Если за месяц сайт был недоступен 43 минуты, его аптайм примерно равен 99.9%.

Какой аптайм считается хорошим?

Зависит от проекта. Для небольшого сайта может быть достаточно 99–99.5%. Для коммерческого сервиса часто целятся в 99.9%. Для критичных систем нужны 99.99% и выше, но это требует более сложной архитектуры.

Плановые работы входят в даунтайм?

Только если так определено в ваших правилах или SLA. Иногда плановые окна исключают из расчёта, но это должно быть согласовано заранее, а не после инцидента.

Почему мониторинг показывает, что сайт доступен, а пользователи жалуются?

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