Налаштування та доопрацювання 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.
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) та кілька проблемних замовлень для відтворення.