Comme certains d'entre vous le savent, PagerDuty a subi une panne de 15 minutes ce matin. Nous comptons sur 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 de nos sincères excuses pour cette panne. Nous avons travaillé dur ces six derniers mois pour repenser nos systèmes afin qu'ils soient totalement tolérants aux pannes. Nous sommes très proches du but, mais nous n'y sommes pas encore tout à fait. Poursuivez votre lecture pour connaître tous les détails et les mesures que nous prenons pour que cela ne se reproduise plus.

Arrière-plan

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

PagerDuty exploite ces zones de disponibilité et répartit ses hôtes et ses banques de données sur plusieurs zones de disponibilité. En cas de panne d'une seule zone de disponibilité, PagerDuty peut récupérer rapidement en redirigeant le trafic vers une zone de disponibilité restante.

Cependant, il est évident qu'il existe de nombreuses situations où toutes les zones de disponibilité d'une région EC2 donnée tombent en panne simultanément. D'expérience, ces situations se produisent environ tous les six mois. Une panne régionale de ce type s'est produite tôt ce matin, provoquant des problèmes de connectivité Internet dans toute la région US-East-1 d'AWS.

La panne

PagerDuty est devenu inaccessible à 2h27 ce matin.

Sachant que les solutions de secours dans d'autres zones de disponibilité ne suffisent pas, PagerDuty dispose d'une autre réplique entièrement fonctionnelle de sa pile complète, exécutée dans un autre centre de données (détenu et exploité séparément). Nous avons lancé la procédure de basculement vers cette réplique après avoir été informés du problème avec EC2 et lorsqu'il est devenu évident qu'EC2 subissait une panne 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é d'événements API et e-mail entrants, générant un grand nombre de notifications sortantes pour nos clients. À ce stade, nous avons interrompu le basculement vers notre pile de notifications externes de secours.

Ce que nous avons fait de mal

Quinze minutes, ça paraît long entre le début de notre panne et le moment où nous effectuons notre saut. Et c'est vrai.

Nous utilisons plusieurs systèmes de surveillance externes pour surveiller PagerDuty et nous alerter en cas de problème (nous ne pouvons malheureusement pas utiliser PagerDuty nous-mêmes !). Après un examen attentif, les alertes de ces systèmes ont été retardées de quelques minutes. Par conséquent, nous sommes intervenus avec quelques minutes de retard sur la panne.

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 étudierons 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 notifié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 détaillant précisément comment nous utiliserons ce système à l'avenir et vous rappelant 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 mesures est l'existence même de notre environnement PagerDuty de secours hébergé en externe. Il s'agit d'une solution (onéreuse) à ce problème rare. Nous effectuons régulièrement des exercices internes pour tester et mettre en pratique la procédure de basculement vers cet environnement. Nous poursuivrons ces exercices.

Une autre mesure que nous avons prise pour atténuer ces événements EC2 de grande ampleur consiste à garantir que nos systèmes peuvent gérer le trafic très important observé lorsqu'un tiers de nos clients (tous ceux hébergés sur EC2) sont en panne simultanément. Nous avons apporté de nombreuses améliorations à nos systèmes au cours des six derniers mois : notre système met désormais rapidement les événements en file d'attente, déleste intelligemment la charge en cas de trafic élevé afin de maintenir son fonctionnement, et veille à ce que nos clients ne manquent jamais de recevoir des alertes. Ces systèmes ont très bien fonctionné ce matin, évitant ainsi de nouveaux retards d'alerte.

Ce que nous allons faire

Un changement, aussi rapide soit-il, implique des temps d'arrêt. Cela nous laisse un goût amer. Nous travaillons (d'arrache-pied !) à la réarchitecture interne afin de migrer vers 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 d'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, chez différents hébergeurs. Le nouveau système sera capable de résister à une panne de centre de données sans aucun basculement. En effet, nous allons passer au sans basculement (car le mot « basculement » est synonyme de « panne »). Nous travaillons d'arrache-pied à la construction de ce nouveau système et à son déploiement dans les meilleurs délais, tout en veillant à sa stabilité pendant la transition. Cette restructuration est assez importante ; attendez-vous donc à quelques solutions à court terme.

Lors de notre analyse interne de ce matin, nous avons identifié quelques points sur 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 nos points de terminaison de messagerie et d'API. Nous priorisons ces changements.

Nous étudions également de plus près la possibilité de transférer nos principaux systèmes hors d'AWS US-East. À court terme, nous continuerons d'utiliser US-East dans une certaine mesure (peut-être comme fournisseur secondaire). À plus long terme, nous transférerons tous nos systèmes critiques hors d'AWS.

Enfin, comme mentionné précédemment, nous améliorerons nos propres systèmes de surveillance. Les alertes de notre surveillance web externe sont trop lentes à se transmettre, et nous corrigerons ce problème au plus vite. Nous améliorerons également notre procédure de diffusion d'urgence sur Twitter, qui nous permet de vous informer en cas de problème interne. Restez à l'écoute pour un prochain article à ce sujet dans les prochains jours.