Au début de l’année, Slack était victime d’une panne privant de travail pendant de longues heures plusieurs millions de salariés. Selon un rapport, l’origine de la panne est à chercher chez son fournisseur de services cloud, AWS en l’occurrence.
Quelques semaines après l’annonce de son rachat par Salesforce pour 27,7 milliards de dollars, Slack était victime d’une panne. Le 4 janvier 2021 très précisément. Elle est arrivée au pire moment avec la reprise du travail pour des millions de salariés à travers le monde, après la période des fêtes de fin d’année. A l’époque, Slack n’avait pas communiqué sur les raisons de cette interruption de service en expliquant seulement qu’il allait mener une enquête.
Les résultats de cette investigation ont été envoyés aux clients, rapporte nos confrères du site américain Protocol. « Vers 6 heures du matin PST (heure du pacifique), nous avons commencé à connaître des pertes de paquets entre les serveurs, causées par un problème de routage au sein des services réseaux de notre fournisseur de cloud ». Le site précise que, selon une source, le souci provenait de la solution Transit Gateway d’AWS qui n’a pas été assez rapide pour répondre au pic de charge sur Slack lors du retour au bureau des salariés.
Dans la suite de l’analyse, la perte de paquets engendrée par les problèmes réseaux a conduit les serveurs Slack à signaler un nombre croissant d’erreurs. Des serveurs « sains » ont pris alors le relais, mais ont du encaisser un pic de charge très élevé. Les ingénieurs de Slack n’ont été avertis des perturbations qu’à 6h45 PST. « A 7 heures du matin PST, le nombre de serveurs backend était insuffisant pour répondre à nos besoins de capacité », précise le rapport d’enquête de Slack.
Un système de serveurs de secours peu réactif
Le service de collaboration disposait d’une réserve de serveurs de sauvegarde prête à fonctionner, mais il a découvert des problèmes dans le système de provisioning pour faire tourner et vérifier ces serveurs de secours. Ce système n’était pas conçu pour exécuter Slack sur plus de 1 000 serveurs en si peu de temps. A noter que les soucis réseaux ont impacté le service d’observabilité de Slack, qui ne pouvait donc pas réparer les bugs.
Entre 7 heures et 8h15 du matin PST, AWS a augmenté la capacité de son service Transit Gateway et a basculé Slack d’un système mutualisé à un système dédié. Une fois cette étape terminée, les problèmes du système de provisioning ont été résolus, les serveurs ont retrouvé des connexions réseau stables et le service a commencé à revenir à la normale au cours de l’heure suivante. Auprès de ses clients, Slack a promis de revoir son architecture au cours des prochains mois, notamment en améliorant son système d’alerte en cas de perte de paquets.