Menu
Статистика неумолима: в день глобальной распродажи 11 ноября трафик на российских и мировых площадках вырастает в 10-50 раз, по сравнению с обычными днями. Метрика фиксирует аномальные пики посещаемости.
Оставим за скобками то, что всемирный день шопинга превратился в минное поле с завышенными ценами, но до сих пор массы людей с наступлением магической даты готовы тратить деньги. Что самое неприятное? Сбои случаются в самый неподходящий момент.
Если даже вы уверены, что у вас хороший запас прочности по сайту: вы ошибаетесь. Тот запас прочности - это стандартные посещения с выдачей страниц сайта из кэша.
Сейчас же нагрузка придётся на элементы, которые не готовы к наплыву, и которые невозможно закэшировать: страницы личного кабинета и корзина (все это нагружает базу данных, процессор, потребляет оперативную память).
Важен каждый компонент: и сеть, и веб-сервер, и база данных. Поэтому подготовка должна начинаться за 2-3 недели, а лучше за месяц.
Прежде чем что-то оптимизировать, надо понять, где узкое место. Я использую инструменты Apache JMeter (бесплатно) или Yandex.Tank. Провожу тест на стенде, который повторяет боевую инфраструктуру. Пропускаю через него нагрузку в 2-3 раза выше ожидаемого пика. Смотрю на четыре ключевых показателя: время отклика (должно оставаться в пределах нормы), процент ошибок (не больше 1-2%), использование CPU и памяти. Если сервер умирает при 500 запросов в секунду, а вы ожидаете 2000 - срочно нужно масштабироваться.
Не забудьте прогнать сценарии именно покупки: добавление в корзину, оформление заказа, переход на платёжную форму. Это самые тяжёлые SQL-запросы. Часто выясняется, что сервер держит каталог, но падает при попытке одновременно создать 1000 заказов. Рецепт: оптимизировать таблицы БД, добавить индексы, а возможно, перейти на очереди (RabbitMQ). Напишу об этом ниже.
Также тестируйте разные типы трафика: высокий RPS (запросов в секунду) на динамические страницы, большой объём данных (например, загрузка изображений), и смешанный.
Кэширование способно снизить нагрузку на бэкенд в 10-100 раз. Если страница каталога не меняется для каждого пользователя (нет персонализации), её нужно кэшировать хотя бы на несколько секунд. Настройте Nginx FastCGI cache или Varnish. Я предпочитаю Nginx proxy_cache для страниц и Redis для объектов (например, корзины). Для WordPress отлично работают плагины WP Rocket и LiteSpeed Cache - на тарифах с OpenLiteSpeed они дают микро-кэш на 1-5 секунд, что спасает при наплыве ботов.
А вот главную, категории, карточки товаров, статику - кэшируйте смело. Установите TTL (Time To Live) для статики на год (Cache-Control: max-age=31536000), а для динамических страниц на 60-300 секунд. Используйте CDN (Content Delivery Network) для раздачи картинок, CSS, JS - это снизит нагрузку на ваш сервер.
Важный момент: кэширование не должно мешать актуальности. Для товаров с ограниченным остатком используйте ESI (Edge Side Includes) или инвалидацию кэша по событию (например, при изменении остатка). У некоторых CMS есть плагины для умного сброса кэша. Протестируйте, чтобы кэш не выдавал старые цены в разгар распродажи - это подорвёт доверие.
Если нагрузочные тесты показали, что одного сервера мало, нужно горизонтальное масштабирование. Самый быстрый способ для VPS - перейти на облачную платформу с автобалансировкой (Selectel, VK Cloud, Yandex Cloud). Настройте группу из нескольких серверов за балансировщиком. Используйте сессии Redis, чтобы пользователь не вылетал при смене сервера. Базу данных вынесите на отдельный выделенный сервер или используйте управляемую БД (Managed Database) - они масштабируются быстрее.
Перед черной пятницей обязательно протестируйте автоматическое добавление новых серверов под нагрузкой (auto-scaling). Проследите, чтобы сервер приложений был stateless (не хранил сессии на диске, файлы загрузок не сохранял локально). Иначе масштабирование не сработает. Все загруженные пользователем файлы отправляйте в S3-совместимое хранилище (Selectel, VK Cloud Object Storage).
Для проектов на Битриксе или 1С часто помогает простое вертикальное масштабирование: взять VPS помощнее на время распродажи. Многие хостинги позволяют увеличить RAM и CPU на пару дней. Это дёшево и быстро. Главное - выбрать тариф с возможностью апгрейда без перезагрузки (или с коротким даунтаймом).
В день распродажи база данных - это сердце. Если она падает, сайт встаёт. Я видел, как на 11.11 MySQL умирал из-за блокировок таблиц и слишком большого количества одновременных запросов. Что делаю:
Не забывайте про настройки буферов: innodb_buffer_pool_size должен быть 70-80% от доступной RAM (если БД на отдельном сервере). Проверьте max_connections - не ставьте слишком высоко, иначе БД захлебнётся в соединениях. Увеличивайте постепенно, тестируя нагрузку.
В момент пика, когда повышенное число пользователей нажимают "Оформить заказ", сервер может не справиться с синхронной обработкой. Решение - очереди. Вместо того чтобы обрабатывать заказ мгновенно (что может занять несколько секунд), вы ставите его в очередь (RabbitMQ, Redis Lists, Amazon SQS), а воркеры (фоновые процессы) забирают оттуда заказы и обрабатывают их. Пользователь получает мгновенный ответ "Заказ принят, обрабатывается", а сайт не зависает.
Для WordPress есть плагины (WooCommerce Queue, Action Scheduler) - они могут откладывать тяжёлые операции. Для Битрикса - агентирование. Но лучше всего настроить собственный скрипт-воркер на отдельном сервере. Важно: протестировать, чтобы очередь не росла бесконечно, и воркеры успевали обрабатывать заказы быстрее, чем поступают.
Настройте мониторинг размера очереди и оповещения, если она начинает переполняться. Тогда вы успеете добавить ещё воркеров до того, как покупатели начнут жаловаться.
К сожалению, в день 11.11 нередки DDoS-атаки от конкурентов или вымогателей. Обычный VPS без защиты рухнет мгновенно. Что делать? Если вы на облачной платформе (Selectel, VK Cloud, Yandex Cloud), включите их встроенный анти-DDoS. Если нет - рассмотрите подключение облачного scrubbing service (Cloudflare, StormWall, DDoS-Guard). За 2-3 недели до распродажи протестируйте, как защита ведёт себя под тестовой атакой. Убедитесь, что легитимный трафик не блокируется.
Перед 11.11 настройте ограничения (rate limiting) на веб-сервере для критических страниц: логин, оформление заказа, поиск. Например, не более 10 запросов в минуту на оформление с одного IP. Это не остановит мощный DDoS, но защитит от брутфорса и спама. Используйте модули Nginx (limit_req, limit_conn).
Имейте запасной план: если основной сервер ляжет, быстро переключить DNS на запасной VPS у другого провайдера. Это требует подготовки, но однажды спасло мой магазин.
В день 11.11 вы не можете сидеть и обновлять страницу вручную. Нужны автоматические системы мониторинга. Настройте Zabbix, Prometheus+Grafana или хотя бы онлайн-сервисы вроде UptimeRobot. Контролируйте загрузку CPU, RAM, сетевой трафик, количество свободных inode, размер очереди. Установите пороги: если CPU больше 80% в течение 5 минут - SMS или сообщение в Telegram. Если количество ошибок 5xx превышает 5% от всех запросов - срочно смотрите логи.
Отдельно мониторьте базу данных: число активных соединений, медленные запросы. Можно использовать Percona Monitoring and Management (PMM) - бесплатно и наглядно. Настройте алерты на превышение количества медленных запросов (больше 10 в минуту) - это сигнал, что пора оптимизировать.
Не забывайте про логи веб-сервера (access.log, error.log). Сделайте скрипт, который в реальном времени показывает топ IP по числу запросов, топ URL. Если видите аномалию (один IP долбит главную), баньте его через fail2ban. Автоматизируйте, чтобы не сидеть вручную.
Что бы ни случилось, вы должны иметь возможность восстановить сайт за 10-15 минут. За 2 дня до 11.11 сделайте полный бэкап: файлы, база данных, конфиги. Сохраните копии и на отдельный бэкап хостинг, и на свой компьютер.
Протестируйте процесс восстановления на тестовом сервере - убедитесь, что всё работает. Потренируйтесь переключать DNS на резервный сервер в случае выхода основного из строя. Заранее подготовьте скрипты или инструкцию - в панике легко забыть шаги.
Если вы используете managed базу данных, включите автоматические бэкапы каждые 15 минут - так вы потеряете не более 15 минут данных. Для файлов загрузок - настройте репликацию в облако. И зарубите себе на носу: бэкап должен быть не на том же сервере, что и исходные данные.
За две недели до 11.11 заморозьте обновления. Новые версии плагинов и ядра могут принести баги. Лучше обновиться за месяц, а последние дни провести в режиме стабилизации. Если всё же нужно обновить критический патч безопасности - сделайте это, но только после тщательного тестирования на копии сайта.
Отключите все неиспользуемые плагины. Каждый плагин - это лишний код и потенциальный тормоз. Проверьте, какие плагины выполняют фоновые задания (cron). Отключите ненужные на время распродажи. Например, плагин синхронизации с 1С можно временно деактивировать. То же с аналитическими системами, которые не влияют на оформление заказов.
Для WordPress рекомендую плагин Query Monitor - он показывает медленные запросы. Включите его на тестовом стенде, пройдите все сценарии покупателя, найдите слабые места. Но на боевом сайте отключите, потому что сам плагин потребляет немалые ресурсы.
Техническая подготовка - лишь половина дела. В день 11.11 обязательно должна быть дежурная команда: разработчик (на связи), администратор сервера, техподдержка (для ответов клиентам). Распределите роли, подготовьте инструкции по действиям при авариях. Прорепетируйте сценарии: "что делать, если база данных легла?", "если началась DDoS-атака?", "если хостинг не отвечает?". Важно, чтобы каждый знал свои шаги и не паниковал.
Настройте быстрые каналы связи: отдельный чат в том же Telegram или MAX. И обязательно выспитесь перед ночью 11 ноября - она будет долгой.
Подготовка к 11.11 - это не про "запустить и забыть". Это про системный подход, тестирование, резервирование и контроль. Начните с нагрузочных тестов, переходите к кэшированию и масштабированию, не забывайте про безопасность и бэкапы. И главное - тестируйте, тестируйте, тестируйте. Только прогоняя сценарии на стенде (стенд - это тестовый сервер, если кто под конец статьи так и не понял), вы найдёте узкие места. Не пренебрегайте планом Б - резервным хостингом, запасными IP, инструкциями для команды.
Cloudflare окончательно заблокирован в РФ ещё летом 2025 года.
Функцию фильтрации ботов Cloudflare взял на себя российский антибот Killbot.
Принцип работы отличается от привычного, отслеживаются не знакомые всем при настройке других антибот решений параметры (входящие IP адреса, AS подсети ботов, User Agent и прочее, всё это легко подделывается), а уникальные для каждого набора браузеров слепки.
По отличию оригинального браузера от модифицированного, тот или иной заход определяется либо как заход реального посетителя, либо как заход бота.
Чтобы не повторяться - расписывал более подробно в статьях:
Попробовать бесплатно. При регистрации в Killbot введите промокод
promo13
и получите месяц тестирования платного тарифа Killbot (фильтрация трафика, 1000 руб) и Ads (отключение показа рекламы поведенческим ботам, 1000 руб) в качестве бонуса. Этого вам хватит на то, чтобы понять, подходит вам данное решение, или нет. На данный момент - в Рунете нет более достойной альтернативы, по соотношению цена-качество. Срок действия промокода ограничен по времени, куда-то записывать его нет смысла. В следующий раз промокод уже будет другой, поэтому использовать его нужно сейчас, когда вы читаете этот текст. Промокод действует только в форме регистрации. Если аккаунт уже создан - создайте новый, на другой почте, и при регистрации в последнем поле введите промокод.
Подпишитесь на Telegram канал / MAX для того, чтобы всегда быть в курсе последних новостей и обновленных настроек для защиты от ботов, а также оперативно получать новые материалы, выходящие на antibot24.ru
Автор статей: Сергей (AntiBot24). Эксперт в области фильтрации поведенческого трафика, настройки антибот систем. Высший рейтинг на Kwork, более 680 отзывов, 100% заказов успешно сдано, 56% повторных заказов. Пишу подробные статьи, инструкции по фильтрации ботов в своем блоге antibot24.ru
Всегда нужно иметь в виду, что те советы, которые вы прочли в статьях - это лишь часть настроек, которые я делаю при профессиональной экспертной настройке фильтрации поведенческих ботов. Все остальное - это непубличные профессиональные секреты. Любая информация, становящаяся общедоступной - достаточно быстро устаревает и перестает быть эффективной.
Если вы столкнулись с повышенной роботностью в Яндекс метрике, увеличением числа прямых заходов, увеличением количества отказов - вы всегда можете заказать у меня настройку Killbot.