Nos alertes automatiques nous ont remonté des soucis le mercredi 16 septembre à 11h43 (heure de Paris). Soucis mineurs dans un premier temps, donnant lieu à une simple alerte de routine auprès de notre hébergeur. (dumps Redis trop longs)

Ces erreurs se sont intensifiés au retour de la pause déjeuner (vers 13h54). Nous avions des dump Redis désormais impossible, et ayant des effets de bord sur MySQL. Nous avons ce coup-ci escaladé l'issue précédente en souci "majeur".

Vers 14h30, après investigation de l'équipe tech et de Claranet, nous avons constaté un trop gros usage RAM de Redis pour les sauvegardes automatiques toutes les 2 minutes. Nous avons décidé à 14h39, première action de notre part, de limiter la taille des dump Redis, quitte à tronquer les anciennes valeurs, afin de préserver l'intégrité de la base principale MySQL.

Les sondes de performances indiquent :

• une dégradation des temps de réponse de l'application à partir de 12h43 (passage de 120ms temps moyen en haute activité à 209ms sur la période)
• une augmentation du taux d'erreur à partir de cette même heure, passant de 0,0812% à 2,39%

L'action faite à 14h39 n'a malheureusement pas suffit à endiguer l'escalade de l'usage de la RAM des serveurs backend qui ont fini par lâcher à 14h49. Les équipes Claranet ont été informées dans la minute de l'incident, étant déjà en ligne pour les soucis de RAM sus-mentionnés. Après enquête sommaire, et avoir escaladé en interne chez eux l'incident, il a été décidé de forcer la bascule du backend sur le serveur slave et de redémarer le master, en y ajoutant 10Gb de RAM. Une fois ceci effectué, le trafic a été re-basculé sur le master, puis ce fut au tour du slave de redémarer avec plus de RAM.

A 15h09 précisément, 90% de l'infrastructure était à nouveau disponible et opérationnelle. Le serveur de temps réel était impacté par ces opérations et diffusait les événements live en long polling (toutes les 60 secondes). Nous avons été alerté de ceci vers 15h19 (10 minutes après la fin de l'avarie majeure), et avons effectué les mesures nécessaires sur cet élément à 15h27.

Les symptômes de cette avarie ont été les suivants:

• tout participant déjà sur Wisembly ne pouvait que consulter le contenu déjà présent, et ne pouvait pas en ajouter de nouveau
• tout animateur/administrateur de Wiz ne pouvait pas lancer de sondage/passer un document/changer de slide
• en revanche, les solutions Visio collab et Live event n'ont pas été affectée par ce souci, tout comme les intégrations tierces parties (Zoom, Webex, etc..).

=> Pour les participants en cours de réunion, cette avarie s'est traduite par une perte complète des fonctionalités d'interactivité, mais pas de flux audio/vidéo

=> Pour les participants/administrateurs cherchant à rejoindre une réunion en cours ou à venir, ils ont été dans l'incapacité de le faire de 14h49 à 15h09

Cet incident, dû à une surconsomation de la RAM des serveurs de backend hébergeant les bases de données et queues de messages, a été réglé à court et moyen terme par une augmentation de 40% de la RAM de ces machines + redémarrage. Les équipes Wisembly et Claranet, de concert, dans les prochains jours, vont étudier en détail la consommation de la RAM de chacun des applicatifs de ces serveurs pour être plus efficient, et aboutir à une solution nominale pérenne à la vue de l'augmentation des usages de la plateforme Wisembly de ces derniers mois et des mois à venir.

Veuillez contacter l'équipe Success si vous avez été impacté par cet incident et que cette dernière n'est pas déjà revenue vers vous. Nous avons des offres d'indemnisations à vous proposer.