INCIDENT PROCESSING | Perturbations plateforme de paiement / Payment platform disruptions

English version below

Référence incident

TSR-1177

Service concerné

Paiements e-commerce.

Impact client

Service interrompu sur deux plages de 15 minutes.

Synthèse de l’incident

• 22 janvier - 16h54 : début de l’incident.
• 22 janvier - 16h57 : création de la cellule incident majeur.
• 22 janvier - 17h04 : décision de rollback du service API.
• 22 janvier - 17h07 : redémarrage d’une instance.
• 22 janvier - 17h09 : reprise du service sur l’instance redémarrée.
• 22 janvier - 17h10 : redémarrage des autres instances.
• 22 janvier - 17h12 : temporisation du rollback vu que le redémarrage semble suffisant.
• 22 janvier - 17h13 : réplique de l’incident. Décision de rollback sur toutes les instances.
• 22 janvier - 17h28 : reprise du service.
• 22 janvier - 17h32 : rollback effectif sur toutes les instances. Fin de l’incident.

Contexte

Les flux de paiements sont répartis sur plusieurs instances sur lesquelles des actions peuvent être prises de manière individuelle.

Une livraison du service API opérée la veille de l’incident a engendré une augmentation du nombre de messages transitant sur la plateforme, ce qui était anticipé.

Root cause

Le service de gestion des messages transitant sur la plateforme est arrivé à saturation. Les tentatives de connexion du service API à ce service de gestion des messages sont toutes tombées en échec, ce qui a fini par faire tomber tout le service.

‌

Actions à entreprendre par Payplug

Symptômes	Actions
Saturation du service de gestion des messages.	Court terme - Montée vers une version pouvant encaisser une charge plus importante.  Moyen terme - Comprendre les raisons de la saturation.
Interruption du service API provoqué par la saturation du service de gestion des messages.	Reproduire ce comportement en environnement hors production pour analyser la stabilité du service API. Des actions seront prises en conséquence pour améliorer la résilience du service API vis à vis d’une saturation du service de gestion des messages
Mise en production non conforme au processus défini.	Faire des rappels de processus aux équipes.
Délai de résolution trop long.	Analyse de la chronologie de l’incident et élaboration d’actions en conséquence.

‌

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

Incident reference

TSR-1177

Payment services affected by the incident

E-commerce payments.

Client impact

Service interrupted for two periods of 15 minutes.

Incident Overview

• January 22nd - 4:54pm : incident beginning.
• January 22nd - 4:57pm : major incident response team created.
• January 22nd - 5:04pm : decision to rollback API service.
• January 22nd - 5:07pm : restart of one instance
• January 22nd - 5:09pm : service restored on restarted instance.
• January 22nd - 5:10pm : restart of the other instances.
• January 22nd - 5:10pm : rollback on hold on other instances since restart seems to fix the incident.
• January 22nd - 5:13pm : incident restart. Decision to rollback all instances.
• January 22nd - 5:28pm : service restored.
• January 22nd - 5:28pm : All instances rollbacked. Incident ending.

Context

Payment flows are distributed across multiple instances, on which actions can be taken individually.

A delivery of the API service performed the day before the incident caused an increase in the number of messages transiting on the platform, which was anticipated.

Root cause

The message management service on the platform reached saturation. All connection attempts from the API service to the message management service failed, ultimately bringing down the entire service

Actions to be taken by Payplug

Symptoms	Actions
Saturation of the message management service.	Short term - Upgrade to a version capable of handling a higher load. Medium term - Understand the reasons for the saturation.
API service interruption caused by the saturation of the message management service.	Reproduce this behavior in a non-production environment to analyze the stability of the API service. Actions will be taken accordingly to improve the API service's resilience to saturation of the message management service.
Production deployment not compliant with defined process.	Remind teams of the defined processes.
Resolution delay too long.	Analyze the incident timeline and develop actions accordingly.