Как подготовить WooCommerce к большой распродаже: чек-лист

Это чек-лист для инженеров, которые обслуживают магазины на WooCommerce перед событием с высоким трафиком: Black Friday, запуском продукта, крупной акцией. Работа делится на три фазы, за две недели, последние дни и сама распродажа, и каждый шаг здесь достаточно конкретен, чтобы выполнить его из терминала.

За две недели: обновите всё, но только на staging

Хуже всего обнаружить конфликт плагинов на пике трафика. Склонируйте продакшен в staging-копию, выполните там все обновления и только потом перенесите те же версии на продакшен. После этого заморозьте версии: никаких изменений до конца распродажи.

# на staging-копии
wp core update
wp core update-db
wp plugin update --all
wp theme update --all
wp wc update

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

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

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

# в тестовой среде
wp db import nightly_dump.sql
wp db check
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='shop_order';"

Если включено хранилище заказов High-Performance Order Storage (HPOS), считайте по таблице wp_wc_orders. Число должно совпадать с продакшеном. Запланируйте ещё один снапшот за час до старта распродажи, чтобы точка отката была свежей на минуты, а не на сутки.

Нагрузочно тестируйте оформление заказа, а не главную страницу

Закешированная главная выдержит почти всё, поэтому эта цифра ничего не доказывает. Корзина и оформление заказа обходят кеш страниц и на каждый запрос обращаются к PHP и базе данных. Опишите в скрипте реальный поток: добавление в корзину, открытие корзины, загрузка страницы оформления, и запустите его против staging инструментом вроде k6:

k6 run --vus 50 --duration 5m checkout-flow.js

Пока тест идёт, смотрите на сервер, а не на вывод теста:

mysqladmin extended-status | grep -E "Threads_(connected|running)"
tail -f /var/log/mysql/slow.log
grep max_children /var/log/php8.2-fpm.log

Найдите точку, где время ответа начинает расти, и добейтесь запаса в 2-3 раза от ожидаемого пика. Обычные меры в порядке отдачи: поднимите pm.max_children насколько позволяет RAM, включите постоянный объектный кеш и проиндексируйте или перепишите то, что раз за разом показывает лог медленных запросов.

Последние дни: изображения, плагины, правила кеша

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

cwebp -q 82 banner.png -o banner.webp

Затем уберите вес, который во время распродажи не нужен:

• Отключите на эту неделю тепловые карты, запись сессий и второстепенные маркетинговые пиксели. Каждый из них добавляет вес на фронтенде и лишние запросы admin-ajax или REST. Оставьте один лёгкий инструмент аналитики.
• Убедитесь, что кеш страниц исключает корзину, оформление заказа и личный кабинет и отключается, как только появляется сессионная cookie WooCommerce.

# пример для nginx fastcgi-cache
if ($request_uri ~* "/(cart|checkout|my-account)") { set $skip_cache 1; }
if ($http_cookie ~* "woocommerce_items_in_cart|wp_woocommerce_session") { set $skip_cache 1; }

Проверьте снаружи: curl -I https://shop.example/checkout/ должен показывать заголовок BYPASS или MISS на каждом запросе. Закешированная страница оформления заказа перемешивает корзины покупателей и ломает nonce, а это намного хуже, чем медленная страница.

Основы настройки сессий и базы данных

Первое: cron. WooCommerce чистит таблицу wp_woocommerce_sessions и выполняет запланированные действия через WP-Cron, который срабатывает от просмотров страниц и плохо ведёт себя под нагрузкой. Отключите его директивой define('DISABLE_WP_CRON', true); в wp-config.php и запускайте из системного cron:

*/5 * * * * wp --path=/var/www/shop cron event run --due-now

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

wp transient delete --expired
wp db query "SELECT SUM(LENGTH(option_value))/1024/1024 AS autoload_mb FROM wp_options WHERE autoload='yes';"

Третье: сам MySQL. Задайте innodb_buffer_pool_size так, чтобы рабочий набор данных помещался в память, согласуйте max_connections с числом воркеров PHP-FPM и оставьте лог медленных запросов включённым на всю распродажу, чтобы видеть, где болит.

Во время распродажи: наблюдайте, ничего не выкатывайте

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

Следите за четырьмя числами: активные процессы PHP-FPM против pm.max_children, MySQL Threads_running, свободное место на диске, потому что логи и сессии растут быстро, и заказы в минуту. Резкое падение темпа заказов при нормальном трафике обычно означает сломанное оформление заказа, и оповещение должно прийти из мониторинга раньше, чем клиент напишет письмо. Если ошибки на оформлении заказа резко растут и быстро найти причину не удаётся, восстановите проверенный снапшот: именно для этого он и существует.

Чек-лист

1. Склонируйте продакшен на staging за 14 дней.
2. Обновите на staging ядро, плагины, темы и базу WooCommerce, затем проверьте полный цикл покупки.
3. Перенесите те же версии на продакшен и заморозьте все обновления.
4. Восстановите свежий бэкап в отдельной среде и сверьте количество заказов.
5. Нагрузочно тестируйте сценарий оформления заказа, пока не получите запас в 2-3 раза от ожидаемого пика.
6. Уменьшите и сожмите изображения, отдавайте WebP.
7. Отключите тепловые карты, запись сессий и второстепенные маркетинговые пиксели.
8. Проверьте через curl исключения кеша для корзины, оформления заказа и личного кабинета.
9. Убедитесь, что работает постоянный объектный кеш.
10. Удалите истёкшие транзиенты и проверьте объём autoload-данных.
11. Перенесите WP-Cron в системный cron.
12. Проверьте innodb_buffer_pool_size, max_connections и лог медленных запросов.
13. Сделайте свежий снапшот за час до старта распродажи.
14. Во время распродажи: следите за FPM, MySQL, диском и темпом заказов, ничего не выкатывайте.

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