Behebung kritischer Fehler im Checkout und bei Webhooks auf Magento 2 nach dem Upgrade – Stripe/PayPal – Redis/Varnish

Nach dem Magento 2.4.6-p3 (PHP 8.2)-Update kam es bei der Produktion des Online-Shops (B2C, ~15.000 SKUs, 800-1200 Bestellungen/Tag) zu Fehlern bei der Auftragserteilung und Desynchronisierung der Zahlungen. Einige Kunden erhalten im Zahlungsschritt eine Fehlermeldung oder die Bestellung wird ohne Transaktion erstellt, und manchmal wird sie dupliziert. Die Protokolle enthalten eine Mischung aus 500/502, Zeitüberschreitungen, MySQL-Deadlock-Meldungen und Ausnahmen im benutzerdefinierten ERP-Integrationsmodul. Außerdem ist mir aufgefallen, dass Stripe-Webhooks manchmal keine Bestätigung durchführen und die PayPal-IPN zweimal angezeigt wird. Damit der Checkout unter Last stabil läuft, ist es notwendig, die Ursachen zu lokalisieren und Fehler zu beheben.

Technische Umgebung: Magento Open Source 2.4.6-p3, Nginx, PHP-FPM 8.2, MySQL 8.0, Redis (Sitzungen+Cache), Varnish, Elasticsearch/OpenSearch, RabbitMQ. Bereitstellung über GitLab CI, es gibt Staging, Zugriff über SSH. Es gibt APM (New Relic) und zentralisierte Protokolle (ELK). Es gibt mehrere benutzerdefinierte Module: Integration mit ERP (REST), Promo-Logik, Checkout-Anpassung. Zahlungen: Stripe (PaymentIntents + Webhooks) und PayPal.

Erwartetes Ergebnis: Ursachen für Checkout-Fehler behoben, korrekte Verarbeitung von Webhooks/Benachrichtigungen, keine Duplizierung von Bestellungen/Transaktionen, stabiler Betrieb unter Last. Es sind eine Reihe von Code- und Konfigurationsänderungen sowie ein kurzer technischer Bericht darüber erforderlich, was fehlerhaft war und wie es getestet wurde.

Einschränkungen: Produktionsunterbrechungen sind verboten, nur ein kurzes Veröffentlichungsfenster von 10–15 Minuten ist zulässig. Änderungen müssen mit aktuellen benutzerdefinierten Modulen kompatibel sein. Sie können Varnish/Redis in der Produktion nicht deaktivieren, Sie können Punkteinstellungen vornehmen. Kundendaten können nicht außerhalb des Servers hochgeladen werden.

Arbeitsschritte:
1) Diagnose: Analyse von Protokollen (Magento/System/Ausnahme, Nginx, PHP-FPM), New Relic-Spuren, zugehöriger Cron/Warteschlange, Wiedergabe beim Staging mit aktiviertem Profiler, Suche nach Race Conditions in der Reihenfolge, Idempotenzprüfung für Stripe/PayPal.
2) Korrekturen: Änderungen im benutzerdefinierten Checkout-/ERP-Modul (Transaktion, Wiederholung, Blockierung/eindeutige Schlüssel), Korrektur der Webhook-Verarbeitung (Signatur, Wiederholungen, Reihenfolge der Ereignisse, Idempotenzschlüssel), Beseitigung von Deadlock-Ursachen (Indizes/Reihenfolge der Datensätze), Timeouts/FastCGI-Einstellungen, Optimierung bestimmter langsamer SQL/Consumer.
3) Validierung: Auslastungstests beim Staging (k6/JMeter) für 3DS-/Nicht-3DS-Checkout-Szenarien, Simulation wiederholter Webhooks, Überprüfung auf Nichtduplizierung, Regression von Aktionscodes/Versand/Steuern.
4) Release: MR-Vorbereitung, Bereitstellungsanweisungen, Rollback-Plan, Release-Support und 24-Stunden-Metriküberwachung.

Akzeptanzkriterien (gemessen):
- Beim Staging mit 50 virtuellen Nutzern hat der Checkout in einem 30-minütigen Test ohne 500/502 beim Bezahlschritt eine Erfolgsquote von mindestens 99 %.
- In der Produktion innerhalb von 24 Stunden nach der Veröffentlichung: Anteil der Bestellfehler <0,2 % (laut New Relic), es gibt keine doppelten Bestellungen mit derselben Zahlungsabsichts-ID/PayPal-TXN-ID.
- Stripe-Webhooks werden in 99,9 % der Fälle mit 2xx-Bestätigung verarbeitet, wiederholte Ereignisse führen nicht zur Erstellung neuer Rechnungen/Sendungen.
– Das Repository verfügt über einen MR mit einer Beschreibung der Änderungen und einen kurzen Bericht (1–2 Seiten) mit Grundursachen und Links zu Protokollen/Metriken.

Ich werde Zugang und Materialien bereitstellen: SSH zu Staging/Prod, Zugang zu GitLab, New Relic, Beispiele für problematische Bestell-/Zahlungs-IDs, Zeitfenster für Vorfälle.