Comme vous le savez peut-être déjà, PagerDuty a subi une panne de 30 minutes hier, suivie d'une période de délais de livraison d'alertes plus longs. Nous prenons cette interruption très au sérieux, d'autant plus qu'elle coïncidait avec des interruptions de service auxquelles beaucoup de nos clients étaient confrontés.

Veuillez comprendre que nous n'essayons pas de rejeter la faute sur d'autres parties, mais une partie de nos processus consiste à comprendre tout temps d'arrêt grave et à y faire face ouvertement.

Ce qui s'est passé : la panne

PagerDuty est actuellement hébergé sur Amazon Web Services (AWS) Cluster de calcul élastique (EC2). L'une des fonctionnalités les plus attrayantes d'AWS est la « zone de disponibilité ». Il s'agit d'« emplacements distincts conçus pour être isolés des pannes dans d'autres zones de disponibilité et pour fournir une connectivité réseau peu coûteuse et à faible latence aux autres zones de disponibilité de la même région ».

Comme de nombreuses applications à haute disponibilité, PagerDuty utilise plusieurs zones de disponibilité pour protéger notre application contre les pannes au niveau du centre de données. Les réseaux inter-AZ à haut débit d'AWS nous permettent de répliquer de manière synchrone chaque événement, notification et incident que nous traitons vers au moins deux emplacements physiquement distincts. Dans des circonstances normales, en cas de panne à l'échelle d'une AZ (c'est-à-dire d'un centre de données), nous sommes en mesure de rediriger tout le trafic vers l'une des AZ survivantes dans les 60 secondes sans aucune perte d'événements entrants.

Malheureusement, hier, le système n'a pas fonctionné comme prévu. Nous attendons avec impatience de lire l'autopsie officielle d'AWS, mais notre propre enquête indique qu'au moins trois AZ nominalement indépendantes de l'US-East-1 ont toutes été simultanément déconnectées d'Internet pendant 30 minutes. Nous n'avions donc aucun matériel pour accepter les événements entrants, ni pour envoyer des notifications pour les événements que nous avions déjà reçus.

Ce qui s'est passé : les conséquences

La panne d'EC2 à l'échelle régionale a eu un impact sur une grande partie de nos clients. Une fois la connectivité rétablie, nous avons reçu une charge extrêmement élevée d'événements et d'e-mails entrants, et notre infrastructure (seulement semi-rétablie) n'a pas été en mesure de traiter le backlog assez rapidement. La charge a également révélé certains problèmes liés aux performances au sein de notre système de répartition des notifications. À l'avenir, notre infrastructure de test de charge testera un scénario dans lequel nous sommes confrontés à un niveau et à une distribution de trafic similaires.

Prévention : Plans immédiats

Nous nous efforçons de garantir que PagerDuty envoie chaque alerte dans les 3 minutes suivant la date de livraison prévue. Une panne de 30 minutes à l'échelle du système est évidemment totalement inacceptable. Nous avons déjà pris les mesures suivantes pour garantir qu'un événement similaire à l'échelle régionale ne provoque pas de panne prolongée :

1. Nous avons déployé une réplique de l'intégralité de notre pile sur un autre fournisseur d'hébergement. En cas de défaillance similaire d'AWS, nous basculerons nos entrées DNS vers la pile alternative et poursuivrons le traitement là où nous nous sommes arrêtés. Bien que le processus de basculement ne soit pas aussi rapide ou transparent que possible avec la fonctionnalité IP élastique d'AWS, cette pile alternative nous offre un niveau de redondance que nous ne pouvons pas atteindre en utilisant AWS seul.
2. Nous avons doublé notre capacité front-end. Malheureusement, PagerDuty a une charge intrinsèquement très variable. Lorsqu'un fournisseur d'hébergement majeur subit une panne, une grande partie de notre clientèle doit être alertée simultanément. Nous pouvons donc passer d'un système largement sous-dimensionné à un système gravement sous-approvisionné en quelques instants. Nous avons quelques réflexions sur la meilleure façon de résoudre ce problème à l'avenir, mais pour l'instant, nous avons ajouté davantage de capacité inactive à notre système pour gérer la charge potentielle supplémentaire.

