Готовность к аварии хостинга: что настроить заранее, чтобы сайт не встал

Ночью 2 ноября 2026 года у крупного российского хостера произошёл сбой: перестали открываться панель управления, сайты клиентов, часть виртуальных серверов, возникли перебои с почтой и DNS. Отдельная деталь, которая важнее самого сбоя: страница статуса хостера лежала вместе с сайтом — она размещена в той же доменной зоне. В результате узнать, что происходит, было негде, кроме стороннего канала.

Разберём на этом примере, что владелец интернет-магазина может сделать заранее, чтобы чужая авария не превращалась в остановку продаж, и что делать в первые часы, если она уже случилась.

Что произошло и почему это касается не только клиентов хостера

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

Показательный момент: запрос к домену хостера и к его статус-странице возвращал ошибку разрешения имён у нескольких независимых резолверов. То есть домен был делегирован, но серверы, которые должны отвечать на запросы, не отвечали. Сайт при этом может быть полностью исправен — он просто «не находится» по имени.

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

Почему статус-страница, которая лежит вместе с сайтом, бесполезна

Статус-страница нужна ровно в тот момент, когда инфраструктура сломана. Если она живёт на той же инфраструктуре, домене и DNS, что и сайт, — в момент аварии её не будет. Это относится не только к хостеру: та же логика у страницы «сайт временно недоступен» на вашем собственном домене.

Практическое правило: аварийный канал связи должен быть на чужой платформе. Для нас это Telegram-канал, для кого-то — внешний статус-сервис. Проверить просто: откройте свой аварийный канал в момент, когда сайт лежит. Если он тоже лежит — канала нет.

Шаг 1. DNS — не у хостинга

Главная настройка, которая чаще всего отсутствует: доменные записи обслуживаются там же, где сайт. Тогда падение хостинга уносит и сайт, и почту, и поддомены, и любые сервисы на домене.

Что сделать:

1. Перенести зону на отдельного провайдера DNS: бесплатный тариф Cloudflare (зона, управление TTL, базовая защита от DDoS), Яндекс DNS или NS регистратора. Ключевое — не название, а то, что NS не находятся в инфраструктуре хостинга.
2. Хранить у себя экспорт зоны: список всех записей файлом (A, AAAA, CNAME, MX, TXT, CAA). Без него переезд превращается в восстановление по памяти, а забытая запись DKIM ломает почту уже после аварии.
3. Записать TTL. При смене NS старые значения живут в кэшах резолверов до истечения TTL — в практике это часы, в худшем случае до двух суток.

Оговорка: у любого внешнего DNS-провайдера бывают свои сбои. Поэтому второй пункт — экспорт зоны — важнее выбора конкретного сервиса.

Шаг 2. Бэкапы в трёх местах, у разных провайдеров

Схема 3-2-1 в переводе на магазин: три копии, два разных носителя или провайдера, одна копия вне вашей инфраструктуры.

Практическая реализация:

1. Копия 1 — рабочая, на хостинге. В расчёт трёх копий не идёт: в день аварии её может быть физически не достать, панель недоступна.
2. Копия 2 и 3 — два разных объектных хранилища (S3) у разных провайдеров. Ежедневный дамп базы и архив файлов, хранение 14–30 дней.
3. Файлы сайта — в git. Если код и шаблоны в репозитории, для восстановления нужны только база и загруженные пользователями файлы.

Про цену: тарифы меняются, но порядок такой — холодное объектное хранилище стоит порядка 1–2 ₽ за гигабайт в месяц, обычное — 2–3 ₽. База на 20 ГБ в холодном классе — десятки рублей в месяц. Держать те же данные на диске сервера с ежедневным бэкапом дороже.

Отдельно про статику: картинки товаров, PDF-каталоги и видео стоит держать в хранилище с репликацией или за CDN. В разобранном примере сайт на другом хостинге работал, а обложки из хранилища на аварийном хосте не открывались — визуально «сайт сломан», хотя каталог и корзина живы.

Шаг 3. Проверять не наличие бэкапа, а восстановление

Бэкап, из которого ни разу не восстанавливали, — это надежда. Проверка занимает час и делается раз в квартал:

