Nous consacrons énormément de temps à la fiabilité de PagerDuty et de l'infrastructure qui l'héberge. La majeure partie de ce travail est invisible, cachée derrière l'API et l'interface utilisateur avec lesquelles nos clients interagissent. Cependant, lorsqu'elles dysfonctionnent, les conséquences sont immédiatement perceptibles : retards dans les notifications et erreurs 500 sur nos points de terminaison d'API. C'est précisément ce qui s'est produit le samedi 13 avril, vers 8 h, heure du Pacifique. PagerDuty a subi une panne suite à une dégradation de son infrastructure. point d'observation Utilisé par deux régions AWS.

Nous publions ce message pour informer nos clients de ce qui s'est passé, de ce que nous avons appris et de ce que nous allons faire pour résoudre tous les problèmes mis en lumière par cette panne.

Arrière-plan

L'infrastructure de PagerDuty est hébergée dans trois datacenters différents (deux sur AWS et un sur Linode). Depuis un an, nous avons repensé l'architecture de notre logiciel afin qu'il puisse fonctionner même en cas de panne d'un datacenter entier (y compris en cas de déconnexion du réseau). Cependant, la capacité à gérer la défaillance simultanée de deux datacenters n'avait pas été spécifiquement intégrée à notre conception. Aussi improbable que cela puisse paraître, c'est pourtant ce qui s'est produit samedi matin. Étant donné que nous considérons une région AWS comme un datacenter, la défaillance simultanée des deux datacenters nous a empêchés de maintenir notre disponibilité avec notre seul datacenter restant.

Nous avons sélectionné nos trois centres de données de manière à ce qu'ils soient indépendants et physiquement séparés. Cependant, nous avons appris depuis que deux d'entre eux partageaient un point d'interconnexion commun. Ce point d'interconnexion a subi une panne, entraînant l'indisponibilité de nos deux centres de données.

La panne

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

• À 7 h 57, selon AWS, un problème de connectivité survient en raison de la dégradation d'un point d'interconnexion en Californie du Nord.
• À 8 h 11, l'ingénieur d'astreinte de PagerDuty est appelé concernant un problème avec l'un des nœuds de notre système de répartition des notifications.
• À 8h13, une tentative de remise en marche du nœud défaillant est effectuée, mais sans succès.
• À 8h18, notre système de surveillance détecte une défaillance de plusieurs fournisseurs de notifications (due à un problème de connectivité). À ce moment-là, la plupart des notifications sont toujours acheminées, mais avec des latences et des taux d'erreur accrus.
• À 8 h 31, une alerte de niveau 2 a été déclenchée et des renforts d'ingénieurs ont été appelés en renfort.
• À 8h35, PagerDuty perd complètement sa capacité à envoyer des notifications, car il n'a pas pu établir de quorum en raison d'une latence réseau élevée. Un niveau de gravité 1 est déclaré.
• À 8 h 53, le système de notification PagerDuty a atteint le quorum et a commencé à traiter toutes les notifications en attente.
• À 9 h 23, selon AWS, le problème de connectivité au point d'interconnexion de Californie du Nord est résolu.

Lors de l'analyse post-mortem, nos ingénieurs ont également déterminé qu'une erreur de configuration de notre service de coordination nous avait empêchés de rétablir rapidement le service. Au total, PagerDuty n'a pas pu envoyer de notifications pendant 18 minutes, entre 8h35 et 8h53 ; toutefois, durant cette période, notre API d'événements a continué à recevoir des événements.

Ce que nous allons faire

Comme toujours lors des pannes majeures, nous découvrons de nouvelles failles dans notre logiciel. Voici quelques-unes de nos solutions pour corriger les problèmes identifiés.

court terme

1. Lors de notre analyse, nous avons constaté que la journalisation était insuffisante pour déboguer les problèmes au sein de certains de nos systèmes. Nous avons donc renforcé cette journalisation et commencé à la centraliser afin d'en faciliter la recherche.
2. Durant la panne, la plupart des processus de coordination défaillants ont été redémarrés manuellement. Nous allons ajouter un système de surveillance des processus afin de les redémarrer automatiquement.
3. Nous avons également constaté un manque de visibilité sur la connectivité entre les hôtes. Nous allons donc créer un tableau de bord pour y remédier.

à long terme

1. Nous avons également constaté que certains membres de notre équipe d'ingénierie ne maîtrisent pas encore Cassandra et ZooKeeper. Nous allons donc consacrer du temps à former notre personnel à ces deux technologies.
2. Il faudrait envisager de migrer hors d'une des régions AWS. Nous devrons bien étudier le choix d'un nouvel hébergeur et d'un centre de données afin d'éviter tout point de défaillance unique.