Les 3 et 4 juin, le pipeline de notifications de PagerDuty a subi deux pannes SEV-1 majeures. Le 3 juin, la panne a entraîné une période de mauvaises performances qui a entraîné des retards dans l'envoi de certaines notifications. Le 4 juin, la panne a été plus grave. Afin de récupérer de la panne, les données en vol du système ont été purgées et ont entraîné l'échec de la livraison des notifications, l'échec de l'acceptation des événements entrants de notre API d'intégration et un nombre important de notifications retardées.

Nous tenons à nous excuser auprès de tous nos clients qui ont été touchés par cette panne. Il s'agit d'un problème très grave et nous prenons des mesures pour éviter qu'une panne de cette ampleur ne se reproduise à l'avenir.

Ce qui s'est passé?

Notre pipeline de notifications repose sur un datastore NoSQL appelé Cassandra. Ce datastore open source, distribué, hautement disponible et décentralisé alimente certains des sites/services les plus populaires sur Internet. Cassandra s'est également avéré être un système complexe, difficile à gérer et à régler correctement.

Le 3 juin, le processus de réparation sur l'un des nœuds de notre cluster Cassandra a commencé à fonctionner normalement. Ce processus de réparation en arrière-plan de Cassandra, utilisé pour maintenir la cohérence des données stockées dans l'ensemble du cluster, exerce une pression considérable sur Cassandra. Cela a eu un impact sur les performances de notre banque de données. Le processus de réparation, combiné à une charge de travail supplémentaire élevée appliquée à ce moment-là, a placé le cluster Cassandra dans un état fortement dégradé.

Pour remédier à la situation, notre équipe a diminué la charge sur le cluster. Dans le cadre de cette opération, le processus de réparation a été interrompu. Bien que cela ait temporairement résolu l'incident, le cluster a connu six heures d'oscillation entre périodes de stabilité et d'instabilité. Nous avons ensuite éliminé la communication entre certains nœuds pour tenter de stabiliser le cluster, et les opérations normales ont finalement repris.

Au cours de cette panne, le pipeline de notifications de PagerDuty a été dégradé à un point où environ 3 % des événements envoyés à notre API d'intégration n'ont pas pu être reçus et un petit nombre de notifications (une fraction de 1 %) ont connu une livraison retardée.

Le 4 juin, notre équipe a relancé manuellement le processus de réparation qui avait été reporté le 3. Malgré la désactivation d'une quantité importante de charges système facultatives, le processus de réparation a finalement réintroduit la panne de la veille sur notre système. Malheureusement, cette panne ultérieure a été beaucoup plus dommageable : au cours de cette panne, nous n'avons pas pu recevoir 14,9 % des événements envoyés à notre API d'intégration, tandis que 27,5 % des notifications n'ont pas été envoyées du tout et que 60,9 % des notifications ont été retardées de plus de 5 minutes.

Dans un premier temps, nous avons tenté de reproduire notre processus de la veille pour stabiliser Cassandra, mais ces efforts n’ont pas eu le même résultat. Après plusieurs tentatives supplémentaires pour stabiliser les performances du pipeline de notifications, il a été décidé de prendre une mesure drastique pour reprendre le contrôle du pipeline : une « réinitialisation d’usine », supprimant toutes les données en cours dans le pipeline de notifications. Cela a permis à l’équipe de rétablir progressivement le service, ce qui a conduit à la stabilisation du pipeline et à un retour à un fonctionnement normal. Cassandra a immédiatement récupéré après la « réinitialisation », bien que certains de nos systèmes en aval aient nécessité une intervention manuelle pour que leurs données soient cohérentes avec la nouvelle « page blanche ».

Bien que nos systèmes soient désormais pleinement opérationnels, nous sommes toujours en train de procéder à notre analyse des causes profondes, car nous devons comprendre pourquoi nos approches de stabilisation n'ont pas fonctionné. Fondamentalement, cependant, nous savons que nous n'avons pas été suffisamment dimensionnés et que nous avons partagé le cluster entre trop de services différents avec des modèles de charge et d'utilisation disparates.

Qu'est-ce que nous faisons?

À l’avenir, notre priorité absolue est de nous assurer qu’une panne comme celle-ci n’affectera plus nos clients. Chez PagerDuty, nous prenons la fiabilité très au sérieux et donnerons la priorité aux projets qui contribueront à rendre notre système plus stable à l'avenir. Voici quelques-uns des changements que nous allons entreprendre pour éviter que ce type de panne ne se reproduise :

• Mise à l'échelle verticale des nœuds Cassandra existants (serveurs plus grands et plus rapides)

• Configurer plusieurs clusters Cassandra et répartir nos charges de travail entre eux

• Établir des seuils de charge système à partir desquels, à l'avenir, nous mettrons à l'échelle de manière proactive et horizontale nos clusters Cassandra existants

• Mettre à niveau les clusters actuels et nouveaux vers une version plus récente de Cassandra

• Mettre en œuvre d'autres techniques de délestage pour nous aider à contrôler Cassandra en cas de charges élevées

• Apporter une expertise Cassandra supplémentaire en interne

Une dernière chose qui doit être mentionnée : nous avions déjà décidé de prendre certaines des mesures ci-dessus car nous avions remarqué des problèmes similaires récemment. Nous avions déjà réalisé certaines des améliorations prévues, mais malheureusement, nous avions décidé de faire le reste des améliorations dans un ordre basé principalement sur l'efficacité : nous avions décidé de faire la mise à niveau de la version Cassandra avant la mise à l'échelle verticale + horizontale. Malheureusement, nous avons manqué de temps. Il est maintenant évident que la mise à l'échelle devait se produire en premier, et depuis le 4, nous avons déjà terminé la mise à l'échelle verticale et sommes en train de diviser nos clusters Cassandra en fonction de la charge de travail et de l'utilisation.

Si vous avez des questions ou des préoccupations, envoyez-nous un e-mail à support@pagerduty.com .