Les 24, 25 et 26 janvier 2013, PagerDuty a subi plusieurs pannes. L'API d'événements, utilisée par nos clients pour soumettre des événements de surveillance dans PagerDuty à partir des outils de surveillance, était en panne pendant les pannes. Notre application Web, utilisée pour accéder et configurer les comptes clients, a également été affectée et pourrait avoir été indisponible pendant les pannes.

Nous avons rédigé ce rapport d'autopsie pour vous informer de ce qui s'est passé et pour vous informer également des mesures que nous prenons pour garantir que cela ne se reproduise plus jamais. Enfin, nous tenons à nous excuser pour cette panne. Bien que nous n'ayons pas eu une seule panne prolongée au cours de cette période, nous croyons fermement au mantra selon lequel même 2 minutes d'indisponibilité sont inacceptables et nous tenons à vous faire savoir que nous travaillons dur pour améliorer notre disponibilité, à court et à long terme.

Arrière-plan

L'infrastructure PagerDuty est hébergée dans plusieurs centres de données (DC). Le composant d'envoi de notifications de PagerDuty est entièrement redondant sur 3 DC et peut survivre à une panne de DC sans aucun temps d'arrêt. Nous avons conçu le système pour utiliser un magasin de données distribué qui ne nécessite aucune sorte de basculement ou de retournement lorsqu'un contrôleur de domaine entier est hors ligne.

Cependant, l'API des événements, qui s'appuie sur un système de file d'attente, repose toujours sur notre ancien système de base de données hérité, basé sur un SGBDR traditionnel. Ce système dispose d'une base de données principale qui est répliquée de manière synchrone sur un hôte secondaire. Le système dispose également d'une base de données tertiaire qui est répliquée de manière asynchrone (au cas où la base principale et la base secondaire rencontreraient des problèmes). Si l'hôte principal tombe en panne, notre procédure d'exploitation standard consiste à effectuer un basculement vers l'hôte secondaire. L'inconvénient est que le processus de basculement nécessite quelques minutes d'indisponibilité.

Détails de la panne

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

Le 24 janvier

• À 8h25, l'API des événements et le site Web sont tous deux tombés en panne.
• A 8h25, les ingénieurs d'astreinte de PagerDuty sont alertés.
• À 8h32, nous avons commencé une conférence téléphonique de gravité 1.
• À 8h36, nous avons commencé le processus de basculement de la base de données principale vers la base de données secondaire.
• À 8h41, le processus de retournement était terminé.
• À 8h42, l'API et le site Web des événements ont été remis en ligne.

Plus tard dans la journée, nous avons eu plusieurs problèmes :

• À 16h16 : petit problème – coupure de courant d'une minute
• À 22h37 : petit problème – coupure de courant d'une minute
• À 22h51 : petit problème – panne de courant d'une minute

Tout au long de la journée, nous avons travaillé sur l'enquête concernant le problème et sur l'autopsie. Dans le cadre de l'enquête, nous avons remarqué un grand nombre d'invocations d'une requête lente particulière sur la base de données. Nous avons modifié le code pour désactiver l'invocation de la requête incriminée. À ce stade, nous avons pensé que les pannes étaient causées par une seule requête lente, que nous avions corrigée, et nous avons donc pensé que le problème sous-jacent était également résolu.

Le 25/01

• À 7h05 : petit problème – coupure de courant de 3 minutes

Nous avons enquêté sur la nouvelle panne et avons trouvé une autre requête lente problématique, que nous avons résolue immédiatement.

Le 26/01

• À 2h28 du matin, l'API des événements et le site Web sont tombés en panne.
• À 2h28 du matin, les ingénieurs de garde ont été appelés.
• À 2h38 du matin, l'API des événements et le site Web ont été rétablis.

À ce stade, nous sommes arrivés à la conclusion que la meilleure chose à faire était de mettre à niveau la machine de base de données vers un hôte plus grand. Les ingénieurs ont travaillé toute la nuit pour construire toutes les nouvelles machines de base de données (primaire, secondaire et tertiaire) sur un meilleur matériel.

Vers 6 heures du matin, nous pensions que la construction des nouvelles machines était terminée. De 6 h 15 à 9 h 14, nous avons tenté de transférer la base de données vers une nouvelle machine principale à plusieurs reprises, sans succès à chaque fois. Chacune de ces tentatives a entraîné quelques minutes d'indisponibilité.

À ce stade, nous avons abandonné l'idée de passer à la nouvelle machine. La raison pour laquelle le changement n'a pas fonctionné est que l'instantané des données sur la nouvelle machine n'a pas été téléchargé correctement, car les ingénieurs étaient extrêmement fatigués et épuisés après avoir travaillé toute la nuit sur les mises à niveau.

Après s'être reposés pendant environ 12 heures, les ingénieurs ont commencé à construire de nouvelles machines de base de données à partir de zéro. Les ingénieurs fraîchement reposés ont mis en place une nouvelle base de données primaire. Quelques heures plus tard, ils ont également installé une base de données secondaire mise à niveau et une base de données tertiaire mise à niveau.

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

Court terme

Nous allons mettre en place une surveillance rigoureuse des requêtes lentes sur notre base de données [déjà fait]. Nous allons également automatiser la construction d'un nouveau serveur de base de données via chef. Le serveur de base de données a été l'un des derniers composants à être géré par chef dans notre infrastructure, et les 26 et 27 janvier, nous avons reconstruit les machines de base de données à la main au lieu d'utiliser chef, ce qui était un processus long et sujet aux erreurs.

Nous allons également mettre en place un processus de développement plus rigoureux, dans lequel les nouvelles fonctionnalités et les modifications apportées à la base de code doivent être examinées en termes de performances de la base de données dans le cadre du processus de révision du code régulier [déjà effectué].

Nous allons également mettre en place de meilleures mesures d'hôte pour le serveur de base de données afin que nous puissions détecter rapidement si et quand nous approchons de la capacité et mettre à niveau le serveur de manière ordonnée.

Long terme

Nous allons supprimer la dépendance de notre API d'événements de notre base de données SGBDR principale. Pour donner un peu plus de contexte, notre API d'événements est soutenue par une file d'attente : les événements entrants sont mis en file d'attente et les travailleurs en arrière-plan traitent les événements en file d'attente. La raison en est que nous pouvons gérer et traiter correctement de gros volumes de trafic d'événements.

Actuellement, cette file d'attente dépend de notre base de données SQL principale. Comme expliqué ci-dessus, cette base de données est entièrement redondante avec 2 sauvegardes sur 2 centres de données, mais nécessite un basculement lorsque la base de données principale (primaire) tombe en panne.

À la suite de cette analyse rétrospective, nous allons accélérer un projet visant à réorganiser la file d'attente et les workers de l'API des événements afin d'utiliser notre nouveau magasin de données distribué. Ce magasin de données est réparti sur 5 nœuds et 3 centres de données indépendants, et il est conçu pour survivre à la panne d'un centre de données entier sans nécessiter de processus de basculement et sans aucun temps d'arrêt.