Teilweiser Ausfall: Händlerimporte und -exporte
- identified
Wir stehen vor einem teilweisen Ausfall in unserem Merchant Imports & Exports Service und arbeiten daran, ihn so schnell wie möglich zu beheben.
- resolved
Dieser Vorfall wurde behoben.
- postmortem
# Vorfall Post-mortem-Bericht **Dashboard-Exporte und -Importe verzögert sich für alle Stores ** | | | | | --- | --- | **Datum | 25. Oktober 2026, 11:25 Uhr bis 14:26 Uhr \(UTC\+3, KSA-Zeit\). Dauer: 3 Stunden 1 Minute | | **Typ des Vorfalls** | Service-Degradation: Hintergrundverarbeitung | | **Titel** | Ein sehr großer Kundenimport blockiert Dashboard exportiert und importiert für alle Stores | 132 Exportanfragen aus 66 Stores verzögerten sich durchschnittlich um 81 Minuten und bis zu 3 Stunden 43 Minuten. 3 von ihnen timed out und müssen erneut angefordert werden. Die Kundenimporte des Shops, der den großen Import begann, verzögerten sich bis 15:12 Uhr. | | **Gesamtauswirkungen auf die Betriebszeit** | Kein Ausfall. Geschäfte, Checkout und das Dashboard funktionierten die ganze Zeit. Nur Exporte und Importe warteten. | ## Zusammenfassung Dashboard-Exporte (Bestellungen, Kunden, Brieftasche, aufgegebene Warenkörbe und andere) und Dashboard-Importe werden im Hintergrund von einem gemeinsamen Pool von Mitarbeitern erstellt. Um 11:23 Uhr startete ein Händler einen Kundenimport mit rund 1,05 Millionen Zeilen. Die Plattform teilt jeden Import in Teile von 100 Zeilen, so dass diese 10.486 Teile wurden. Nach jedem Teil prüft die Plattform, ob der gesamte Import beendet ist, sodass sie dem Händler eine Zusammenfassung senden kann. Dieser Scheck lud jeden Teil des Imports, einschließlich der Zeilen, in den Speicher: etwa 200 MB pro Scheck für diesen Import, wobei bis zu fünf Schecks gleichzeitig ausgeführt wurden. Den Arbeitern ging das Gedächtnis aus und sie starteten immer wieder neu. Exportanfragen aus jedem Store warteten hinter den Importteilen. Wir haben eine Änderung auf Codeebene versandt, so dass der Scheck nur fragt, ob ein Teil noch aussteht und die endgültigen Gesamtwerte in der Datenbank addiert. Es lädt die Zeilen nicht mehr, so dass seine Speichernutzung nicht mehr mit der Größe des Imports wächst. ## Timeline \(KSA-Zeit\) Uhrzeit | Veranstaltung | | --- | --- | 11:23 Uhr | Ein Händler startet einen Kundenimport von etwa 1,05 Millionen Zeilen. Um 11:27 Uhr wird es in 10.486 Teile aufgeteilt. | 11:25 Uhr Die erste Exportanforderung, die warten muss, wird erstellt. Später fordert Schlange hinter den Importteilen. | 11:34 Uhr Den Arbeitern geht das Gedächtnis aus und sie starten neu. Von hier aus beenden sie etwa 5 Importteile pro Neustart und fast keine Exporte. | | 12:26 Uhr | Ein Händler berichtet, dass 3 Exporte, die seit 11:30 Uhr angefordert wurden, noch verarbeitet werden. | | ~1:15 Uhr | Product Engineering startet die Untersuchung und verfolgt die Neustarts bis zum Importabschluss. | | 1:54 Uhr | Product Engineering bereitet den Wandel vor, mit einem Test, der das Gedächtniswachstum reproduziert. | | 14:08 Uhr | Die Arbeiter fangen an, den Rückstand zu räumen, obwohl sie immer noch von Zeit zu Zeit neu starten. | | 14:26 Uhr | Der letzte verzögerte Export endet. Die Exporte sind wieder normal. | 2:34 Uhr | Die Veränderung ist live. | | ~3:00 Uhr | Der Arbeiter startet wieder an. | | 15:09 Uhr | 3 Exportanfragen, die mehr als 3 Stunden gewartet haben, werden als zeitversetzt markiert. | | 3:10 Uhr | Der große Import endet, mit Ausnahme eines Teils von 100 Zeilen, die die Plattform automatisch abruft. | ## Was betroffen war | Area | State während des Vorfalls | Wie wir es wissen | | --- | --- | Dashboard-Exporte, alle Typen und alle Stores | **Verzögert:** 132 Anfragen aus 66 Stores, durchschnittlich 81 Minuten, bis zu 3 Stunden 43 Minuten | Export Request Records. Bestellungen 72, detaillierte Bestellungen 21, Brieftasche 11, aufgegebene Warenkörbe 6, Kunden 6, Bewertungen 5, Auftragsvorbereitung 4, Coupons 3, andere 4. | | Exporte, die ausgefallen sind | **Failed:** 3 Anfragen aus 2 Stores | Export Request Records. Diese Händler müssen den Export erneut beantragen. | | Exporte noch verarbeiten | **1 Request** | Export Request Records. Die Plattform versucht es automatisch. | | Kundenimporte des Shops, der den großen Import gestartet hat | **Verzögert bis 15:12 Uhr:** 9 Importe | Importdatensätze. Alle Teile fertig bis auf einen, der automatisch wiederholt wird. | | Importe aus anderen Geschäften | **Nicht betroffen ** | Kein anderer Store hat während des Vorfalls einen Import gestartet. | Dateiinhalte exportieren | **Nicht betroffen ** | Jede Datei wird aus Live-Daten erstellt, wenn sie ausgeführt wird, so dass verzögerte Dateien vollständig sind | | Stores, Checkout und Dashboard | **Nicht betroffen** | Nur die Hintergrundarbeiter für Exporte und Importe neu gestartet | ## Maßnahmen ergriffen 1. Die Ursache gefunden: Die Arbeiter, die Exporte und Importe bauen, wurden neu gestartet, weil die Importabschlussprüfung aus dem Speicher lief. 2. Versendet eine Änderung auf Codeebene: Die Abschlussprüfung zählt ausstehende Teile und addiert die Summen in der Datenbank, anstatt jedes Teil zu laden. Ein Test scheitert am alten Verhalten und gibt das neue weiter. 3. Bestätigt, dass die verspäteten Exporte abgeschlossen sind, und die 3 zeitversetzten Anträge identifiziert, so dass die Unterstützung diese Händler bitten kann, sie erneut anzufordern. ## Schlussfolgerungen ** Der Import eines Händlers sollte nicht die Exporte jedes anderen Shops aufhalten. ** Exporte und Importe teilen sich die gleichen Arbeiter, so dass ein starker Import alle verzögert. Die Änderung beseitigt diese Ursache. **Arbeiten, die einmal pro Teil ausgeführt werden, dürfen nicht mit der Größe des gesamten Imports wachsen.** Der Abschluss-Check liest den gesamten Import nach jedem Teil. Das war für typische Importe in Ordnung und scheiterte nur für einen sehr großen. Mit der Änderung erschöpft ein Import dieser Größe das Gedächtnis der Arbeiter nicht mehr.
Automatisch aus der offiziellen Störungsmeldung übersetzt.