Настройка и доработка WooCommerce: интеграция с 1C и СДЭК, кеширование, логирование, контроль остатков

Исходная ситуация: интернет-магазин на WordPress 6.x + WooCommerce 8.x работает на VPS (Ubuntu 22.04, Nginx, PHP 8.2, MariaDB). Каталог около 25 000 товаров и 60 000 вариаций. Сейчас обмен с 1C происходит через устаревший модуль, периодически дублируются товары, слетают цены и остатки, а в пиковые часы (распродажи) оформление заказа тормозит и иногда даёт 502. Доставка считается через плагин СДЭК, но часть заказов уходит без выбранного ПВЗ из-за гонок при пересчёте корзины. Нужен планомерный разбор и настройка, без смены CMS и без полной переделки темы.

Техническая среда и ограничения: нельзя останавливать продажи дольше чем на 10 минут за раз, все изменения через staging и Git, деплой через SSH. Нельзя подключать внешние SaaS-кеши типа Cloudflare APO, можно использовать Redis на VPS. Нельзя менять текущий платёжный модуль и URL-структуру. Допустимы точечные правки кода в виде небольшого MU-plugin или собственного плагина, без правки ядра WordPress и WooCommerce.

Что требуется сделать:
1) Провести аудит текущей конфигурации производительности и логики оформления заказа - профилирование медленных запросов (Query Monitor/New Relic или аналог), анализ PHP-FPM/Nginx логов, выявление узких мест в базе (индексы, медленные запросы WooCommerce lookup tables, wp_postmeta).
2) Настроить кеширование и стабильность - включить и корректно настроить Redis Object Cache, исключения для динамических страниц (корзина, оформление, личный кабинет), настроить page cache на Nginx или корректно конфигурировать существующий плагин кеша, чтобы не ломались цены, купоны и пересчёт доставки.
3) Привести в порядок обмен с 1C - стабилизировать импорт товаров, цен и остатков так, чтобы не создавались дубликаты и не терялись связи вариаций. Настроить маппинг по внешнему идентификатору (SKU/UUID), обработку удалённых товаров, контроль целостности после импорта. Добавить журнал импорта с понятными ошибками (в wp-content/uploads/logs или в таблицу), без вывода чувствительных данных.
4) Починить сценарий выбора ПВЗ СДЭК - устранить проблему, когда при пересчёте корзины выбранный ПВЗ сбрасывается или не попадает в заказ. Результат должен сохраняться в заказе как мета и отображаться в админке и письмах. Если текущий плагин не даёт нужных хуков - сделать обвязку через WooCommerce hooks, не ломая обновляемость плагина.
5) Настроить мониторинг и предохранители - включить ротацию логов, настроить алерты на 5xx (достаточно отправки на email), добавить health-check эндпоинт для проверки доступности ключевых компонентов (БД, Redis, wp-cron).

Конкретный результат:
- Оформление заказа стабильно проходит без 502 и без потери выбранного ПВЗ.
- Импорт из 1C перестаёт создавать дубликаты товаров и вариаций, остатки и цены после обмена совпадают с выгрузкой.
- Сайт выдерживает пиковую нагрузку без резких деградаций за счёт корректного кеширования.

Измеримые критерии приёмки:
- P95 времени ответа страницы оформления заказа - не более 2.5 сек при 20 одновременных пользователях на staging (k6 или аналог), без 5xx.
- После полного обмена с 1C количество товаров и вариаций не увеличивается за счёт дублей, 0 новых дублей по SKU/внешнему UUID.
- В 50 тестовых заказах подряд выбранный ПВЗ СДЭК всегда сохраняется и отображается в админке и в письме клиенту.
- Redis cache hit rate на типовых страницах каталога не ниже 70% (по метрикам плагина/redis info), при этом корзина и checkout не кешируются как страница.

Ожидаемые этапы: настройка staging и сбор диагностик - план работ и рисков - внедрение кеширования - исправление обмена 1C - исправление СДЭК - нагрузочное тестирование - финальный деплой и чек-лист.

Доступы и материалы: предоставлю SSH на staging и production, дамп БД для локального анализа по запросу, доступ в админку WP, примеры выгрузки 1C (XML) и несколько проблемных заказов для воспроизведения.