«Сайт не открывается».

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

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

А если вместе с сайтом повреждены данные или произошёл взлом, простой — далеко не единственная проблема.

Самое неприятное, что заранее определить точный сценарий сбоя невозможно.

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

Поэтому хороший сайт — это не тот, который просто работает в обычный день.

Это сайт, с которым понятно, что делать, когда что-то идёт не по плану.

Сайт может упасть. Вопрос в том, сколько бизнес потеряет за время его простоя.

Почему простой сайта — это проблема бизнеса

Техническая ошибка редко остаётся только технической.

Допустим, интернет-магазин перестал принимать заказы.

Для разработчика это может быть ошибка одного модуля.

Для бизнеса это:

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

В B2B-сегменте последствия могут быть ещё менее очевидными.

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

Скорее всего, он просто откроет сайт конкурента.

Именно поэтому стоимость простоя нельзя оценивать только как «несколько часов работы программиста».

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

Цена сбоя — это не стоимость ремонта сайта. Это стоимость времени, в течение которого бизнес не может нормально работать.

Почему сайт может перестать работать

У сайта редко бывает одна универсальная причина сбоя.

Иногда проблема находится на сервере. Иногда — в коде. Иногда — в базе данных. Иногда причина вообще находится за пределами проекта.

Сервер и инфраструктура

Сайт может перестать отвечать из-за:

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

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

Сайт при этом может выглядеть вполне нормально.

До тех пор, пока однажды нагрузка или очередное изменение не покажет слабое место.

Ошибки в коде и обновления

Сайт — не статичная конструкция.

CMS обновляется. Меняются версии PHP и библиотек. Появляются новые плагины и модули. Добавляются интеграции.

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

В результате после seemingly обычного обновления появляются:

  • ошибки 500;
  • белый экран;
  • проблемы с авторизацией;
  • неработающие формы;
  • ошибки в корзине;
  • некорректная работа административной панели.

Именно поэтому обновление сайта — это не просто нажатие кнопки «обновить».

Проблема часто возникает не во время обновления, а из-за старых решений, которые годами никто не проверял.

База данных

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

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

Если база повреждена или потеряна, восстановить внешний вид сайта недостаточно.

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

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

Взлом

После атаки сайт может:

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

И здесь простая переустановка CMS далеко не всегда решает проблему.

Если не найти источник компрометации, вредоносный код может появиться снова.

«У нас есть резервная копия» — не всегда хороший ответ

Резервное копирование необходимо.

Но наличие файла с названием backup-final.zip ещё не означает, что сайт можно восстановить.

На практике возникают ситуации, когда:

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

Отдельная проблема — отсутствие актуальной информации о самом проекте.

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

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

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

Почему один сайт восстанавливается быстро, а другой — нет

На первый взгляд кажется, что восстановление сайта — простая задача: взять копию и вернуть её на сервер.

В реальном проекте всё зависит от его состояния.

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

Другой создавался годами:

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

Внешне оба проекта могут выглядеть одинаково.

Но при аварии разница становится очевидной.

В первом случае специалист понимает структуру проекта и быстро определяет причину.

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

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

Самый опасный сайт — тот, который «вроде работает»

Полностью недоступный сайт заметить легко.

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

Например:

  • главная страница открывается;
  • каталог работает;
  • карточки товаров отображаются;
  • форма выглядит нормально.

Но заявки в CRM не поступают.

Или интернет-магазин принимает заказ, но платёж не проходит.

Или клиент регистрируется, но письмо с подтверждением не отправляется.

Или данные из формы сохраняются некорректно.

Для владельца сайта проблема может остаться незаметной несколько дней.

За это время компания уже теряет клиентов.

Поэтому профессиональная поддержка сайта — это не только реакция на сообщение «страница не открывается».

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

Сайт может быть доступен для посетителя и одновременно недоступен для бизнеса.

Что происходит с сайтом, который годами не обслуживали

Большинство проблем не появляются из ниоткуда.

Они накапливаются.

Сначала перестают обновляться отдельные компоненты.

Потом появляются несовместимые версии.

Затем разработчики начинают обходить старые ограничения дополнительным кодом.

Постепенно растёт технический долг.

Через несколько лет владелец получает сайт, который:

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

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

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

Сайт не становится сложным за один день. Сложность накапливается незаметно — до первого серьёзного сбоя.

Когда достаточно оптимизации

Не каждый проблемный сайт нужно разрабатывать заново.

Иногда основа проекта вполне рабочая, но отдельные части требуют доработки.

Например:

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

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

Гораздо разумнее найти узкие места и устранить их.

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

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

Когда нужна новая разработка

Бывает и обратная ситуация.

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

Особенно это заметно, когда:

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

В таком случае очередной ремонт может только отложить неизбежное.

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

И здесь отказоустойчивость тоже начинается не с резервной копии.

Она начинается с правильных архитектурных решений.

Техническая поддержка — это не только «починить, когда сломалось»

У сайта есть свой жизненный цикл.

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

Если за этим не следить, проект постепенно начинает деградировать.

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

Она позволяет:

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

Это принципиально другой подход.

Не ждать, пока сайт перестанет работать, а поддерживать его в состоянии, при котором вероятность серьёзной аварии ниже.

Хорошая техническая поддержка стоит дешевле, чем срочное восстановление сайта после серьёзного сбоя.

А если сайт уже упал?

В этом случае главное — не усугубить ситуацию.

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

Особенно опасно это для сайтов, где есть:

  • интернет-магазин;
  • личные кабинеты;
  • CRM-интеграции;
  • платежи;
  • сложная база данных;
  • закрытая информация;
  • большое количество пользовательских данных.

Сначала нужно понять, что произошло.

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

Иногда сайт действительно можно быстро вернуть в рабочее состояние.

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

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

Четыре задачи, которые часто путают

В работе с сайтами есть четыре разных ситуации.

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

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

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

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

Иногда эти задачи пересекаются.

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

Именно поэтому универсального решения «для всех сайтов» не существует.

Что делать с сайтом до того, как он упадёт

Лучшее время подумать о восстановлении — до первого серьёзного сбоя.

Не обязательно сразу менять весь сайт или строить сложную инфраструктуру.

Для начала специалисту достаточно оценить состояние проекта:

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

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

Иногда достаточно технической поддержки.

Иногда требуется оптимизация.

Для старого проекта может быть разумнее планировать новую разработку.

А если проблема уже произошла — в первую очередь требуется восстановление.

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

Как Flex System помогает с сайтами

У сайта нет одного момента, когда работа с ним заканчивается.

Мы подключаемся на разных этапах его жизни — в зависимости от задачи бизнеса.

Разработка

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

Оптимизация

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

Техническая поддержка

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

Восстановление

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

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

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

Задача — подобрать решение под конкретный проект и стоимость проблемы для бизнеса.

Сайт должен переживать сбои

Невозможно гарантировать, что сайт никогда не столкнётся с ошибкой.

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

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

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

Если сайт работает стабильно — это ещё не значит, что с ним всё хорошо.

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

И чем важнее сайт для бизнеса, тем дороже становится экспериментировать с ним самостоятельно.

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

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

Сначала стоит разобраться, что с ним происходит.

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

Flex System помогает пройти этот путь — от разработки и оптимизации до постоянной поддержки и восстановления сайтов после серьёзных сбоев.