Определение простыми словами
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 БД. Стоимость растёт нелинейно с каждой девяткой.