22h30 heure de Paris

Le serveur en cause a été purgé et redémarré. Il a été réintégré au pool de cache.

Nous prévoyons plusieurs changements pour éviter qu'une telle situation se reproduise :

• Augmenter la capacité du pool de serveurs de cache
• Mettre en place un meilleur monitoring du système Redis que nous utilisons pour détecter les problèmes de fragmentation de la base

14h40 heure de Paris

Un de nos serveurs de cache était en cause, nous l'avons manuellement enlevé du pool. Nous cherchons la cause du problème.

14h10 heure de Paris

Nos serveurs d'applications sont en erreur. Il semble que ce soit l'accès à nos serveurs de cache qui soit en cause. Nous recherchons la cause exacte et une solution.

Lundi 16 mai à 21h40 heure de Paris

Une version corrigée de HAProxy vient d'être publiée, après un test concluant, nous déployons sur nos Load Balancer de production cette nouvelle version qui corrige le problème avec Android et MyVS en HTTP2.

Mercredi 11 mai à 9h heure de Paris

Nous testons de désactiver le protocole HTTP 2 sur nos load balancer et les terminaux Android arrivent à nouveau à passer des requêtes HTTP avec succès. Nous déployons ce changement de configuration.

L'étape suivante, c'est de comprendre ce qui provoque un problème entre notre load balancer, le protocole HTTP 2 et les terminaux Android.

Lundi 9 mai 2022 à 16h heure de Paris

Après avoir passé en revue tous nos composants, nous constatons que l'API utilisée par MyVS est fonctionnelle, mais les requêtes HTTP envoyées par les terminaux Android ne sont pas traitées correctement et reçoivent une erreur HTTP 500 en réponse. Techniquement, tout est ok pourtant.

Lundi 9 mai 2022 à 9h heure de Paris

Notre équipe support nous indique qu'il est impossible de se connecter à l'application MyVS depuis n'importe quel terminal sous Android.

À 15h50 heure de Paris,

Les données sont synchronisées, le cluster est au complet avec ces 3 nœuds. Le load balancer du groupe ne rencontre plus de difficulté à servir les demandes. Nous allons analyser la cause du problème au niveau du nœud qui subit un problème technique en début d'après-midi.

Nous allons également travailler à l'amélioration de la répartition de charge pendant une resynchronisation des données, un seul nœud pouvant accueillir correctement les demandes, l'autre étant occupé à fournir les données au nœud qui redémarre.

À 14h30 heure de Paris,

Nous avons réussi à forcer le trafic vers le noeud du cluster qui n'est pas occupé à effectuer la réplication, les environnements sont à nouveau accessibles normalement.

À 12h30 heure de Paris,

un des serveurs du cluster de base de données du groupe 4 a subi un problème de synchronisation de données. Nous avons déclenché une resynchronisation des données vers 13h50 heure de Paris, néanmoins nous observons des erreurs de connexion aléatoires depuis que nous avons lancé cette synchronisation.

Plus de la moitié des données a été synchronisée.

À la fin de la synchronisation, tout rentrera dans l'ordre.

Nous nous excusons pour la gêne occasionnée.