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

2026-08-20 11:43:40 Время чтения 7 мин 17

Привет, герой бизнеса!

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

В статье рассказываем, что держать на контроле, чтобы такие проблемы не становились неожиданностью.

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

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

Самый очевидный сценарий.

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

Как быстро команда узнает о проблеме и сможет восстановить работу?

Если о проблеме первым сообщает клиент, компания уже потеряла время.

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

Следующий вопрос — восстановление.

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

Бэкап становится частью плана: что восстанавливаем, из какой копии и за какое время можем вернуть сайт в рабочее состояние.

2. Что будет, если перестанет работать интеграция?

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

Например, интернет-магазин получает из 1С цены и остатки. Обмен остановился, сам сайт при этом никуда не делся, каталог открывается, товары можно найти и добавить в корзину. Только информация на сайте уже может быть устаревшей, так как товар закончился на складе или цена изменилась.

С CRM ситуация похожая. Форма на сайте работает, пользователь видит сообщение «Спасибо, заявка отправлена», но сама заявка из-за сбоя не доходит до CRM, то есть менеджер о новом обращении не узнает.

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

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

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

3. Обновили сайт и получили проблему на рабочем проекте

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

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

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

Перед изменениями важно понимать:

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

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

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

➡️ Скачайте бесплатный чек-лист по безопасности сайта на Битриксе из нашей «Геройской папки»

4. Что будет, если проблема уже внутри сайта?

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

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

Проверять нужно не только пользовательскую часть сайта, но и то, что происходит внутри проекта:

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

Отдельная история — доступы.

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

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

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

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

В итоге можно потерять часть поискового или рекламного трафика и, что ещё важнее,доверие пользователей.

Заключение

Полностью исключить технические сбои невозможно.

Но можно сделать так, чтобы проблема:

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

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