En tant que membre de l'équipe d'ingénierie en temps réel de PagerDuty, notre principale préoccupation 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 connu 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 ce que nous faisons pour nous assurer que cela ne se reproduise plus.

Impact

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

En raison de ce problème, certains de nos processus de travail de sauvegarde ont démarré automatiquement. Les processus de travail de sauvegarde gèrent l'envoi de notifications à partir de nos différentes files d'attente de notifications, en particulier pour compenser 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. Par conséquent, le traitement de certaines notifications a été retardé. Au cours de la période de panne, 7 % du total des alertes sortantes ont été retardées d'un temps inacceptable. Toutes les notifications ont finalement été envoyées et aucune notification 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 résolvons ce problème

Le bug que nous avons rencontré lors de cette panne particulière a été corrigé. Bien que nous testions l'ensemble de notre code de manière approfondie, ce bug particulier n'a pas été détecté. Étant donné que ce chemin de code ne devient critique qu'en cas de panne du centre de données, nous n'avons pas pu détecter le problème avant qu'il ne se révèle dans notre environnement de production.

Nous allons améliorer nos tests de code qui s'exécutent dans des situations exceptionnelles. Concevoir des systèmes capables de gérer les pannes des centres de données ne suffit pas : nous devons continuellement 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 de cas de défaillance. Nous allons très bientôt instaurer un « vendredi de défaillance » régulier, au cours duquel nous essayons activement de déclencher un ensemble complet de défaillances contrôlées. Au fil du temps, nous espérons passer à l'utilisation de notre propre Singe du chaos qui créera ces conditions de manière continue et aléatoire.