Prévention : projets d'avenir

Au cours des prochains mois, nous prévoyons d’apporter un certain nombre d’améliorations supplémentaires à notre infrastructure. Ces changements réduiront encore davantage le risque d’une panne à l’échelle du système.

1. Nous avons l'intention d'arrêter complètement AWS EC2. Une très grande partie de notre clientèle héberge ses services sur AWS. Cela crée une situation de défaillance corrélée dangereuse où les périodes pendant lesquelles notre charge est susceptible d'être anormalement élevée sont également susceptibles d'être des périodes où nous rencontrons nous-mêmes des problèmes opérationnels. Même lorsqu'une défaillance est limitée à une seule zone de disponibilité, cela crée des problèmes, car cela nous fait perdre une capacité redondante au moment où nous en avons le plus besoin.
2. Nous allons héberger PagerDuty chez plusieurs fournisseurs. Il est tentant d'utiliser un seul fournisseur d'hébergement avec plusieurs centres de données : il est beaucoup plus facile d'écrire une application distribuée avec des outils tels que des adresses IP virtuelles qui peuvent être migrées d'un centre de données à un autre. Mais, à notre avis, le couplage des défaillances que ces fonctionnalités introduisent dans l'environnement ne vaut pas le risque. Lorsque vous utilisez plusieurs fournisseurs d'hébergement, le risque de points de défaillance uniques est beaucoup plus faible.
3. Nous allons provisionner et tester en partant du principe qu'à tout moment, nous pourrions avoir besoin d'alerter 33 % de nos clients en 5 minutes. Cela nous permettra de faire face à des scénarios de « tempête parfaite » où une panne au niveau du fournisseur déclenche des pannes sur une très grande partie de notre base de clients. Par le passé, nos tests de charge se concentraient sur de fortes rafales de trafic provenant d'un nombre réduit de clients. Nous prendrons également des mesures pour garantir que nos systèmes de mise en file d'attente des événements et de répartition des notifications se dégradent progressivement dans les scénarios de surcharge.

Réponse d'urgence

Un autre problème mis en évidence par la panne d'hier est que nous n'avions aucun moyen efficace d'alerter nos clients qu'il y avait une interruption dans la couverture de PagerDuty. Bien que nous ayons bien évidemment l'intention d'empêcher qu'une telle interruption ne se reproduise, nous pensons qu'il est important de prévoir toutes les éventualités.

À cette fin, nous avons créé un compte Twitter sur lequel nous annoncerons uniquement les interruptions de service de PagerDuty . En abonnant votre téléphone portable à ce flux Twitter, vous serez averti chaque fois qu'il y aura une interruption de service de votre service PagerDuty . Pour en savoir plus sur la façon de configurer cela, veuillez consulter notre article de blog précédent .

De plus, nous avons l'intention de créer une fonction personnalisée permettant aux utilisateurs de s'abonner pour recevoir des alertes téléphoniques si PagerDuty subit une autre panne à l'échelle du système. Naturellement, nous avons l'intention de ne jamais avoir besoin d'utiliser ce système. Cependant, nous voulons nous assurer que nous disposons d'un moyen d'avertir rapidement les clients intéressés de toute interruption de leur couverture PagerDuty . Bien entendu, nous veillerons à ce que ce système d'urgence ne partage aucune dépendance avec notre principal service de répartition des notifications.

Conclusions

Il va sans dire que nous sommes désolés de vous avoir laissé tomber. Nous avons déjà pris plusieurs mesures pour garantir que cela ne se reproduise plus, et nous en prendrons d'autres dans les semaines à venir.

N'hésitez pas à nous contacter si vous avez des questions ou des préoccupations. Nous espérons regagner votre confiance.