Downtime: что это, как считать SLA и минимизировать простой | Глоссарий FREEHOSTING

Downtime

Время простоя
Downtime — Downtime — период, когда сервис недоступен пользователям: сайт не открывается, API возвращает 5xx, игровой сервер не пускает игроков. Считается в минутах за период и переводится в проценты доступности (uptime).

Определение простыми словами

Downtime бывает плановый (релиз, миграция БД, обновление ядра) и аварийный (упал хостинг, сгорел диск, DDoS). Для пользователя разницы нет — сайт не работает. Поэтому в SLA провайдеры обычно гарантируют доступность с учётом плановых окон, а компании-заказчики измеряют downtime своими внешними чекерами, не доверяя статусу хостера.

Связан напрямую с uptime: 99.9% доступности = 8.76 часа downtime в год, 99.99% = 52.6 минуты, 99.999% (пять девяток) = 5.26 минуты. Каждая девятка стоит на порядок дороже предыдущей.

Сравнение SLA по downtime

Uptime SLA Downtime в день Downtime в месяц Downtime в год
99% (две девятки) 14.4 мин 7.2 ч 3.65 дня
99.9% (три девятки) 1.44 мин 43.8 мин 8.76 ч
99.95% 43 сек 21.9 мин 4.38 ч
99.99% (четыре девятки) 8.6 сек 4.4 мин 52.6 мин
99.999% (пять девяток) 0.86 сек 26.3 сек 5.26 мин

Кейсы использования

  • Интернет-магазин с оборотом 1 млн ₽/день при downtime 1 час теряет в среднем 41 тыс. ₽ выручки + конверсию на следующие сутки.
  • Игровой сервер: 5 минут downtime в прайм-тайм = массовый отток в Steam-обзоры с минусом.
  • Banking API: 99.999% — нормативное требование ЦБ для процессинга, дешевле резервный ЦОД, чем штрафы.
  • Negative-сценарий: компания купила «99.9% SLA» и обнаружила, что компенсация считается только при downtime >15 минут одним куском. Десять микро-падений по 5 минут не компенсируются.
  • Postmortem-культура: каждый инцидент >5 минут разбирается письменно, фиксируются root cause, action items и owner. Корреляция с Load Average часто даёт первую гипотезу.

Технические детали

# Простой внешний чекер через cron + curl
* * * * * curl -fsS -m 5 https://example.com/health || 
  echo "$(date -u +%FT%TZ) DOWN" >> /var/log/downtime.log

# Подсчёт простоя за месяц из логов
awk '/DOWN/ {c++} END {print c" минут downtime"}' /var/log/downtime.log

# Расчёт SLA в процентах за период
python3 -c "d=43; total=43200; print(f'uptime={(1-d/total)*100:.4f}%')"

# Профессиональный мониторинг — несколько точек проверки
# UptimeRobot, Pingdom, StatusCake, Better Stack
# минимум 3 географически разнесённых точки и интервал 60 сек

# Плановый downtime через maintenance page (nginx)
location / {
  if (-f /var/www/maintenance.flag) { return 503; }
  try_files $uri $uri/ =404;
}
error_page 503 /maintenance.html;

Важная деталь — кто измеряет downtime. Хостер видит «сервер пингуется», заказчик видит «оплата не проходит». Истина обычно у внешнего мониторинга с проверкой бизнес-сценария (логин + покупка), а не плоского HTTP 200.

Частые вопросы

Кто должен измерять downtime — хостер или заказчик?

Истина у внешнего независимого мониторинга, который проверяет бизнес-сценарий (логин, покупка), а не просто пинг сервера. Хостер часто не видит, что приложение отдаёт 500.

Что такое плановый downtime?

Заранее объявленное окно для релиза, миграции, обновления железа. Обычно ночью, длится минуты-часы. По SLA не считается простоем, если согласовано с заказчиком за N часов.

Как добиться downtime близкого к нулю?

Blue/green деплой, кластер с health checks, географическое резервирование, графовое снижение трафика, автоматический failover БД. Стоимость растёт нелинейно с каждой девяткой.