Устранение критических ошибок в checkout и вебхуках на Magento 2 после обновления - Stripe/PayPal - Redis/Varnish

После обновления Magento 2.4.6-p3 (PHP 8.2) на продакшене интернет-магазина (B2C, ~15 тыс. SKU, 800-1200 заказов/день) появились сбои в оформлении заказа и рассинхронности оплаты. Часть клиентов получает ошибку на шаге оплаты или заказ создается без транзакции, а иногда – дублируется. В логах есть смесь 500/502, timeouts, сообщения о deadlock в MySQL и исключения в custom модуле интеграции с ERP. Параллельно подмечено, что Stripe webhooks иногда не подтверждаются, а PayPal IPN приходит дважды. Следует локализовать первопричины и исправить ошибки так, чтобы checkout стабильно проходил под нагрузкой.

Техническая среда: Magento Open Source 2.4.6-p3, Nginx, PHP-FPM 8.2, MySQL 8.0, Redis (sessions+cache), Varnish, Elasticsearch/OpenSearch, RabbitMQ. Деплой через GitLab CI является staging, доступ по SSH. Имеются APM (New Relic) и централизованные логи (ELK). Есть несколько кастомных модулей: интеграция с ERP (REST), промологика, кастомизация checkout. Платежи: Stripe (PaymentIntents+webhooks) и PayPal.

Ожидаемый результат: исправлены причины ошибок checkout, корректная обработка вебхуков/нотификаций, отсутствие дублирования заказов/транзакций, стабильная работа под нагрузкой. Требуется набор изменений в коде и конфигах, плюс краткий технический отчет, который был сломан и как проверено.

Ограничение: остановка продакшена запрещена, разрешено только короткое окно на релиз 10-15 мин. Изменения должны быть совместимы с текущими кастомными модулями. Нельзя выключать Varnish/Redis на продакшене, можно производить точечные настройки. Данные клиентов нельзя выгружать за пределы сервера.

Этапы работ:
1) Диагностика: анализ логов (Magento/system/exception, Nginx, PHP-FPM), New Relic traces, связанных cron/queue, воспроизведение на staging с включенным profiler, поиск race conditions в place order, проверка idempotency для Stripe/PayPal.
2) Исправление: правки в кастомном checkout/ERP модуле (транзакционность, ретраи, блокировка/уникальные ключи), коррекция обработки webhooks (подпись, повторы, порядок событий, idempotency key), устранение deadlock причин (индексы/порядок записей), настройка timeout SQL/consumer.
3) Проверка: погрузочное тестирование на staging (k6/JMeter) для сценариев checkout 3DS/non-3DS, симуляция повторных webhook, проверка отсутствия дублирования, регрессия промокодов/доставки/налогов.
4) Релиз: подготовка MR, инструкция деплоя, план отката, сопровождение релиза и мониторинг 24 часа по метрикам.

Критерии приемки (измеряемые):
- На staging при 50 виртуальных пользователях checkout имеет успеваемость не ниже 99% за 30 мин теста без 500/502 на шаге оплаты.
- На продакшене в течение 24 ч после релиза: доля ошибок place order <0.2% (по New Relic), отсутствуют дубликаты заказов с одинаковым payment_intent_id/PayPal txn_id.
Webhooks Stripe обрабатываются с подтверждением 2xx в 99.9% случаев, повторные события не создают новых инвойсов/шипментов.
- В репозитории есть MR с описанием изменений и краткий отчет (1-2 страницы) с первопричинами и ссылками на логи/метрики.

Доступы и материалы предоставим: SSH к staging/prod, доступ к GitLab, New Relic, примеры проблемных order/payment IDs, временные окна инцидентов.