Язык
Перед акцией магазин может выглядеть вполне здоровым: главная страница открывается, товары попадают в корзину, мониторинг показывает норму. Решающий момент наступает позже, когда покупатель оформляет заказ и ждет ответа платежной системы. Этому пути нужна отдельная репетиция.
Представим условный магазин, который ожидает больше заказов за один вечер. Вопрос о допустимом числе посетителей полезен, но недостаточен. Важно понять, сколько покупок завершается, где прерывается путь и кто реагирует на неопределенный статус заказа. Это учебный сценарий, а не история клиента SERVER1.
Проверяйте магазин в точке завершения заказа
Составьте список действий: гость открывает товар, выбирает вариант, применяет купон, меняет количество, переходит к оплате и получает подтверждение. Вернувшегося пользователя проверяйте отдельно: сохраненные адреса, персональные условия и сессии могут изменить поведение магазина.
Для каждого сценария определите проверяемый результат. Экран успешного завершения сам по себе не подтверждает согласованность платежа, остатков и письма. Проверьте повторное нажатие и прерванный ответ: при расследовании важно отличить уже созданный заказ от незавершенной операции.
Меняйте не только тестовую учетную запись, но и устройство. Сценарий на офисном компьютере не заменяет проверку через мобильную сеть. Пройдите ввод адреса, выбор доставки и возврат после ошибки. Настройка хостинга сама по себе не вернет покупателя, которому приходится вводить все заново.
Быстрый каталог полезен. Правильно завершенный заказ дает более убедительное свидетельство готовности.
У кеша должна быть понятная граница
Cart, Checkout и My Account содержат данные конкретного покупателя. Сверьте исключения page cache и CDN с реальной конфигурацией. Отключение кеша на всем сайте не является универсальным решением: публичному каталогу и персонализированным ответам нужны разные правила.
Убедитесь, что корзина одного пользователя не появляется у другого. Проверьте вход, выход, пустую корзину, купон и варианты товара. Изменение правил сначала проверяйте на staging, затем переносите обычным контролируемым релизом.
Итог репетиции - решение о готовности
Подготовьте копию сайта и убедитесь, что платежный модуль работает в sandbox. Проверьте также почту, склад, доставку и CRM: внешняя система может принять тестовый заказ за настоящий. Реальные персональные данные используйте только при необходимой авторизации; по возможности заменяйте их тестовыми.
Ограничьте доступ к staging авторизацией и исключите его из публичного поиска. Один robots.txt защитой доступа не является. Перед началом ответственный должен проверить адрес среды, платежный режим и получателей исходящих уведомлений. Название staging не доказывает, что все интеграции изолированы.
Сначала сохраните исходные показатели при обычной нагрузке. Повышенную конкуренцию запросов проверяйте только на разрешенном staging, с согласованным пределом и условием остановки. Самостоятельный нагрузочный тест на shared-хостинге или сервере с другими клиентами проводить нельзя.
В конце сопоставьте ответ для покупателя, статус заказа в магазине и результат sandbox платежного провайдера. Это разные сигналы. Страница успеха еще не доказывает правильность внутренних статусов. Ошибка платежа тоже должна оставлять ясный результат, а не неопределенный заказ, который покупатель может случайно повторить.
Запишите короткое решение: что проверили, в каком объеме, что осталось неизвестным и при каком условии акцию остановят. Повторяющиеся неопределенные ответы платежной системы могут быть важнее небольшого замедления каталога. Допустимые границы следует согласовать с бизнесом и техническим ответственным заранее.
Вечер акции не подходит для нового эксперимента
Условный магазин ожидает 600 посещений за час. При равномерном распределении это десять посещений в минуту, но число одновременных пользователей из этого не следует. Важны длительность сессии и количество действий. Несколько активных checkout создают иную нагрузку, чем множество кешированных просмотров.
Если каталог работает быстро, а оплата замедляется, сначала изучите обращения плагинов, запросы к базе и ответы платежного провайдера. Добавление RAM не устраняет задержку внешнего сервиса. VPS оценивайте, когда измерения выявляют конкретную потребность в ресурсах, изоляции или управлении.
Определите период без изменений и человека, который принимает решения во время акции. Проверьте дату и состав резервной копии, затем безопасно испытайте восстановление. Полный откат базы способен удалить реальные заказы после момента backup, поэтому сохранению новых данных нужен отдельный план.
После репетиции расположите проблемы по пути покупателя. Сначала устраните препятствия покупке, затем улучшайте удобство каталога. Небольшое число одновременных изменений также упрощает интерпретацию результата. Если меняли несколько вещей сразу, осторожнее связывайте итог с одной из них.
При выборе WordPress-хостинга приложите этот сценарий к запросу. Потребность в Managed VPS обосновывайте нагрузкой и требованиями к управлению. Приближение акции само по себе не доказывает необходимость увеличивать сервер.
О выборе самого окружения: WordPress и WooCommerce Hosting: что должна включать специализированная среда.
Детали тестирования и исключений кеша: WooCommerce - Testing orders; WooCommerce - Caching configuration.
