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

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

1. Временно заменить динамические блоки статическими. Например, вместо типичных для интернет-магазина AJAX-подборок «Рекомендуем», «Популярное» и «С этим покупают» показывать заранее сформированный и одинаковый для всех список товаров.

2. Ещё один вариант — оперативно увеличить объём оперативной памяти (RAM) у хостера. И, если сайт на 1С-Битрикс, то перевести файловый кэш на Memcached (сервер, позволяющий сохранять кэш не в файлах, а в оперативной памяти). Это может снизить нагрузку на диск и ускорить работу сайта. Главное — проверить, что проблема именно в файловом кэше, и учесть нагрузку при прогреве нового кэша.

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

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

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

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

Дальше — быстрые шаги:

• Включить кеширование, чтобы сервер не собирал страницы заново.
• Временно убрать всё необязательное: поиск, рекомендации, лишнюю аналитику, второстепенные блоки.
• Ограничить автоматические запросы и ботов — в пике они часто создают лишнюю нагрузку.
• Добавить мощности, если сайт упирается в возможности сервера.

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

Нас не раз рекомендовал евангелист eBay/Magento как команду по оптимизации проектов по всему миру. В таких ситуациях мы действуем по похожему принципу: сначала быстрый аудит и снятие нагрузки, потом точечные исправления и рефакторинг.

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

• Первая — оперативно нарастить мощности. В облаке ресурсы серверов и баз данных можно увеличить за минуты. Но если причина в неоптимальных запросах или блокировках в базе, новые ресурсы лишь отсрочат проблему.
• Вторая — усилить кэширование. Каталог и карточки товаров можно отдавать из кэша, допуская задержку в обновлении цен на пару минут. Это заметно разгружает бэкенд.
• Третья — временно отключить второстепенное: рекомендации, сложные фильтры, поиск с подсказками. В пике пользователю нужно одно — добавить товар в корзину и оплатить.
• Четвёртая — отсечь нецелевой трафик. Заметную долю запросов создают боты и парсеры. Ограничение частоты запросов и правила WAF снижают их влияние. Если посетителей всё равно больше, чем сайт способен обслужить, помогает виртуальная «комната ожидания»: короткая очередь лучше недоступной страницы.

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

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

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

• В первую очередь нужно подключить CDN и кеширование, например, Cloudflare. Разворачивается за минуты, статика уходит на его серверы, исходный хостинг разгружается.
• Потом можно добавить ресурсов на сервере, если провайдер позволяет. У большинства облачных хостингов есть вертикальное масштабирование в один клик: CPU и память увеличиваются без переустановки.
• Третье — закрыть доступ всем ботам, кроме поисковых. В Cloudflare для этого есть Bot Fight Mode, в nginx — блокировки по user-agent. Google, Яндекс и Bing при этом продолжают индексировать.

Остальные меры так или иначе требуют предварительной подготовки.

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

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

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

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

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

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

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

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