(version française à la suite)
(Times GMT+! / Heures GMT+1)
Summary
On Saturday, February 22, between approximately 5:00 PM and 7:45 PM, the Voice Management service was significantly impacted by extreme slowdowns in call connection to agents.
Below, we detail the timeline, causes, impacts, corrective measures, and areas for improvement.
Some aspects are still under investigation, and our efforts are ongoing.
Causes
During the night of Friday, February 21, to Saturday, February 22, a scheduled maintenance operation to update our virtualization infrastructure at the Equinix site in St. Denis did not function correctly. The actions taken left a cluster of machines in a degraded but functional state. Since this state was considered stable, the decision was made to postpone the completion of the operation to the following night.
Starting Saturday afternoon, for unexplained reasons—but likely linked to the degraded cluster configuration—some machines progressively shut down.
At around 5:00 PM, a machine at the impacted site, acting as a message broker for Voice Management services, experienced severe performance degradation. By 6:00 PM, due to uncertainty regarding the machine’s functional state, it was decided to shut it down completely, assuming that the remaining brokers—fully operational—would handle the service.
Impacts
The first phase of the incident, up until approximately 5:00 PM, was handled without significant customer impact, as our systems correctly managed the unavailability of the affected equipment.
However, around 5:30 PM, we were surprised to observe a significant impact, with customers reporting unexplained delays in call connection to agents. A detailed root cause analysis identified a message broker related problem as the source of the issue.
This caused delays of up to 30 seconds for affected calls between the moment an agent picked up and the moment the caller or recipient was actually connected. Approximately one-third of calls were impacted, though the distribution varied between agents and customers.
Additionally, these slowdowns disrupted call distribution, leading to situations where available agents did not receive incoming calls because another agent in the queue was experiencing extended wait times for the previous call.
Corrective Measures
Our teams worked in parallel on two key areas:
By 7:30 PM, the infrastructure gradually recovered, including the problematic message broker. Restarting this system specifically resolved the operational impact on the service.
Problem Analysis
The affected message brokers (four in total) have been in service for several months. At this stage, they are not critical for service operation.
Further analysis and subsequent simulations revealed a bug in how service instances connect to message brokers when a server is unavailable.
In such cases, incorrect timeout values (30 seconds) can occur, leading to the issue observed. This problem was not identified during pre-implementation testing.
Areas for improvement
We sincerely apologize for the impact our customers have experienced on their operations and assure you of our commitment to continuing our efforts to prevent future incidents.
Résumé
Le samedi 22 février, en fin de journée, entre 17h00 et 19h45 environ, le service Voice Management a été significativement impacté par des lenteurs extrêmes dans la connexion des appels aux agents.
Nous détaillons ci-après la chronologie, les causes, les impacts, les mesures correctives et les points d’amélioration.
Certains points ne sont pas définitifs, et notre analyse détaillée se poursuit.
Causes
Dans la nuit du vendredi 21 au samedi 22 février, une maintenance programmée de mise à jour de notre infrastructure de virtualisation du site Equinix à St-Denis n’a pas fonctionné correctement. Les actions entreprises ont laissé un cluster de machines dans un état fonctionnel, mais dégradé. Cet état étant considéré comme stable, il a été décidé de décaler la fin de l’opération à la nuit suivante.
À partir du début de l’après-midi du samedi, de façon inexpliquée mais sans doute en rapport avec la configuration dégradée du cluster, certaines machines se sont progressivement arrêtées.
Vers 17h00, une machine du site impacté, jouant le rôle de broker de messages pour les services Voice Management, a subi une dégradation de performances préoccupante. Vers 18h00, devant l’incertitude quant au niveau fonctionnel de la machine, il a été décidé de l’éteindre complètement, en supposant que le service serait assuré par les autres brokers, eux totalement fonctionnels.
Impacts
La première partie de l’incident, jusque 17h00 environ, a été gérée sans impact client significatif, nos systèmes prenant correctement en compte l’indisponibilité des équipements concernés.
Toutefois, vers 17h30, nous avons été surpris de constater un impact significatif, des clients signalant des lenteurs inexpliquées dans la connexion des appels aux agents.
L’analyse approfondie des causes nous a permis d’identifier un processus lié à la transmission de messages au broker évoqué ci-dessus comme la cause du problème.
Cela provoquait, pour les appels concernés, un délai pouvant atteindre 30 secondes entre le moment où l’agent décrochait et le moment où l’appelé/appelant était connecté.
Environ un tiers des appels étaient impactés, mais cette répartition était inégale entre les agents et les clients.
Ces lenteurs impactaient également la distribution des appels, entraînant des situations où des agents disponibles ne voyaient pas d’appels se présenter, car l’un de leurs collègues était en attente prolongée pour l’appel précédent dans la file.
Mesures Correctives
Nos équipes se sont organisées pour travailler en parallèle sur deux sujets :
Vers 19h30, l’infrastructure est progressivement repartie, y compris le broker de message ayant posé problème.
C’est le redémarrage de ce système qui a spécifiquement permis de résoudre l’impact opérationnel sur le service.
Analyse du Problème
Ces brokers, au nombre de quatre, sont en service depuis quelques mois.
À ce stade, ils ne sont pas nécessaires au bon fonctionnement du service.
L’analyse ultérieure et des simulations réalisées depuis ont permis de mettre en évidence un bug dans la façon dont les connexions aux brokers de messages sont gérées par les instances de service lorsqu’un serveur est indisponible.
Dans ce cas, des timeouts de durée incorrecte (30 secondes) peuvent se produire, conduisant au problème observé.
Ce problème n’avait pas été identifié lors des tests préalables à la mise en place de ce dispositif.
Actions Ultérieures
Nous sommes désolés pour l'impact que nos clients ont eu à subir sur leurs opérations, et vous assurons de notre engagement à poursuivre nos efforts pour éviter de nouveaux incidents à l'avenir.