Накануне вирус уничтожил лендинг небольшой компании. Страница пропала целиком, и у владельца не осталось ни исходного кода, ни резервной копии. Единственным активом был один скриншот старой главной страницы. Мы вернули бизнесу рабочий сайт за несколько часов, но сама ситуация это хороший повод поговорить о том, почему до такой точки доходить нельзя.
История закончилась хорошо, но закончиться она могла иначе. Разберём, что именно произошло, во сколько это обходится бизнесу и как выстроить защиту, чтобы потеря сайта не превращалась в потерю клиентов и выручки.
Что на самом деле теряет бизнес, когда пропадает сайт
На первый взгляд кажется, что исчез просто файл с версткой. На деле компания в этот момент теряет лицо, через которое к ней приходят заявки. Лендинг это точка входа: реклама ведёт на него, клиенты ищут компанию и попадают на пустую или зараженную страницу, поисковые системы фиксируют недоступность. Каждый час простоя это упущенные обращения, а не абстрактная техническая неполадка.
Дальше включается репутационный эффект. Посетитель, который увидел сломанный или подозрительный сайт, редко возвращается позже, чтобы проверить, всё ли починили. Он уходит к конкуренту, и стоимость его повторного привлечения для бизнеса уже выше. Если сайт принимал заявки или платежи, к прямым потерям добавляется ещё и риск утечки данных клиентов, а это уже вопрос доверия и, в зависимости от страны, юридической ответственности.
Главный вывод здесь простой: простой и потеря данных это не строчка в отчёте айтишника, а деньги, репутация и клиенты. Поэтому относиться к ним надо как к финансовому риску, а не как к технической мелочи.
Корень проблемы: одна копия это ноль копий
В описанной истории беда не в самом вирусе. Вирус лишь обнажил то, что было заложено заранее: у компании не существовало рабочей резервной копии. Сайт жил в единственном экземпляре, и его потеря означала потерю всего.
В нашей практике это самая частая причина, по которой инцидент превращается в катастрофу. Бизнес исходит из того, что хостинг или подрядчик сами всё сохранят, но реальной проверенной копии под рукой не оказывается. Здесь работает старое инженерное правило: одна копия это фактически ноль копий, потому что она исчезает вместе с основной системой при пожаре, шифровальщике или ошибке администратора.
Отдельно подчеркнём слово проверенная. Бэкап, который никто никогда не разворачивал обратно, это не гарантия, а предположение. Архив может быть повреждён, неполон или сделан с настройками, при которых сайт не запустится. Резервная копия становится активом только тогда, когда есть подтверждённая процедура восстановления из неё, отработанная заранее, а не в момент аварии.
Как мы восстанавливали сайт из одного скриншота
Когда исходников нет, восстановление превращается в реконструкцию. У нас был один скриншот старой главной страницы, и из него мы воссоздали рабочий лендинг. Через двадцать минут страница выглядела аккуратно и пригодно к использованию, через четыре часа она уже работала на отдельном сервере. Не идеально, но у бизнеса снова появилось лицо, на которое можно вести трафик.
Для срочной реконструкции мы использовали инструмент быстрого прототипирования, который за один-два часа собирает рабочий фронтенд на Node.js по минимальному набору вводных. Такие инструменты хорошо закрывают именно аварийный сценарий, когда время важнее тонкой настройки. Но у этого подхода есть нюансы, которые честно стоит назвать:
- Жёсткий выбор технологий. Инструмент настойчиво выдаёт свой стек, например Node.js, даже если вы просили другое. В режиме аварии это приемлемо, в долгую может не совпасть с вашей инфраструктурой.
- Привязка к платформе. Часть ресурсов, например изображения, уходит во внешнее хранилище, а не в ваш репозиторий. Без переноса активов появляется зависимость от конкретного сервиса, и это уже новый риск вместо устранённого старого.
- Нужна отправная точка. С полного нуля инструмент не угадает фирменный стиль и тон. Скриншот или хотя бы общее направление здесь критичны.
То есть быстрая реконструкция это рабочее аварийное решение, но именно аварийное. Оно возвращает бизнес в строй, но не заменяет нормальной инфраструктуры с резервным копированием.
Что выстроить заранее, чтобы не реконструировать с нуля
Правильный момент думать о восстановлении это до инцидента, а не после. Минимальный набор, который мы рекомендуем бизнесу, выглядит так. Во-первых, регулярные автоматические бэкапы и кода, и базы данных, хранящиеся отдельно от основного сервера. Во-вторых, периодическая проверка восстановления из этих копий, чтобы знать реальное время возврата в строй, а не надеяться на него. В-третьих, базовая защита самого сайта: контроль доступов, обновления, отделение пользовательских данных от публичной части.
Для бизнеса эти меры переводятся в один понятный показатель: сколько часов и денег вы потеряете, если завтра сайт исчезнет. С продуманной схемой восстановления ответ измеряется в часах и заранее известен. Без неё ответ это рулетка, в которой ставка ваша выручка и репутация.
Итог
Вирус, который съел лендинг, лишь сделал видимой проблему, существовавшую и без него: у компании не было проверенной резервной копии. Историю удалось превратить в победу, но цена импровизации это часы простоя и реконструкция вместо спокойного восстановления за минуты. Бэкапы и отработанная процедура восстановления стоят несопоставимо дешевле, чем потеря клиентов и репутации в момент аварии.
Если вы не уверены, что ваш сайт и данные переживут серьёзный сбой, имеет смысл проверить это до того, как проверит случай. Мы предлагаем бесплатный технический аудит инфраструктуры: посмотрим, как у вас устроены резервное копирование и защита, оценим реальное время восстановления и подскажем, где слабые места. Оставьте заявку на странице https://myod.it/contact-us/
