Comme certains d'entre vous le savent, PagerDuty a subi une panne d'une durée totale de 15 minutes ce matin. Nous prenons la fiabilité de nos systèmes très sérieusement, et nous écrivons ceci pour vous donner une divulgation complète de ce qui s'est passé, de ce que nous avons fait de mal, de ce que nous avons fait de bien et de ce que nous faisons pour aider à éviter cela à l'avenir.

Nous tenons également à vous informer que nous sommes sincèrement désolés de cette panne. Nous avons travaillé dur au cours des 6 derniers mois pour repenser nos systèmes afin qu'ils soient totalement tolérants aux pannes. Nous en sommes très proches, mais nous n'y sommes pas encore tout à fait. Lisez la suite pour connaître tous les détails et les mesures que nous prenons pour nous assurer que cela ne se reproduise plus.

Arrière-plan

Les principaux systèmes de PagerDuty sont hébergés sur EC2 d'Amazon Web Services. AWS utilise le concept de « zones de disponibilité » (AZ), dans lesquelles les hôtes sont censés échouer indépendamment des hôtes des autres zones de disponibilité de la même région EC2.

PagerDuty profite de ces zones de disponibilité et s'assure de répartir ses hôtes et ses banques de données sur plusieurs AZ. En cas de panne d'une seule AZ, PagerDuty peut récupérer rapidement en redirigeant très rapidement le trafic vers une AZ survivante.

Cependant, il est assez évident qu'il existe de nombreuses situations dans lesquelles toutes les zones de disponibilité d'une région EC2 donnée échouent en même temps. D'après notre expérience, ces situations se produisent environ tous les 6 mois. Une telle défaillance à l'échelle régionale s'est produite tôt ce matin, au cours de laquelle AWS a subi des problèmes de connectivité Internet dans toute sa région US-East-1 en même temps.

La panne

PagerDuty est devenu inaccessible à 2h27 ce matin.

Sachant que les solutions de repli dans d'autres AZ ne suffisent pas, PagerDuty dispose d'une autre réplique entièrement fonctionnelle de l'intégralité de sa pile fonctionnant dans un autre centre de données (détenu et exploité de manière totalement distincte). Nous avons commencé la procédure pour basculer vers cette réplique après avoir été informés du problème avec EC2 et lorsqu'il est devenu évident qu'EC2 connaissait une panne à l'échelle régionale.

À 2 h 42 (15 minutes après le début de la panne), la région US-East-1 d'EC2 est réapparue et nos systèmes ont commencé à traiter rapidement l'arriéré des événements API et e-mail entrants, créant un grand nombre de notifications sortantes à nos clients. À ce stade, nous avons abandonné le basculement vers notre pile de notifications externes de secours.

Ce que nous avons fait de mal

Quinze minutes semblent être un laps de temps très long entre le moment où notre panne a commencé et celui où nous avons effectué notre saut. Et c'est le cas.

Nous utilisons plusieurs systèmes de surveillance externes pour surveiller PagerDuty et nous alerter tous en cas de problèmes (nous ne pouvons pas utiliser PagerDuty nous-mêmes, hélas !). Après un examen minutieux, les alertes de ces systèmes ont été retardées de quelques minutes. En conséquence, nous avons répondu à la panne avec quelques minutes de retard.

Il s'agit évidemment d'une mesure que nous devons prendre au plus vite. Ces minutes comptent. Nous savons qu'elles sont très importantes pour vous. Nous allons étudier la possibilité de changer ou d'améliorer nos systèmes de surveillance dès que possible.

Une autre erreur de notre part a été de ne pas vous avoir tous immédiatement informés de notre panne via notre système de diffusion de masse d'urgence (voir http://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down ). Cela est dû à un problème de communication interne sur le moment opportun pour utiliser ce système. Nous publierons prochainement un autre article de blog qui détaillera exactement comment nous utiliserons ce système à l'avenir, et vous rappellera comment vous y inscrire.

Ce que nous avons bien fait

Nous avons déjà pris des mesures pour pouvoir atténuer ces événements EC2 à grande échelle lorsqu’ils se produisent.

L’une de ces étapes est l’existence même de notre environnement PagerDuty de secours hébergé en externe. Il s'agit d'une solution (coûteuse) à ce problème rare. Nous organisons régulièrement des exercices d'incendie internes au cours desquels nous testons et pratiquons la procédure de basculement vers cet environnement. Nous allons poursuivre ces exercices.

Une autre mesure que nous avons prise pour atténuer ces événements EC2 à grande échelle consiste à nous assurer que nos systèmes peuvent gérer les volumes de trafic très élevés que nous constatons lorsqu'un tiers de nos clients (tous ceux hébergés sur EC2) tombent en panne en même temps. Nous avons apporté de nombreuses améliorations à nos systèmes au cours des 6 derniers mois : notre système met désormais rapidement en file d'attente les événements, répartit intelligemment la charge dans les scénarios de trafic élevé afin de continuer à fonctionner et s'assure absolument de ne manquer aucun de nos clients. Ces systèmes ont très bien fonctionné ce matin, évitant ainsi de nouveaux retards d'alerte.

Ce que nous allons faire

Un basculement, aussi rapide soit-il, implique des temps d'arrêt. Cela nous laisse un goût amer dans la bouche. Nous travaillons (dur !) sur notre réarchitecture interne pour passer complètement à un système de traitement des notifications qui n'implique AUCUN point de défaillance unique temporaire, même lorsque ce SPOF concerne « l'ensemble de l'EC2 Est ».

Notre nouveau système utilisera un datastore multi-nœuds en cluster déployé sur plusieurs hôtes situés dans plusieurs centres de données indépendants avec différents fournisseurs d'hébergement. Le nouveau système sera capable de survivre à une panne du centre de données sans aucun retournement. C'est vrai, nous allons passer à l'absence de retournement (car le mot « retournement » est synonyme de « panne »). Nous travaillons à plein régime pour construire ce nouveau système et le déployer dès que possible, tout en veillant à rester stables pendant la transition. Cet effort de réingénierie est assez important, alors préparez-vous à quelques solutions à court terme.

Au cours de notre post-mortem interne de ce matin, nous avons identifié quelques domaines dans lesquels nous pouvons immédiatement améliorer la disponibilité de nos points de terminaison d'événements externes. Il s'agit notamment d'améliorer la redondance de notre point de terminaison de messagerie ainsi que de notre point de terminaison d'API. Nous accordons la priorité à ces changements.

Nous étudions également de plus près la possibilité de déplacer nos principaux systèmes hors d'AWS US-East. À court terme, nous continuerons à utiliser US-East dans une certaine mesure (peut-être en tant que fournisseur secondaire). À plus long terme, nous allons complètement déplacer tous nos systèmes critiques hors d'AWS.

Enfin, comme mentionné ci-dessus, nous allons améliorer nos propres systèmes de surveillance. Nous avons eu des alertes envoyées trop lentement par notre propre surveillance Web externe, et nous allons corriger cela dès que possible. Nous allons également améliorer notre procédure de diffusion d'urgence basée sur Twitter, qui nous aide à vous annoncer lorsque nous rencontrons des problèmes internes. Restez à l'écoute pour un autre article de blog sur ce sujet dans les prochains jours.