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

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

Когда проект недоступен, последствия выходят за пределы ИТ

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

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

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

Чем больше процессов зависит от сайта, приложения или внутренней системы, тем раньше стоит подготовить этот план.

Домены, файлы и резервные копии у одного провайдера: что важно учесть

У одного поставщика могут одновременно находиться файлы проекта, базы данных, почта, резервные копии, DNS и панель управления доменами. Это удобно для повседневной работы, но создаёт общую зависимость: один инцидент может затруднить доступ сразу к нескольким важным сервисам.

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

Важно различать регистрацию домена, работу DNS и хранение файлов проекта. DNS-записи (ДНС-записи) указывают, на какой сервер направлять посетителей сайта и куда доставлять письма для домена. Сбой хостинга сам по себе не означает потерю регистрации домена или удаление файлов. Однако недоступность DNS может сделать проект недоступным по его адресу даже при исправном сервере, а недоступность панели — помешать оперативно изменить настройки. О разделении регистрации и DNS-хостинга можно прочитать в руководстве ICANN по защите учётных записей владельцев доменов.

Поэтому заранее стоит проверить:

• кто зарегистрирован владельцем домена и у кого находятся доступы к его управлению;
• где обслуживается DNS и как изменить серверы имён при недоступности текущего DNS-провайдера;
• сохранена ли вне хостинга копия DNS-записей: адресов серверов сайта (A и AAAA), настроек доставки почты (MX) и остальных записей, необходимых проекту;
• можно ли получить файлы, базы данных и резервные копии независимо от основной площадки;
• доступна ли почта для восстановления учётных записей при сбое этого же провайдера;
• кто выполнит переключение и проверит работу проекта после него.

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

Доверие к провайдеру и независимые резервные копии

Услуги резервного копирования у хостинга полезны. Но при проектировании защиты важно предусмотреть возможность получить данные, даже если основная площадка или её панель управления недоступны.

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

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

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

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

• база данных с заказами, заявками и учётными записями;
• изображения, документы и другие загруженные файлы;
• исходный код проекта;
• настройки приложения и сервера;
• сведения об интеграциях;
• инструкция по развёртыванию и проверке работы.

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

Важно также определить частоту копирования. Магазин, принимающий заказы в течение дня, и корпоративный сайт с ежемесячным обновлением страниц имеют разные требования. Частота резервирования должна учитывать, какой объём последних изменений бизнес может позволить себе потерять.

Когда бизнесу нужен собственный или резервный сервер

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

Поэтому начинать стоит с требований бизнеса. Какой простой допустим? Какие данные критичны? Нужно ли поддерживать готовую копию сервиса или достаточно возможности развернуть его из резервной копии?

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

При этом физическое расположение — только один из факторов. Несколько серверов могут зависеть от одной панели управления, сети или учётной записи. Эти общие зависимости тоже необходимо учитывать.

Резервную копию нужно проверить восстановлением

Надпись «копирование завершено» ещё не отвечает на вопрос, заработает ли проект после переноса.

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

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

Как сохранить связь с клиентами во время сбоя

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

Стоит заранее предусмотреть канал связи, который не зависит от основной площадки. Это может быть телефон, страница в социальной сети или другой доступный компании инструмент.

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

Бизнесу нужна команда, которая следит за инфраструктурой регулярно

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

Эти задачи можно закрепить за внутренними специалистами или передать команде сопровождения. В обоих случаях важно согласовать состав работ, порядок реакции на инциденты и ответственность участников.

Как КОСМОДЕВ может помочь вашему бизнесу

Проверим, сможет ли ваш бизнес восстановить проект, если основной хостинг недоступен. Покажем, каких копий, доступов и инструкций не хватает.

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

Обсудить проверку проекта с КОСМОДЕВ

Подход к резервированию и восстановлению подбирается под конкретный проект, допустимый простой и бюджет. Состав услуг и сроки реакции КОСМОДЕВ определяются отдельно при согласовании сопровождения.

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

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

Материал не содержит инструкций, рекомендаций, призывов, рекламы или популяризации способов обхода ограничений доступа к информационным ресурсам, в том числе к ресурсам, доступ к которым ограничен на территории Российской Федерации. КОСМОДЕВ не оказывает услуги по обходу ограничений доступа, не рекомендует использовать такие способы и не размещает инструкции по их применению.

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

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

Все названия компаний, сервисов, программных продуктов, платформ, товарные знаки, логотипы и иные обозначения принадлежат их правообладателям. КОСМОДЕВ не заявляет о связи, партнерстве, представительстве или принадлежности к указанным правообладателям, если это прямо не указано отдельно.

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