1. Развернуть копию на отдельном сервере (не на проде, не рядом с продом).
2. Открыть каталог, карточку товара, корзину.
3. Оформить тестовый заказ, дойти до оплаты в тестовом режиме эквайринга.
4. Сверить, что база не отстала: количество заказов и последняя дата в дампе.
5. Записать в журнал: дата, кто проверял, что не сошлось, что исправили.

Пункт, который пропускают чаще всего, — оплата. Восстановленный магазин, который не может провести платёж, не восстановлен.

Шаг 4. Мониторинг извне, а не с того же сервера

Мониторинг внутри сервера не заметит, что сервер недоступен: агент мониторинга упадёт вместе с ним. Нужен внешний сервис (UptimeRobot и аналоги) с проверкой раз в 1–5 минут и оповещением в мессенджер.

Что проверять, кроме главной:

1. Каталог и карточку товара — там шаблоны и запросы к базе.
2. Корзину и оформление заказа — самый дорогой для магазина сценарий.
3. API оплаты и колбэк эквайринга, если он у вас свой.
4. Медиа на поддомене хранилища — отдельный адрес, отдельная точка отказа.
5. Сертификат: срок действия и валидность цепочки.

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

Шаг 5. Почта — отдельно от сайта

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

1. Перенести почту на отдельного провайдера: Яндекс 360 для бизнеса (тарифы от нескольких сотен рублей за ящик в месяц) или Mail.ru для бизнеса.
2. Настроить SPF, DKIM и DMARC. DMARC начать в режиме наблюдения, чтобы не отрезать себе легитимные письма.
3. Держать резервный адрес на другом домене и заранее решить, кому он принадлежит и кто его читает.

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

Шаг 6. «Паспорт сайта» на одну страницу

В аварии время уходит не на починку, а на поиск доступов. Одна страница в менеджере паролей решает проблему:

1. Домен и регистратор, дата продления, кто владелец аккаунта.
2. NS и где хранится экспорт зоны.
3. Хостинг, IP-адрес, панель, кто администратор.
4. Где база: сервер, имя, пользователь, где пароль.
5. Где картинки и скрипты: хранилище, бакет, домен раздачи.
6. Где почта: провайдер, MX, кто владелец аккаунта.
7. Где бэкапы и когда последняя успешная копия.
8. Кто отвечает по договору: подрядчик, его телефон, часы реакции.
9. Логины и пароли — только в менеджере паролей, не в документе.

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

Шаг 7. Первые 60 минут аварии

Порядок, который экономит часы:

1. Проверить, отвечает ли домен: dig NS ваш-домен.ru +short и dig ваш-домен.ru @1.1.1.1. Пустой ответ или SERVFAIL — проблема на уровне DNS, а не в коде сайта.
2. Проверить сервер напрямую по IP, если доступен: лежит конкретная машина или не отвечает вся цепочка.
3. Не менять NS и MX в панике. Смена NS без копии зоны — это способ потерять поддомены и почту после восстановления.
4. Поставить понятную заглушку, если сайт недоступен, и указать, как связаться и заказать.
5. Написать клиентам, которые ждут заказ: лучше сухое сообщение, чем тишина.
6. Зафиксировать время начала и что именно не работало — это понадобится для разбора и для страховых случаев.

Решение о переезде принимают не в первый час. В первый час собирают факты.

Чек-лист на неделю

1. Узнать, где живут NS вашего домена, и выгрузить зону файлом.
2. Проверить, где лежит бэкап, и попробовать скачать его не из панели хостинга.
3. Настроить второй S3 и ежедневную копию базы.
4. Поставить внешний мониторинг на главную, каталог, корзину и хранилище картинок.
5. Вынести почту с хостинга или проверить, что MX не на нём.
6. Заполнить «паспорт сайта».
7. Проверить, что аварийный канал связи доступен, когда сайт лежит.

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

Чего не делать

1. Хранить DNS в инфраструктуре хостинга.
2. Считать единственный бэкап в панели хостинга резервной копией.
3. Менять NS в первые часы аварии, не имея на руках выгруженной зоны.
4. Платить за «срочный переезд сегодня» людям, которых вы не проверяли.
5. Обещать клиентам сроки восстановления, которых не знает даже провайдер.