Le 28 juin 2017, nous avons célébré quatre ans de représentations de « Vendredis de l'échec Chez PagerDuty, nous organisons des « Vendredis de la défaillance ». Pour rappel, ces vendredis sont une pratique PagerDuty qui consiste à introduire des pannes dans notre environnement de production de manière contrôlée, sans impact pour nos clients. Ils nous permettent de valider nos efforts en matière d'ingénierie de la résilience.

Au fil des ans, notre processus a évolué, suivant parfois Ingénierie du chaos Des principes, parfois non. Mais l'objectif constant du « Vendredi des échecs » a toujours été de nous aider à identifier et à résoudre les problèmes avant qu'ils n'affectent nos clients. Voici quelques étapes clés de notre parcours et quelques leçons que nous en avons tirées :

Chronologie

2013

• Juin : Le premier vendredi de l'échec !

2014

• Février Notre premier « Failure Friday » axé sur la sécurité. Au lieu de tester la résilience d'un seul service en cas de panne (isolation, redémarrages, etc.), nous avons testé divers cas limites, comme l'envoi de données invalides aux API ou une mauvaise configuration du pare-feu. Cette pratique est toujours en vigueur : certains « Failure Friday » sont réservés non pas à l'injection de pannes sur un seul service, mais à la détection d'anti-modèles à l'échelle de l'infrastructure.
• Avril Moins d'un an après le lancement des « Vendredis de l'échec », nous avons simulé la défaillance complète de l'un des sept systèmes différents. Zones de disponibilité Notre infrastructure fonctionnait ainsi à l'époque. La première fois, nous avons un peu exagéré notre paranoïa et simulé la situation méticuleusement pendant quatre sessions distinctes. Maintenant, une seule session suffit généralement.

2015

• Janvier Après 18 mois et 33 sessions, nous avons enfin automatisé une grande partie des commandes manuelles de l'article original « Failure Friday ». Basé sur le ChatOps outils. En réalisant les étapes manuellement au départ, nous avons pu les valider et en tirer des enseignements sans y consacrer trop de temps initialement. À mesure que notre entreprise grandissait, l'intégration des nouveaux employés devenait de plus en plus difficile ; nous avons donc fait appel à notre chatbot :

• Janvier Une fois que nous nous sommes habitués à l'idée de perdre une seule zone de disponibilité, nous sommes passés à la vitesse supérieure en en supprimant une entière. Région Ces exercices nous prennent généralement encore quelques séances à réaliser, car ils nous apportent toujours de nouveaux apprentissages.
• Mars Nous avons réalisé que les Vendredis de l'échec étaient une excellente occasion de faire de l'exercice notre processus de réponse aux incidents Nous avons donc commencé à l'utiliser comme terrain d'entraînement pour nos nouveaux commandants d'intervention avant même qu'ils n'obtiennent leur diplôme.
• Peut À mesure que nous augmentions le nombre de services et d'équipes assurant leur maintenance, nous avons commencé à formaliser davantage la documentation relative aux pannes planifiées, aux listes de contrôle pour les sessions futures, aux résultats des injections de pannes, etc. « Ce n'est pas de la science si ce n'est pas écrit. »

2016

• Avril Une année de plus s'est écoulée, et avec une nouvelle série de tests de défaillance à grande échelle (Failure Friday), nous avons commencé à simuler le basculement vers notre infrastructure de reprise après sinistre. En temps normal, nous validons nos outils de reprise après sinistre avec un faible pourcentage du trafic réel, mais lors de ces scénarios, nous augmentons progressivement ce pourcentage, en veillant à ne pas impacter nos clients.
• Juin Nous avons introduit « Reboot Roulette » dans notre suite d’automatisation, sélectionnant au hasard des hôtes (avec une pondération pour différentes catégories d’hôtes) auxquels injecter une panne (le redémarrage était la première panne parmi plusieurs ajoutées, à cause de l’allitération bien sûr).

• Septembre : Lors d'une journée de hackathon, Chaos Cat est introduit , en utilisant tous les outils existants pour automatiser l'injection de défauts (à un moment différent de notre fenêtre habituelle de « Failure Friday »).

2017

• Juillet Nous avons formé une guilde interne d'ingénieurs au sein de PagerDuty, répartie dans plusieurs équipes, tous intéressés par l'ingénierie du chaos.

Statistiques

En consultant nos archives du « Vendredi des échecs », voici quelques indicateurs du 28 juin 2013 au 28 juin 2017 :

• Séances du vendredi de l'échec : 121
• Plus de 200 tickets ont été créés pour corriger les problèmes identifiés lors du « Failure Friday ».
• Défauts injectés : 644
• Injections de défauts ayant donné lieu à une autopsie publique : 3
• Nombre de pannes complètes simulées de zones de disponibilité (désactivation de tous les services dans une zone de disponibilité donnée) : 4
• Simulation de pannes complètes de région (désactivation de tous les services dans une région donnée) : 3
• Reprise partielle simulée après sinistre (déviation de tout le trafic vers une autre région) : 2
• Services distincts au sein de PagerDuty ayant subi des injections de défauts : 47

Conclusions

L'introduction de l'échec et l'amélioration continue de notre infrastructure nous ont non seulement permis de fournir de meilleurs logiciels, mais aussi de renforcer la confiance et l'empathie en interne. Les tests de résistance de nos systèmes et processus nous aident à comprendre comment améliorer nos opérations. Vous pouvez le faire aussi. .