Le jeudi 14 juin, à partir de 20 h 44, heure du Pacifique, PagerDuty a subi une grave panne. L'application a connu 30 minutes d'arrêt, suivies d'une période de charge élevée. Nous prenons la fiabilité de nos systèmes très au sérieux ; c'est notre priorité numéro un. Nous avons rédigé ce post-mortem pour vous donner une information complète sur ce qui s'est passé, ce qui n'a pas fonctionné, ce que nous avons bien fait et ce que nous faisons pour garantir que cela ne se reproduise plus jamais.

Nous tenons également à nous excuser pour la panne. Elle n'aurait pas dû durer aussi longtemps. En fait, elle n'aurait jamais dû se produire.

Arrière-plan

L'infrastructure PagerDuty est hébergée chez plusieurs fournisseurs. Au moment d'écrire ces lignes, notre principal fournisseur est Amazon AWS et notre système principal est hébergé sur AWS dans la région Est des États-Unis.

Nous avons conçu nos systèmes dès le départ pour être tolérants aux pannes dans plusieurs zones de disponibilité (AZ). Les AZ sont essentiellement des centres de données distincts au sein d'une région AWS. Ainsi, en cas de panne d’une seule AZ, PagerDuty peut récupérer rapidement en basculant vers une AZ de sauvegarde.

AWS peut échouer de différentes manières. La défaillance d'une seule zone de disponibilité est le cas le plus simple, pour lequel nous avons conçu une solution en répartissant notre pile principale (comprenant à la fois les serveurs de base de données et les serveurs Web) sur plusieurs zones de disponibilité.

Un autre scénario de défaillance d'AWS, beaucoup plus grave, est la défaillance d'une région entière en même temps. Historiquement, cela s’est produit plusieurs fois. PagerDuty est également conçu pour être tolérant aux pannes dans ce cas. Nous avons mis en place une sauvegarde à chaud de notre pile complète sur un fournisseur d'hébergement distinct (non Amazon). Dans ce cadre, nous avons développé un processus de basculement d'urgence qui nous permet de passer rapidement d'AWS à notre fournisseur de sauvegarde.

La panne

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

• À 20h44, nos outils de surveillance ont détecté une panne de l'application PagerDuty .
• A 20h49, l'ingénieur d'astreinte de PagerDuty a été contacté. La personne de garde s'est rendu compte qu'il s'agissait d'un incident de gravité 1 et a contacté quelques autres ingénieurs pour l'aider.
• À 20h55, la décision a été prise de faire le basculement d'urgence vers notre fournisseur de secours (celui qui n'est pas dans AWS). La raison de cette décision est que l'équipe d'intervention a remarqué que la console AWS était en panne, ce qui les a amenés à penser qu'un basculement vers une zone de disponibilité de secours ne fonctionnerait pas.
• À 21h14, le basculement vers le fournisseur d'hébergement de secours a été effectué. À ce stade, nos systèmes étaient pleinement opérationnels mais soumis à une charge très élevée, travaillant pour traiter un important arriéré de notifications.
• 21h22 : Le gros retard de notifications a été éliminé. À ce stade, nous étions toujours sous une charge de travail importante : les nouvelles notifications prenaient 5 à 6 minutes à être traitées.
• À 10h03, la charge a diminué et nous étions de retour à la normale, traitant les notifications en quelques secondes.

Ce que nous avons fait de mal

Nous ne sommes pas satisfaits du fait qu'il nous ait fallu 30 minutes pour effectuer le basculement d'urgence vers notre pile de secours. Nous ne sommes pas non plus satisfaits de la manière dont nous avons géré la charge élevée une fois le basculement terminé. Voici la liste complète des problèmes :

1. Nos outils de surveillance ont mis 5 minutes pour nous signaler le problème. Ce délai est trop long : une valeur acceptable se situe entre 1 et 2 minutes.
2. Après que l'ingénieur de garde a réalisé qu'il avait affaire à un problème de gravité 1, il lui a fallu plusieurs minutes pour organiser un appel de groupe avec le reste de l'équipe. Notre processus de gravité 1 s'appuie sur Skype pour organiser l'appel de groupe. Cependant, Skype a planté plusieurs fois, ce qui a entraîné une perte de temps.
3. Le retournement d'urgence a pris trop de temps – 20 minutes. Le guide de retournement est trop détaillé et donc difficile à suivre en cas d'urgence. De plus, certaines des personnes qui ont travaillé à l'exécution du retournement n'en avaient jamais fait auparavant, ce qui a fait que l'opération a pris plus de temps.
4. Après le retournement, nous avons eu du mal à faire tourner tous nos processeurs de tâches d’arrière-plan à pleine capacité.

