Slack : notre “terrible, horrible journée” où une panne nous a contraint à faire du Zoom et de l’e-mail

Les ingénieurs de Slack ont rendu public un incident survenu le 12 mai dernier, lorsque Slack est tombé en panne pendant plusieurs heures au milieu d’une épisode de télétravail de masse au coeur de la pandémie de la Covid-19. Slack a publié un

.

Les deux contenus permettent de comprendre la manière dont les ingénieurs de Slack, qui dépendent également de Slack pour communiquer, gèrent la reprise lorsque les choses tournent mal. Au début, Slack a été présenté comme un tueur de courriels, et Microsoft a répondu à Slack avec Teams. Mais pendant la pandémie de Coronavirus, une rivalité entre Microsoft Teams et Zoom est apparue, les employés étant obligés de mener des réunions par vidéo depuis leur domicile.

Que s’est-il donc passé à Slack lorsque ce dernier s’est effondré à 16h45, heure du Pacifique, le 12 mai ? Comme tout le monde pendant le confinement, l’équipe de réponse aux incidents de Slack a rapidement organisé une réunion vidéo Zoom, qui n’a pas été organisée depuis Slack, mais via un courriel adressé à toute l’entreprise. Oui, un mail, le média que Slack était censé tuer dans le cadre de l’entreprise.

publicité

Problème d’équilibrage de charge

“Dans ces situations où nous ne pouvons pas compter sur Slack, nous avons prescrit d’autres méthodes de communication”, dit Ryan Katkov, un responsable de l’ingénierie chez Slack. “Suite aux rapports d’incidents, nous avons rapidement déplacé l’incident sur Zoom et élevé la réponse à un Sev-1, notre plus haut niveau de gravité.” Zoom semble avoir donc su gérer les besoins de communication de crise de Slack lorsque celui-ci était en panne.

“Des ingénieurs de différentes équipes se sont joints à l’appel Zoom, des secrétaires enregistraient la conversation sur Zoom pour une diffusion ultérieure, des opinions et des solutions ont été proposées. Des graphiques ont été partagés”, écrit M. Katkov. “C’est une bouffée d’adrénaline que le responsable de la gestion des incidents doit guider et maintenir les bonnes personnes concentrées afin que les mesures les plus appropriées puissent être prises, en équilibrant le risque et le rétablissement du service. De multiples axes de travail ont été établis et assignés dans le but d’apporter des mesures correctives de la manière la plus efficace possible”.

Comme l’explique Laura Nolan, ingénieur en fiabilité de Slack, les systèmes de Slack ont commencé à flancher à 8h30 lorsque des alarmes ont été déclenchées au niveau de la base de données utilisateurs Vitess. Son récit de la panne – “Une terrible, horrible, mauvaise, très mauvaise journée chez Slack” – révèle que la charge supplémentaire sur la base de données de Slack a été contenue en annulant un changement de configuration. Mais l’incident a eu un effet d’entraînement sur son application web principale.

“Nous avons augmenté notre nombre d’instances de 75 % pendant l’incident”

“Nous avons augmenté notre nombre d’instances de 75 % pendant l’incident, pour finir avec le plus grand nombre d’hôtes de webapps que nous ayons jamais eu à ce jour. Tout semblait aller bien pendant les huit heures qui ont suivi, jusqu’à ce que nous soyons avertis que nous avions plus d’erreurs HTTP 503 que la normale”, explique Laura Nolan, ingénieur en fiabilité du site de Slack. Nolan détaille une série de problèmes qui ont affecté la flotte d’instances du logiciel HAProxy de Slack pour son équilibreur de charge. Ces problèmes ont fini par affecter les instances de ses applications web, qui ont commencé à dépasser le nombre de créneaux disponibles dans l’HAProxy.

“Si vous considérez les machines à sous HAProxy comme un jeu géant de chaises musicales, certaines de ces applications web ont été laissées sans siège. Ce n’était pas un problème – nous avions plus qu’assez de capacité de service”, écrit-elle. “Cependant, au cours de la journée, un problème est apparu. Le programme qui synchronisait la liste d’hôtes avec l’état du serveur HAProxy avait un bug. Il essayait toujours de trouver un slot pour les nouvelles instances de webapps avant de libérer les slots occupés par les anciennes instances de webapps qui ne fonctionnaient plus”.

Ce programme a commencé à ne plus fonctionner car il n’a pas pu trouver de slots vides, de sorte que les instances HAProxy en cours d’exécution ne recevaient pas de mise à jour de leur état. La panne s’est produite après que Slack ait réduit son niveau d’application web pour s’aligner sur la fin de la journée de travail aux États-Unis. Ce problème a été réglé, mais Nolan et son équipe n’ont pas compris pourquoi son système de surveillance n’avait pas signalé le problème plus tôt.

Source : “ZDNet.com”

Leave a Reply

Your email address will not be published. Required fields are marked *