Отключение хостинга, готовим план Б до аварии

До первой серьезной аварии нужно проверить не только сервер, но и все точки, от которых зависит доступность сайта. Почему план Б для сайта нужно готовить до сбоя: во время инцидента уже поздно выяснять, где лежат резервные копии, кто имеет доступ к DNS и сколько времени занимает восстановление базы.

• Резервные копии: проверьте, создаются ли они по расписанию, где хранятся, шифруются ли и можно ли восстановить сайт из последней копии. Тестовое восстановление нужно проводить на отдельном окружении хотя бы раз в месяц.
• DNS и домен: убедитесь, что доступы есть минимум у двух ответственных, включено автопродление домена, указан актуальный email регистратора, а TTL DNS-записей не мешает быстрому переключению на резервный сервер.
• Хостинг и сервер: зафиксируйте лимиты CPU, RAM, диска, I/O, количество процессов и соединений. Важно понимать, при какой нагрузке сайт начинает отдавать 500-е ошибки или тормозить.
• База данных: проверьте размер, скорость запросов, наличие репликации, журналов и корректных прав доступа. Отдельно протестируйте восстановление не только файлов, но и актуального дампа базы.
• SSL-сертификаты: контролируйте дату истечения, способ выпуска и автоматическое продление. Просроченный сертификат способен остановить продажи не хуже падения сервера.
• Мониторинг: настройте проверки доступности страниц, ответа сервера, места на диске, ошибок 5xx, времени отклика и отправки форм. Уведомления должны приходить в Telegram, email или SMS, а не только в панель хостинга.

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

2 месяца SEO продвижения в подарок

Закажите у нас разработку сайта и сэкономьте 2 месяца SEO продвижения, потому как мы сразу проводим базовую SEO оптимизацию.

Заказать

Резервные копии, DNS и доступы: минимальный набор для быстрого восстановления

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

Резервные копии должны храниться отдельно от основного сервера. Копия на том же хостинге бесполезна при блокировке аккаунта, взломе или сбое диска. Минимальный регламент: ежедневный бэкап базы данных, еженедельный бэкап файлов, хранение минимум 3 последних версий, отдельное облако или внешний сервер. Раз в месяц нужно делать тестовое восстановление на техническом домене: так проверяется не факт наличия архива, а его работоспособность.

• Файлы сайта: шаблоны, загрузки, изображения, плагины, конфигурации.
• База данных: товары, заказы, пользователи, статьи, настройки CMS.
• DNS-зона: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC.
• Доступы: регистратор домена, хостинг, CMS, FTP/SFTP, SSH, база данных, CDN, почта.
• Контакты поддержки: хостинг, разработчик, администратор домена, подрядчик по рекламе.

DNS нужно держать под контролем владельца бизнеса, а не только подрядчика. При аварии достаточно изменить A-запись или переключить домен на резервный сервер, но это возможно только при доступе к панели регистратора и понимании текущих записей. TTL для критичных доменов лучше держать в пределах 300–900 секунд: тогда переключение пройдет быстрее.

На практике вопрос «Почему план Б для сайта нужно готовить до сбоя» упирается в минуты. Когда доступы собраны, бэкапы проверены, а DNS задокументирован, восстановление занимает часы, а не дни. Отдельный файл с инструкцией нужно хранить в защищенном менеджере паролей и обновлять после каждого изменения хостинга, CMS или подрядчика.

Как сократить простой, сохранить трафик и не потерять клиентов

Аварийный сценарий должен быть описан до первой критической ошибки. Почему план Б для сайта нужно готовить до сбоя: в момент отказа сервера, падения CMS или ошибки деплоя команда не тратит время на поиск ответственных, доступов и резервных копий, а действует по готовому регламенту.

Минимальный набор для снижения простоя — актуальный бэкап, резервная инфраструктура и понятная схема переключения. Бэкапы нужно хранить не только на основном сервере, но и во внешнем хранилище. Проверка восстановления обязательна: архив, который ни разу не разворачивали, нельзя считать рабочим.

• настройте ежедневные инкрементные и еженедельные полные копии файлов и базы данных;
• зафиксируйте RTO: допустимое время восстановления, например 30 минут или 2 часа;
• зафиксируйте RPO: допустимую потерю данных, например не более 15 минут заказов;
• подготовьте резервный DNS-сценарий с коротким TTL для быстрого переключения;
• храните доступы к хостингу, домену, CDN и репозиторию в защищённом менеджере паролей.

Чтобы не потерять органический трафик, важно корректно отдавать статус сервера. При временной недоступности используйте 503, а не 404 или пустую страницу. Для поисковых систем это сигнал, что сайт временно недоступен, а не удалён. Если часть страниц работает, не закрывайте весь сайт заглушкой.

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

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

Регламент действий команды при отключении хостинга

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

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

• Технический администратор открывает тикет у хостера с указанием времени сбоя, IP, домена, скриншотов ошибок и результатов трассировки.
• Руководитель проекта фиксирует инцидент в журнале: дата, время начала, затронутые сервисы, текущий статус.
• Разработчик проверяет актуальность резервной копии файлов и базы данных, доступность репозитория и инструкции по разворачиванию.
• SEO-специалист отслеживает ответы сервера, индексируемость ключевых страниц и риск массовых 5xx-ошибок.
• Менеджер по клиентским коммуникациям готовит короткое сообщение для поддержки, отдела продаж и, при необходимости, пользователей.

Если хостер не дает точный срок восстановления в течение 15–20 минут, запускается сценарий переноса на резервную площадку. Администратор поднимает окружение на запасном сервере, подключает последнюю стабильную копию, проверяет PHP, базу данных, SSL-сертификат, права на директории и работу форм.

После технической проверки меняются DNS-записи или переключается трафик через CDN. TTL для критичных доменов должен быть заранее снижен до 300 секунд, чтобы переключение не растягивалось на часы. До полного восстановления запрещены непроверенные правки в коде, обновления CMS и очистка резервных копий.

После запуска команда проверяет главную страницу, каталог, корзину, оплату, формы заявок, robots.txt, sitemap.xml и коды ответа. Финальный отчет содержит причину сбоя, время простоя, потери заявок и список мер, которые нужно выполнить до следующего инцидента.