Nous consacrons énormément de temps à la fiabilité de PagerDuty et de l'infrastructure qui l'héberge. La plupart de ce travail est invisible, caché derrière l'API et l'interface utilisateur avec laquelle nos clients interagissent. Cependant, lorsqu'ils échouent, ils deviennent très visibles sous forme de retards dans les notifications et de 500 sur les points de terminaison de notre API. C'est ce qui s'est passé le samedi 13 avril vers 8h00, heure du Pacifique. PagerDuty a subi une panne déclenchée par une dégradation dans un point d'observation utilisé par deux régions AWS.

Nous écrivons cet article pour informer nos clients de ce qui s'est passé, de ce que nous avons appris et de ce que nous ferons pour résoudre tous les problèmes découverts par cette panne.

Arrière-plan

L'infrastructure de PagerDuty est hébergée dans trois centres de données différents (deux dans AWS et un autre dans Linode). Au cours de l'année écoulée, nous avons repensé l'architecture de notre logiciel dans le but de lui permettre de survivre à la panne d'un centre de données entier (y compris en le séparant du réseau), mais quelque chose qui n'était pas spécifiquement intégré dans notre conception était la capacité de survivre à la panne de deux centres de données à la fois. Bien que cela soit peu probable, c'est ce qui s'est passé samedi matin. Étant donné que nous considérons une région AWS comme un centre de données et que les deux tombent en panne en même temps, nous n'avons pas pu rester disponibles avec seulement notre dernier centre de données restant.

Nous avons choisi nos trois centres de données de manière à ce qu'ils ne soient pas dépendants les uns des autres et nous nous sommes assurés qu'ils soient physiquement séparés. Cependant, nous avons depuis appris que deux des centres de données partageaient un point de peering commun. Ce point de peering a connu une panne qui a entraîné la mise hors ligne de nos deux centres de données.

La panne

Note: Toutes les heures mentionnées ci-dessous sont en heure du Pacifique.

• À 7h57, selon AWS, un problème de connectivité commence en raison de la dégradation d'un point de peering dans le nord de la Californie
• À 8h11, l'ingénieur de garde de PagerDuty est alerté d'un problème avec l'un des nœuds de notre système de répartition des notifications.
• À 8h13, une tentative est faite pour ramener le nœud défaillant mais sans succès
• À 8h18, notre système de surveillance détecte une défaillance de plusieurs fournisseurs pour les notifications (causée par un problème de connectivité). À ce stade, la plupart des notifications continuent de passer, mais avec des latences et des taux d'erreur accrus
• À 8h31, un Sev-2 a été déclaré et davantage d'ingénieurs ont été appelés pour aider.
• À 8h35, PagerDuty perd complètement sa capacité à envoyer des notifications, car il ne parvient pas à établir le quorum en raison de la latence élevée du réseau. Sev-1 est déclaré
• À 8 h 53, le système de répartition des notifications PagerDuty a pu atteindre le quorum et a commencé à traiter toutes les notifications en file d'attente.
• À 9h23, selon AWS, le problème de connectivité au point de peering de Californie du Nord prend fin

Lors de l'analyse post-mortem, nos ingénieurs ont également déterminé qu'une mauvaise configuration de notre service de coordinateur nous a empêché de récupérer rapidement. Au total, PagerDuty n'a pas pu envoyer de notifications pendant 18 minutes entre 8h35 et 8h53 ; cependant, pendant cette période, notre API d'événements était toujours en mesure d'accepter des événements.

Ce que nous allons faire

Comme toujours lors de pannes majeures, nous découvrons de nouvelles failles dans nos logiciels. Voici quelques-unes de nos mesures visant à corriger les problèmes découverts.

Court terme

1. Au cours de notre analyse, nous avons constaté que nous ne disposions pas d'une journalisation adéquate pour résoudre les problèmes dans certains de nos systèmes. Nous avons désormais ajouté davantage de journalisation et commencé à les regrouper dans une source unique pour une meilleure recherche.
2. Pendant la panne, la plupart des processus de coordination ayant échoué ont été redémarrés manuellement. Nous allons ajouter un observateur de processus pour redémarrer ces processus automatiquement.
3. Nous avons également constaté que nous n'avions pas une bonne visibilité sur la connectivité entre les hôtes. Nous allons créer un tableau de bord qui le montre.

Long terme

1. Nous avons également constaté que tous nos ingénieurs ne sont pas au courant des dernières nouveautés concernant Cassandra et ZooKeeper. Nous allons consacrer du temps à former notre personnel sur ces deux technologies.
2. Envisagez de quitter l'une des régions AWS. Nous devrons faire nos devoirs lors du choix d'un nouveau fournisseur d'hébergement et du centre de données pour éviter un point de défaillance unique.