English version below

Post Mortem

Référence incident

TSR-2228

Service concerné

Reversement des paiements e-commerce et magasin.

Impact client

Reversement partiel des transactions. 

Synthèse de l’incident

• 4 septembre 7h30 : début de saturation des files traitant différents flux. Début de l’incident.
• 4 septembre 8h50 : détection d’un retard dans le traitement des virements. Création d’une cellule de crise dédiée et début des analyses.
• 4 septembre 8h53 : identification de la saturation de flux dû à une tâche qui tourne en boucle sans succès.
• 4 septembre 8h56 : tests pour répartir certains flux sur des routes secondaires pour éviter la saturation. 
• 4 septembre 9h09 : déplacement de certains flux non affectés par l’incident sur d’autres routes. Poursuite des analyses pour tenter de relancer les virements dans la journée.
• 4 septembre 10h : relance des traitements des virements après plusieurs actions menées pour s’assurer d’éviter des effets de bords.
• 4 septembre 11h57 : fin des traitements après l’heure limite. Certains virements seront réalisés le lendemain.
• 5  septembre : reversement des transactions. Fin de l’incident. 

Contexte

N/A

Root cause

Une mise en production a entraîné une interruption de connexion entre deux API. Une tâche est entrée en boucle et a saturé les différentes routes traitant les flux. 

‌

Actions à entreprendre par Payplug

Symptômes	Actions
Absence de détection d’alerte.	Amélioration du monitoring pour une meilleure identification en cas d’incident.
Blocage des traitements causés par une erreur.	Révision de l’architecture des files d’attentes pour s’assurer qu’une tâche en erreur ne puisse pas bloquer l’ensemble des traitements.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-2228

Payment services affected by the incident

E-commerce & in-store payments settlement.

Client impact

Partial settlement of transactions.

Incident Overview

• 4 September 7:30am – start of queue saturation processing different flows. Start of the incident.
• 4 September 8:50am – detection of a delay in transfer processing. Dedicated crisis unit created and analysis started.
• 4 September 8:53am – identification of flow saturation caused by a task looping unsuccessfully.
• 4 September 8:56am – tests to reroute certain flows through secondary paths to avoid saturation.
• 4 September 9:09am – transfer of some flows not affected by the incident to other routes. Further analysis to attempt to restart transfers during the day.
• 4 September 10:00am – transfer processing restarted after several actions taken to ensure side effects were avoided.
• 4 September 11:57am – processing completed after the cut-off time. Some transfers will be carried out the following day.
• 5 September – transactions paid out. End of the incident.

Context

N/A

Root cause

A production deployment caused a connection interruption between two APIs. A task entered a loop and saturated the different routes processing the flows.

Actions to be taken by Payplug

Symptoms	Actions
No alert detection.	Improved monitoring for better identification in the event of an incident.
Blocking of processing caused by an error.	Review of the queue architecture to ensure that a failed task cannot block all processing.