Внеплановые работы (emergency maintenance) — технические работы на инфраструктуре провайдера, возникающие вне запланированного расписания и требующие немедленного вмешательства. Причины: отказ сетевого оборудования, перегрев серверного узла, критическая уязвимость в гипервизоре (например, Spectre/Meltdown в 2018 году потребовали экстренного патчинга всей индустрии), аварийное отключение электроснабжения или масштабная DDoS-атака.
Плановые vs Внеплановые работы
| Параметр | Плановые (scheduled) | Внеплановые (emergency) |
|---|---|---|
| Уведомление | За 24–72 часа | 0–30 минут или после начала |
| Причина | Обновление ПО, замена оборудования | Авария, уязвимость, атака |
| Длительность | Чётко ограничена | Непредсказуема |
| Засчитывается в SLA | Обычно нет | Да (зависит от договора) |
Правила компенсаций при внеплановых работах
В большинстве хостинг-договоров внеплановые работы по вине провайдера засчитываются в расчёт SLA uptime. Если суммарный простой за месяц превысил порог — провайдер выплачивает service credit на счёт. Простой по независящим от провайдера причинам (форс-мажор: отключение магистральных каналов, природные катастрофы, действия госорганов) обычно исключён из расчёта SLA.
Как узнавать о внеплановых работах
Инструменты для мониторинга статуса провайдеров:
- Status-страница провайдера — обычно status.<provider>.com (status.hetzner.com, status.digitalocean.com). Реализованы через Atlassian Statuspage или Cachet
- RSS-лента статуса — подписка на обновления инцидентов в Feedly или RSS-ридере
- Telegram/Discord каналы — большинство крупных провайдеров ведут официальные каналы уведомлений
- Email-уведомления — включить в настройках профиля в личном кабинете
Подготовка к внеплановым работам
Полностью избежать простоя при внеплановых работах нельзя, но минимизировать последствия можно:
- Регулярное резервное копирование данных — чтобы при экстренном сбое не потерять данные
- Внешний мониторинг (UptimeRobot) — чтобы знать о проблеме раньше, чем сообщит провайдер
- DR-план с запасным сервером у другого провайдера — для критичных проектов с SLA
- Настройка автоматического рестарта сервисов через systemd (
Restart=always) — для восстановления после коротких перезагрузок без ручного вмешательства - Процедура отката — если внеплановые работы совпали с деплоем вашего приложения, необходим чёткий план разделения причин инцидента
Что происходит во время внеплановых работ
При отказе сетевого оборудования провайдер выполняет: изоляция проблемного узла → переключение трафика на резервные каналы (если есть) → диагностика → замена оборудования или перенастройка → снятие изоляции. Физическая замена оборудования в дата-центре — 30-120 минут. Отказ программного компонента (гипервизора, сети хранения) — от 15 минут до нескольких часов. Внеплановые работы, длящиеся более 4 часов, обычно покрываются компенсацией по SLA.
Коды статуса HTTP 502/503 при внеплановых работах — признак перегрузки или перезапуска сервисов; 504 — таймаут при обращении к бэкенду.
Реальные примеры внеплановых работ
Значимые инциденты в индустрии, вызвавшие масштабные внеплановые работы:
- Meltdown/Spectre (2018) — критические уязвимости процессоров Intel/AMD/ARM. Все хостинг-провайдеры были вынуждены перезагрузить все физические серверы в течение нескольких дней для установки патчей ядра. Простой у большинства провайдеров: 15–30 минут на каждый VPS
- Outage Facebook/Instagram (2021) — 6-часовой сбой из-за ошибки в BGP-конфигурации
- Пожар в OVH Страсбург (2021) — физическое уничтожение одного из четырёх датацентров; тысячи клиентов потеряли данные из-за отсутствия резервных копий
Пожар в OVH показал, что даже крупный провайдер с SLA не гарантирует сохранность данных при физических катастрофах. Правило 3-2-1 для бэкапов: 3 копии, на 2 разных носителях, 1 в другой географической локации — защищает от подобных сценариев.