En tant que membre de l'équipe d'ingénierie temps réel de PagerDuty, notre priorité est de concevoir et de mettre en œuvre nos systèmes avec une disponibilité et une fiabilité élevées. Le 30 mai 2013, nous avons subi une brève panne qui a entraîné une dégradation de la fiabilité de nos alertes. Cet article résume ce qui s'est passé et les mesures que nous prenons pour éviter que cela ne se reproduise.

Impact

Le 30 mai 2013 à 22h50 UTC, nos ingénieurs d'astreinte ont été alertés d'un problème dans le centre de données Linode de Fremont. Ce centre de données présentait des problèmes de latence réseau, comme l'a confirmé Linode sur sa page d'état environ 6 minutes plus tard.

Suite à ce problème, certains de nos processus de sauvegarde ont démarré automatiquement. Ces processus gèrent l'envoi des notifications depuis nos différentes files d'attente, notamment pour pallier le retard des travailleurs hors ligne.

Malheureusement, ces processus ont connu une mauvaise gestion des erreurs. En raison de la panne du centre de données, les taux d'erreur étaient bien sûr plus élevés que la normale, ce qui a retardé le traitement de certaines notifications. Pendant la période de panne, 7 % du total des alertes sortantes ont subi un retard inacceptable. Toutes les notifications ont finalement été transmises et aucune n'a été perdue.

Chronologie

• À 22h50 UTC, nos ingénieurs d'astreinte sont alertés de problèmes de connectivité réseau dans le centre de données Linode Fremont.
• À 22h56 UTC, Linode confirme des problèmes de connectivité réseau dans son centre de données de Fremont.
• À 23h07 UTC, nos ingénieurs remarquent que le traitement des tâches de sauvegarde sur l'une de nos files d'attente de notification est bloqué. Ce processus est donc redémarré manuellement.
• À 23h14 UTC, le traitement des notifications est revenu à la normale.
• À 23h30 UTC, Linode confirme que les problèmes de connectivité réseau sont résolus.

Comment nous y remédions

Le bug rencontré lors de cette panne a été corrigé. Bien que nous testions minutieusement l'ensemble de notre code, ce bug n'a pas été détecté. Ce chemin de code ne devenant critique qu'en cas de panne du centre de données, nous n'avons pu détecter le problème qu'au moment où il se manifeste dans notre environnement de production.

Nous allons améliorer nos tests de code exécuté dans des situations exceptionnelles. Concevoir des systèmes capables de gérer les pannes des centres de données ne suffit pas : nous devons constamment vérifier qu'ils fonctionnent comme prévu.

Bien que nous effectuions des tests de défaillance contrôlés en production, nous ne le faisons pas assez souvent et ne testons pas suffisamment les cas de défaillance. Nous allons bientôt mettre en place un « Vendredi des Défaillances » régulier, au cours duquel nous nous efforcerons activement de déclencher un vaste ensemble de défaillances contrôlées. Nous espérons progressivement utiliser nos propres tests. Singe du Chaos qui créera ces conditions de manière continue et aléatoire.