Sortie partielle: Importations et exportations de marchandises
- identified
Nous sommes confrontés et avons identifié une panne partielle dans notre service d'importations et d'exportations commerciales et nous travaillons à la résoudre dès que possible.
- resolved
Cet incident a été résolu.
- postmortem
Rapport post mortem ** Exportations et importations de tableaux de bord retardées pour tous les magasins** - Oui. - Oui. **Date*** 25 octobre 2026, 11 h 25 jusqu'à 14 h 26 \(UTC\+3, heure de l'ASK\). Durée: 3 heures 1 minute **Type d'incident** Un très grand client importe des exportations et des importations de tableaux de bord bloqués pour tous les magasins **Impact**. 132 demandes d'exportation de 66 magasins ont été retardées, de 81 minutes en moyenne et jusqu'à 3 heures 43 minutes. 3 d'entre eux sont sortis à temps et doivent être demandés à nouveau. Les importations du client du magasin qui a commencé l'importation importante ont été retardées jusqu'à 15h12. **Impact total sur les temps d'arrêt** Les magasins, la caisse et le tableau de bord ont fonctionné tout le temps. Seules les exportations et les importations ont attendu. Autres Résumé Les exportations de tableaux de bord \(commandes, clients, portefeuille, chariots abandonnés et autres\) et les importations de tableaux de bord sont construites en arrière-plan par un groupe de travailleurs. À 11h23, un marchand a commencé à importer un client avec environ 1,05 million de lignes. La plate-forme divise chaque importation en parties de 100 lignes, donc celle-ci est devenue 10 486 parties. Après chaque partie, la plate-forme vérifie si toute l'importation a fini, de sorte qu'elle peut envoyer au marchand un résumé. Cette vérification a chargé chaque partie de l'importation, lignes incluses, en mémoire : environ 200 Mo par vérification pour cette importation, avec jusqu'à cinq vérifications en même temps. Les ouvriers manquaient de mémoire et redémarraient encore et encore. Demandes d'exportation de chaque magasin a attendu derrière les pièces d'importation. Nous avons envoyé un changement de niveau de code afin que la vérification demande seulement si une partie est encore en attente et additionne les totaux finals dans la base de données. Il ne charge plus les lignes, de sorte que son utilisation de la mémoire ne croît plus avec la taille de l'importation. ## Chronologie \(KSA time\) Heure Événement - Oui. Un marchand commence une importation de clients d'environ 1,05 million de lignes. Par 11:27 AM il est divisé en 10.486 parties. 11 h 25 La première demande d'exportation qui doit attendre est créée. Requêtes plus tard file d'attente derrière les pièces d'importation. - C'est pas vrai. Les travailleurs commencent à manquer de mémoire et à redémarrer. De là, ils terminent environ 5 pièces d'importation par redémarrage et presque aucune exportation. Autres Un marchand signale qu'il soutient que 3 exportations demandées depuis 11h30 sont encore en cours de traitement. ~1:15 PM=L'ingénierie du produit commence l'enquête et trace les redémarrages à la vérification d'achèvement de l'importation. L'ingénierie produit prépare le changement, avec un test qui reproduit la croissance de la mémoire. 2:08 Les travailleurs commencent à résorber l'arriéré, bien qu'ils continuent de redémarrer de temps en temps. Autres 2:26 La dernière exportation retardée se termine. Les exportations sont de retour à la normale. Le changement est en direct. ~3:00 Le travailleur redémarre s'arrête. 3:09 PM:3 Les demandes d'exportation qui avaient attendu plus de 3 heures sont indiquées dans le temps. La grande importation se termine, sauf une partie de 100 lignes que la plate-forme récupère automatiquement. Autres Ce qui a été affecté Secteur Etat pendant l'incident Comment nous savons - Oui. Tableau de bord exportations, tous types et tous les magasins **Reporté:** 132 demandes de 66 magasins, 81 minutes en moyenne, jusqu'à 3 heures 43 minutes. Commandes 72, commandes détaillées 21, portefeuille 11, paniers abandonnés 6, clients 6, avis 5, préparation de commande 4, coupons 3, autres 4. Exportations qui ont pris fin **Échec :** 3 demandes de 2 magasins. Ces marchands doivent demander à nouveau l'exportation. Autres Exports encore en cours de traitement. La plate-forme le récupère automatiquement. Les importations des clients de la boutique qui a commencé la grande importation. Toutes les pièces finies sauf une, qui est retriée automatiquement. Autres Importations en provenance d'autres magasins Aucun autre Store n'a commencé à importer pendant l'incident. Exporter le contenu du fichier. **Non affecté. Magasins, caisse et tableau de bord Seuls les travailleurs de base pour les exportations et les importations ont repris. Mesures prises 1. Trouvé la cause: les travailleurs qui construisent des exportations et des importations étaient en train de redémarrer parce que le contrôle d'achèvement des importations manquait de mémoire. 2. Livraison d'un changement de niveau de code: la vérification d'achèvement compte les pièces en attente et additionne les totaux dans la base de données au lieu de charger chaque pièce. Un test échoue sur l'ancien comportement et passe sur le nouveau. 3. Confirmé que les exportations retardées se sont terminées et a identifié les trois demandes de retrait à temps afin que l ' appui puisse demander à ces marchands de les demander à nouveau. Conclusions **L'importation d'un marchand ne devrait pas retarder les exportations de tous les autres magasins.** Les exportations et les importations partagent les mêmes travailleurs, de sorte qu'une forte importation retarde tout le monde. Le changement supprime cette cause. **Le travail qui fonctionne une fois par partie ne doit pas croître avec la taille de l'importation entière.** La vérification d'achèvement a lu toute l'importation après chaque partie. C'était très bien pour les importations typiques et n'a échoué que pour une très grande quantité. Avec le changement, une importation de cette taille n'épuise plus la mémoire des travailleurs.
Traduit automatiquement depuis la mise à jour officielle de l'incident.