Когда перестает открываться сайт, пользователь обычно видит только конечный результат: сервер недоступен. Дальше причина быстро формулируется как «упал хостинг» или «что-то сломал провайдер».

Даже если проект размещен на VPS, его доступность зависит не только от самой виртуальной машины. За ней скрываются электропитание, охлаждение, сетевое оборудование, магистральные операторы, системы хранения, гипервизоры и физическая площадка. Отказ любого из этих компонентов может сделать сервис недоступным, даже если с самим сервером ничего не произошло.

Хороший пример — пожар, случившийся 7 мая 2026 года в дата-центре NorthC в нидерландском Алмере.

Что произошло в Алмере

Возгорание началось не в серверном зале, а в задней части здания, где находилось техническое оборудование. По имеющимся сообщениям, серверы и носители данных непосредственно огнем повреждены не были. Однако по требованию экстренных служб питание площадки пришлось полностью отключить.

В результате перестала работать инфраструктура IBM Cloud в локации Amsterdam 03. С перебоями также столкнулись Утрехтский университет, Статистическое управление Нидерландов, транспортные организации, государственные и медицинские сервисы. Некоторые системы оставались недоступными несколько дней.

Временные системы электропитания и охлаждения удалось запустить только 13 мая — спустя шесть дней после начала пожара. После этого оборудование клиентов включалось поэтапно и под контролем специалистов.

Этот случай интересен не только масштабом. Он показывает, что для остановки сервисов необязательно уничтожать серверы. Достаточно потерять один из критических элементов, без которого оборудование нельзя безопасно эксплуатировать.

Что находится между пользователем и приложением

Упрощенно путь запроса можно представить так:

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

Например, VPS может продолжать работать, но быть недоступным из-за сетевой аварии. Сеть может работать, но физический узел будет выключен из-за перегрева. Сервер может отвечать на ping, но приложение завершится из-за нехватки памяти. Само приложение может быть исправно, но зависнуть в ожидании недоступной базы данных или стороннего API.

Для конечного пользователя все эти ситуации выглядят одинаково: страница не открывается.

Где проходит граница ответственности

В инфраструктуре нет универсальной границы, после которой начинается или заканчивается ответственность хостинг-провайдера. Она зависит от модели услуги.

Один провайдер может одновременно быть владельцем ЦОД, оператором сети и поставщиком облачной платформы. Другой арендует стойки у независимого дата-центра. Поэтому формулировка «виноват хостер» без определения первопричины почти ничего не объясняет.

Но и ссылка на внешнюю аварию не должна автоматически снимать с провайдера ответственность.

Провайдер отвечает за те решения, которые находятся в его зоне контроля:

• выбор площадок и поставщиков;

• резервирование собственных узлов и сетей;

• мониторинг инфраструктуры;

• своевременное информирование клиентов;

• соответствие фактического уровня доступности заявленному;

• наличие вариантов резервного размещения и восстановления.

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

Почему резервные системы не всегда спасают

Дата-центры проектируются с резервированием электропитания, охлаждения и каналов связи. Однако резервирование отдельных компонентов не означает, что площадка не может остановиться полностью.

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

Для оценки таких рисков используется понятие домена отказа — группы компонентов, которые могут перестать работать из-за одного события.

Два VPS могут находиться:

• на одном физическом сервере;

• на разных серверах, но в одной стойке;

• в разных стойках, но в одном машинном зале;

• в разных залах, но в одном здании;

• в разных зданиях, но с общим сетевым или энергетическим узлом.

Формально серверов два. Фактически единая точка отказа все еще существует.

То же относится к резервным копиям. Бэкап на соседнем диске защищает от случайного удаления файла, но не от потери узла. Копия на другом сервере того же ЦОД может не помочь при остановке площадки. А реплика базы данных не является полноценным бэкапом: ошибочная операция или поврежденные данные могут синхронно попасть на обе стороны.

Бэкап, репликация и отказоустойчивость — разные вещи

Эти механизмы часто объединяют словом «резервирование», хотя они решают разные задачи.

Резервная копия позволяет восстановить данные на определенный момент времени. Она не обязана обеспечивать быстрое переключение.

Репликация создает актуальную копию данных или сервиса. Но при ошибке приложения, шифровании или некорректном удалении проблема может распространиться на реплику.

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

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

Как выбирать архитектуру без избыточных затрат

Не каждому проекту требуется два дата-центра и автоматическое переключение. Отказоустойчивость стоит денег и усложняет сопровождение.

Архитектуру стоит выбирать не по принципу «чем больше серверов, тем лучше», а исходя из двух показателей:

• RTO — сколько времени сервис может оставаться недоступным;

• RPO — какой объем последних данных допустимо потерять.

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

Для распределенной инфраструктуры можно использовать серверы в разных странах: например, основной VPS в Нидерландах и резервный сервер в другой европейской локации. Но такое размещение имеет смысл только при настроенной репликации, переключении трафика и регулярной проверке восстановления.

Примерная схема может выглядеть так:

Конкретная конфигурация зависит от приложения. Состояние хранить и переносить сложнее, чем статические файлы или stateless-контейнеры. Иногда резервный сервер можно подготовить заранее и включать вручную. В других случаях переключение должно выполняться автоматически за несколько минут.

Что стоит проверить у своей инфраструктуры

Первый вопрос — не «какой uptime указан на сайте провайдера», а «что произойдет, если основная площадка станет недоступна».

Полезно заранее выяснить:

1. Где физически размещены основные и резервные серверы.

2. Находятся ли резервные копии в другом домене отказа.

3. Сколько времени займет восстановление из бэкапа.

4. Кто принимает решение о переключении на резервную площадку.

5. Где хранятся доступы, инструкции и конфигурации.

6. Работает ли DNS, панель управления и система мониторинга независимо от основного сервера.

7. Когда последний раз выполнялось тестовое восстановление.

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

Главный вывод из аварии в Алмере

Пожар в NorthC не означает, что резервирование дата-центров бесполезно. Оно снижает вероятность отказа отдельных компонентов, но не способно полностью исключить потерю площадки.

Сертификаты, генераторы, дублирующие линии и противопожарные системы уменьшают риск. Они не отменяют физические ограничения и решения экстренных служб. Поэтому при проектировании критичных систем необходимо допускать сценарий, в котором весь ЦОД временно становится недоступным.

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

Клиент, со своей стороны, должен определить допустимый простой и выбрать соответствующую архитектуру. Потому что главный вопрос не в том, может ли когда-нибудь отключиться дата-центр.

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