Что такое downtime сайта и чем он опасен

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

Поэтому вопрос «сколько downtime было у сайта» невозможно корректно ответить, пока не определено, что именно считается доступностью.

Downtime и uptime

Uptime показывает долю времени доступности, downtime — время недоступности.

Если период составляет 43 200 минут, а сервис был доступен 43 170 минут:

downtime = 43 200 - 43 170
downtime = 30 минут

Связанная статья «Что такое uptime сайта и как его рассчитывать» подробнее разбирает проценты доступности и влияние периода.

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

Критерий нужно задавать до начала измерения.

Для небольшого сайта:

GET / → HTTP 200 за допустимое время

Для SaaS:

/login → доступен
/api/health → ожидаемый HTTP-код
критичный API → корректный JSON

Для интернет-магазина бизнес-критичны каталог, корзина, checkout и платёжный сценарий.

Если контролировать только /, можно получить высокий «uptime» при сломанной оплате.

Полный и частичный downtime

Полный

Примеры:

• DNS не разрешает домен;
• TCP-соединение не устанавливается;
• TLS-handshake завершается ошибкой;
• все ключевые URL отвечают 5xx;
• origin недоступен за proxy.

Частичный

Примеры:

• главная 200, API 500;
• каталог работает, checkout 503;
• сайт доступен из одной сети, но недоступен из другой;
• одна replica за load balancer сломана;
• только авторизованные запросы завершаются ошибкой.

Частичный отказ сложнее обнаружить ручной проверкой.

Почему downtime опасен

Пользователь не может завершить действие

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

Короткие сбои остаются незамеченными

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

Периодические проблемы трудно расследовать

Через час система снова работает, а точное начало сбоя неизвестно. История проверок даёт временную привязку для server logs.

Деградация может перейти в каскадный отказ

медленная БД
↓
растёт очередь
↓
заняты worker
↓
растёт latency
↓
proxy начинает отдавать 504

Поэтому полезно контролировать не только downtime, но и признаки деградации до него.

Одна неудачная проверка — это downtime?

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

Политика объявления инцидента должна учитывать цену ложного срабатывания и цену позднего обнаружения реального сбоя.

Как измерять downtime при дискретных проверках

Допустим:

12:00 — OK
12:05 — FAIL
12:10 — FAIL
12:15 — OK

Мы знаем, что в 12:00 сервис был доступен, к 12:05 уже был недоступен, в 12:10 оставался недоступен и к 12:15 восстановился. Но точную секунду начала и окончания между проверками не знаем.

Поэтому методика расчёта должна быть стабильной.

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

При интервале 5 минут двухминутный сбой может полностью пройти между проверками.

Чем чаще проверка:

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

Частоту выбирают по критичности сервиса.

Уровни недоступности

DNS

Домен не разрешается или ведёт на неправильный адрес.

TCP

Адрес известен, но соединение с портом не устанавливается.

TLS

TCP есть, но защищённое соединение не проходит проверку.

HTTP

Сервер доступен по сети, но возвращает нежелательный код, например 500, 503 или 504.

Application

HTTP-код может быть успешным, но приложение сообщает об ошибке.

Business function

Технические уровни отвечают, но пользователь не может завершить критичное действие.

Эти уровни нельзя сводить к одной проверке ping.

Почему ping не измеряет downtime сайта

Возможны ситуации:

ping → работает
HTTPS → не работает

и наоборот:

ping → запрещён firewall
HTTPS → работает

Для веб-сервиса внешний HTTP/HTTPS-запрос ближе к пользовательскому опыту.

Плановые работы считаются downtime?

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

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

Медленный сайт — это downtime?

Зависит от критерия. Если условие успеха только HTTP 200, ответ за 20 секунд может формально быть доступным. Но пользовательский опыт уже плохой.

Availability и latency лучше контролировать отдельно.

Как отличить реальный downtime от ложного срабатывания

Проверьте:

1. повторяется ли ошибка;
2. совпадает ли она из другой точки/сети;
3. разрешается ли DNS;
4. устанавливается ли TCP/TLS;
5. какой HTTP-код;
6. ломается один URL или несколько;
7. есть ли server-side errors в то же время.

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

Для каждого эпизода фиксируйте timestamp, URL, тип ошибки, response time, request ID, deployment, ресурсы, proxy logs, application logs, состояние БД и внешних зависимостей.

После нескольких эпизодов ищите повторяемость: backup, Cron, ETL, deployment, пик трафика, autoscaling.

Как уменьшать downtime

• устранять single points of failure там, где это оправдано;
• использовать корректные readiness-проверки;
• задавать timeout;
• контролировать pools и capacity;
• иметь rollback;
• мониторить зависимости;
• тестировать критичные маршруты после релиза;
• анализировать повторяющиеся инциденты;
• контролировать систему снаружи.

Как мониторинг помогает

Автоматическая проверка показывает последнюю успешную проверку, первую ошибку, последовательность failures, момент восстановления и изменения latency.

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

Базовый набор проверок небольшого production-сервиса

1. Главная страница.
2. Критичный пользовательский URL.
3. API endpoint.
4. SSL-сертификат.
5. Важная Cron/heartbeat-задача.

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

Типичные ошибки

Считать uptime хоста uptime приложения

VM может работать, а приложение — нет.

Считать HTTP 200 достаточным для API

JSON может содержать ошибочное состояние.

Игнорировать частичный отказ

Сломанная оплата может быть важнее недоступной информационной страницы.

Не фиксировать критерий

Без определения успеха процент доступности нельзя интерпретировать.

Практический чек-лист

1. Определить сервис или функцию.
2. Задать критерий успеха.
3. Выбрать интервал.
4. Определить правило подтверждения инцидента.
5. Сохранять время и тип failures.
6. Фиксировать восстановление.
7. Разделять availability и latency.
8. Анализировать повторяющиеся причины.
9. Проверять критичные сценарии отдельно.
10. Использовать одинаковую методику между периодами.