English version below

Post Mortem

Référence incident

TSR-1381

Service concerné

Demandes de paiements. 

Affichage des transactions.

Impact client

Arrêt d’envoi des liens de paiement.

Non affichage des nouvelles transactions.

Synthèse de l’incident

• 26 février - 12h10 : surcharge de messages qui s’empilent dans une file. Début de l’incident.
• 26 février - 12h26 : redémarrage des services défectueux.  
• 26 février - 12h50 : création d’une cellule de crise dédiée et début des analyses.
• 26 février - 13h00 : compréhension de l’origine de l’incident.
• 26 février - 13h01 : redémarrage d’une instance et poursuite des analyses suite à la continuation des erreurs.
• 26 février - 13h40 : identification d’une désynchronisation entre les instances d’un logiciel de gestion des messages.
• 26 février - 14h15 : contact du support externe d’un outil gérant les files des messages.
• 26 février - 14h32 : test d’un fix.
• 26 février - 14h38 : remontée d’alerte sur la non transmission des liens de paiement.
• 26 février - 14h39 : réponse du support externe qui débute les analyses.
• 26 février - 15h04 : relance du support externe devant l’absence d’informations supplémentaires.
• 26 février - 15h23 : réponse du support externe qui ne parvient pas à débloquer la situation.
• 26 février - 16h07 : plusieurs relances au support et mise en pause des actions internes pour ne pas entrer en collision avec les actions menées par le support externe. 
• 26 février - 16h40 : redémarrage avec succès de la première instance.
• 26 février - 16h45 : redémarrage successifs des autres instances.
• 26 février - 16h46 : différentes actions de redémarrages des services suite au retour du support externe.. 
• 26 février - 17h22 : les messages sont de nouveau envoyés. Reprise du service.
• 26 février - 18h15 : Fin de l’incident.

Contexte

Les différents messages qui s’empilent contiennent les informations des transactions. Le non traitement de ces messages cause donc le non affichage des transactions et le non envoi des demandes de paiement.

Le service de gestion des messages repose sur plusieurs instances redondées.

Root cause

La désynchronisation des queues a été causée par un pic très élevé de messages ce qui a mené à la saturation des instances. 

Symptômes	Actions
Surcharge soudaine de messages dans les instances.	Une analyse est en cours pour mettre en place des actions permettant d’éviter cette surcharge.

‌

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

Post Mortem

Incident reference

TSR-1381

Payment services affected by the incident

Payment requests.

Transactions display.

Client impact

Stop sending payment links and displaying transactions.

Incident Overview

• February 26 - 12:10 PM: message overload stacking up in a queue. Incident begins.
• February 26 - 12:26 PM: restart of malfunctioning services.
• February 26 - 12:50 PM: creation of a dedicated crisis team and start of analysis.
• February 26 - 1:00 PM: understanding of the origin of the incident.
• February 26 - 1:01 PM: restart of an instance and continuation of analysis due to ongoing errors.
• February 26 - 1:40 PM: identification of desynchronisation between instances of a message management software.
• February 26 - 2:15 PM: contact with external support for a tool managing the message queues.
• February 26 - 2:32 PM: testing of a fix.
• February 26 - 2:38 PM: alert raised regarding the non-transmission of payment links.
• February 26 - 2:39 PM: response from external support who begins analysis.
• February 26 - 3:04 PM: follow-up with external support due to lack of additional information.
• February 26 - 3:23 PM: response from external support unable to resolve the issue.
• February 26 - 4:07 PM: several follow-ups with support and pause of internal actions to avoid conflict with actions from external support.
• February 26 - 4:40 PM: successful restart of the first instance.
• February 26 - 4:45 PM: successive restarts of other instances.
• February 26 - 4:46 PM: various service restarts following the return of external support.
• February 26 - 5:22 PM: messages are sent again. Service resumed.
• February 26 - 6:15 PM: End of the incident.

Context

The various messages that pile up contain transaction information. If these messages are not processed, transactions are not displayed and payment requests are not sent.

The message management service is based on several redundant instances.

Root cause

The desynchronisation of the queues was caused by a very high peak of messages, which led to the saturation of the instances. 

Actions to be taken by Payplug

Symptoms	Actions
Sudden overload of messages in the instances.	An analysis is underway to put in place measures to avoid this overload.