Le jeudi 14 juin, à partir de 20h44, heure du Pacifique, PagerDuty a subi une panne importante. L'application a été indisponible pendant 30 minutes, suivies d'une période de forte charge. La fiabilité de nos systèmes est primordiale pour nous. Ce rapport d'incident a pour but de vous informer en toute transparence sur les causes de l'incident, les erreurs commises, les mesures correctives mises en place et les actions entreprises pour éviter qu'il ne se reproduise.

Nous tenons également à nous excuser pour cette interruption de service. Elle n'aurait pas dû durer aussi longtemps. En réalité, elle n'aurait pas dû se produire du tout.

Arrière-plan

L'infrastructure de PagerDuty est hébergée chez plusieurs fournisseurs. À l'heure actuelle, notre principal fournisseur est Amazon AWS et notre système principal est hébergé sur AWS dans la région USA Est.

Nous avons conçu nos systèmes dès le départ pour assurer une tolérance aux pannes sur plusieurs zones de disponibilité (AZ). Les AZ sont des centres de données distincts au sein d'une région AWS. Ainsi, en cas de défaillance d'une AZ, PagerDuty peut reprendre rapidement en basculant vers une AZ de secours.

AWS peut tomber en panne de multiples façons. La panne d'une seule zone de disponibilité est le cas le plus simple, que nous avons pris en compte en répartissant notre infrastructure principale (serveurs de base de données et serveurs web) sur plusieurs zones de disponibilité.

Un autre scénario de panne AWS, bien plus grave, est la défaillance simultanée d'une région entière. Ce cas de figure s'est déjà produit à plusieurs reprises. PagerDuty est conçu pour tolérer les pannes dans ce cas également. Nous avons mis en place une sauvegarde à chaud de notre infrastructure complète sur un hébergeur distinct (non Amazon). Dans ce cadre, nous avons développé une procédure de basculement d'urgence qui nous permet de passer rapidement d'AWS à notre hébergeur de sauvegarde.

La panne

Note Tous les horaires mentionnés ci-dessous sont à l'heure du Pacifique.

• À 20h44, nos outils de surveillance ont détecté une panne de l'application PagerDuty .
• À 20h49, l'ingénieur d'astreinte de PagerDuty a été contacté. Ce dernier a constaté qu'il s'agissait d'un incident de niveau 1 et a sollicité l'aide de plusieurs autres ingénieurs.
• À 20h55, il a été décidé de procéder à une bascule d'urgence vers notre fournisseur de sauvegarde (qui n'est pas hébergé sur AWS). Cette décision a été motivée par le fait que l'équipe d'intervention a constaté que la console AWS était hors service, ce qui l'a amenée à penser qu'une bascule vers une zone de disponibilité de sauvegarde serait impossible.
• À 21h14, la migration vers le fournisseur d'hébergement de secours était terminée. Nos systèmes étaient alors pleinement opérationnels, mais soumis à une charge très élevée pour traiter un important arriéré de notifications.
• 21h22 : Le retard important dans le traitement des notifications a été résorbé. À ce moment-là, la charge restait élevée : le traitement des nouvelles notifications prenait 5 à 6 minutes.
• À 10h03, la charge a diminué et nous sommes revenus à la normale, traitant les notifications en quelques secondes.

Ce que nous avons mal fait

Nous ne sommes pas satisfaits du temps qu'il nous a fallu pour effectuer le basculement d'urgence vers notre système de secours (30 minutes). De plus, nous ne sommes pas satisfaits de la manière dont la charge élevée a été gérée après le basculement. Voici la liste complète des problèmes :

1. Nos outils de surveillance ont mis 5 minutes à nous signaler le problème. C'est beaucoup trop long : un délai acceptable se situe entre 1 et 2 minutes.
2. Après avoir constaté qu'il était confronté à un incident critique (niveau 1), l'ingénieur d'astreinte a mis plusieurs minutes à organiser une réunion de groupe avec le reste de l'équipe. Notre procédure de gestion des incidents critiques repose sur Skype pour la mise en place de ces réunions. Or, Skype a planté à plusieurs reprises, entraînant une perte de temps considérable.
3. La manœuvre de retournement d'urgence a duré trop longtemps : 20 minutes. Le guide de retournement est trop verbeux et donc difficile à suivre en situation d'urgence. De plus, certaines personnes qui ont participé au retournement n'avaient jamais effectué cette opération auparavant, ce qui a contribué à rallonger le délai.
4. Après le basculement, nous avons eu du mal à faire fonctionner tous nos processeurs de tâches en arrière-plan à pleine capacité.