Ce que nous avons bien fait

Dans l'ensemble, nous avons effectué un retournement d'urgence du centre de données dans les 30 minutes suivant une panne et le processus de retournement a fonctionné. Voici la liste des choses qui se sont bien déroulées :

1. Nous avons réagi très rapidement à la panne.
2. Nous avons pris la bonne décision en effectuant la désactivation d'urgence d'AWS. Cela a été fait après avoir constaté que la console AWS était en panne.
3. Nous avons communiqué régulièrement via nos comptes Twitter @pagerduty et @pagerdutyops pour tenir nos clients informés de la panne. Au cas où vous ne le sauriez pas déjà, notre compte Twitter @pagerdutyops est réservé aux notifications d'urgence en cas de panne. En fait, vous pouvez le configurer pour qu'il vous envoie un SMS pour chaque mise à jour que nous effectuons. Pour plus d'informations, consultez http://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down .
4. Vue d'ensemble : notre pile de sauvegarde à chaud redondante hébergée sur un autre fournisseur (non Amazon) a très bien fonctionné. Cette pile nous a permis de limiter la panne à 30 minutes seulement. Si nous n'avions pas eu la pile de sauvegarde, la panne aurait pu durer 1 heure, voire plus.

Ce que nous allons faire pour éviter que cela ne se reproduise

Grande image:

Nous migrons nos centres de données. Nous quittons AWS US-East pour nous diriger vers US-West. Cette migration de centre de données était prévue (bien avant la panne) pour le 19 juin. La raison de cette migration est que beaucoup de nos clients (plus de 20 %) exécutent leurs applications dans US-East. Lorsque la région rencontre des problèmes, nous perdons de la capacité et nous sommes soumis à une charge de travail importante de la part de nos clients. Essentiellement, nos échecs sont corrélés à ceux de nos clients. Donc, à court terme (c'est-à-dire demain), nous déménageons vers US-West. Pour faire une parenthèse rapide, le moment de cette panne n'aurait pas pu être pire : nous étions à seulement 5 jours de notre basculement prévu vers US-West lorsque la panne s'est produite.

À long terme, nous avons réalisé deux choses principales :

• Nous ne pouvons pas faire confiance à un seul fournisseur d’hébergement.
• Les flips sont mauvais : ils entraînent toujours des temps d'arrêt et parfois ils ne fonctionnent pas.

En conséquence, nous allons passer à une configuration à 3 fournisseurs d'hébergement où le système PagerDuty est réparti sur 3 centres de données (3 DC pour démarrer, 5 plus tard). Nous passons également à un magasin de données distribué et tolérant aux pannes (Cassandra) à plusieurs nœuds qui ne nécessite pas de retournement en cas de panne d'un centre de données. Ce projet a démarré en décembre dernier et le composant d'envoi de notifications de PagerDuty fonctionne déjà sur la nouvelle pile.

Détails:

1. Nous envisageons de mettre en œuvre un autre outil de surveillance interne qui alertera le personnel de garde dans un délai de 1 à 2 minutes dès qu'une panne est détectée.
2. Nous allons étudier la possibilité de mettre en place une alternative à Skype pour démarrer un appel de groupe afin de traiter les problèmes de niveau 1. Nous mettrons probablement en place un pont de conférence téléphonique fiable, à moins que nous ne trouvions une meilleure solution (chers lecteurs, si vous avez des suggestions à ce sujet, n'hésitez pas à nous en faire part dans les commentaires).
3. Nous allons travailler à la rationalisation du processus de retournement d'urgence. Dans ce cadre, nous allons condenser le manuel de retournement et le tester en profondeur. Nous allons également étudier l'automatisation de certaines parties du processus.
4. Nous allons effectuer des tests de charge sur nos systèmes et rechercher des moyens d'optimiser les processus d'arrière-plan qui envoient des notifications. L'objectif est de récupérer rapidement après avoir effectué un retournement d'urgence et de gérer des scénarios de charge élevée.