Ce que nous avons bien fait

En résumé, nous avons effectué une migration d'urgence de notre centre de données en moins de 30 minutes après la panne, et le processus a fonctionné. Voici la liste des points positifs :

1. Nous avons réagi très rapidement à la panne.
2. Nous avons pris la bonne décision en effectuant une déconnexion d'urgence d'AWS. Cette décision a été prise après avoir constaté que la console AWS était hors service.
3. Nous avons communiqué régulièrement via nos comptes Twitter @pagerduty et @pagerdutyops afin de tenir nos clients informés de la panne. Pour rappel, notre compte Twitter @pagerdutyops est dédié aux notifications d'urgence en cas de panne ; vous pouvez d'ailleurs le configurer pour recevoir des SMS à chaque mise à jour. Pour plus d'informations, consultez… https://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down .
4. Vue d'ensemble : notre système de sauvegarde à chaud redondant, hébergé chez un fournisseur différent (non Amazon), a parfaitement fonctionné. Ce système nous a permis de limiter l'interruption de service à seulement 30 minutes. Sans ce système de sauvegarde, l'interruption aurait pu durer une heure, voire plus.

Que ferons-nous pour éviter que cela ne se reproduise ?

Vue d'ensemble :

Nous procédons à une migration de nos centres de données. Nous quittons AWS US-East pour rejoindre US-West. Cette migration, initialement prévue pour le 19 juin (bien avant la panne), est motivée par le fait que plus de 20 % de nos clients exécutent leurs applications dans la région US-East. Lorsque cette région rencontre des problèmes, nous subissons une perte de capacité et une forte charge de la part de nos clients. En d'autres termes, nos pannes sont directement liées à celles de nos clients. Par conséquent, dès demain, nous migrerons vers US-West. Il convient de préciser que cette panne est survenue au pire moment : nous étions à seulement cinq jours de la migration prévue vers US-West.

À long terme, nous avons constaté deux choses principales :

• Nous ne pouvons faire confiance à aucun fournisseur d'hébergement en particulier.
• Les retournements de situation sont une mauvaise idée : ils entraînent toujours des temps d'arrêt et parfois, ils ne fonctionnent pas.

Par conséquent, nous allons migrer vers une architecture à trois fournisseurs d'hébergement, où le système PagerDuty sera réparti sur trois centres de données (trois dans un premier temps, puis cinq ultérieurement). Nous adoptons également un système de stockage de données distribué et tolérant aux pannes, basé sur Cassandra et multinœud, qui ne nécessite pas de basculement en cas de défaillance d'un centre de données. Ce projet a débuté en décembre dernier et le composant d'envoi de notifications de PagerDuty est déjà opérationnel sur la nouvelle infrastructure.

Détails:

1. Nous envisageons de mettre en place un autre outil de surveillance interne qui alertera le personnel d'astreinte dans un délai de 1 à 2 minutes après la détection d'une panne.
2. Nous allons étudier la possibilité de mettre en place une alternative à Skype pour lancer des appels de groupe afin de résoudre les problèmes critiques. Nous opterons probablement pour une solution de conférence téléphonique fiable, à moins de trouver une meilleure solution (Chers lecteurs, si vous avez des suggestions, n'hésitez pas à les partager dans les commentaires).
3. Nous allons rationaliser la procédure de retournement d'urgence. Dans ce cadre, nous allons condenser le manuel de retournement et le tester rigoureusement. Nous étudierons également la possibilité d'automatiser certaines étapes de la procédure.
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 les notifications. L'objectif est de rétablir rapidement le service après une interruption de service et de gérer les pics de charge.