Faire vos Days of Chaos — Atelier de création de pannes

C’est au cours de notre 5ème meetup dans les locaux de la Société Générale que nous avons proposé aux participants du Paris Chaos Engineering Meetup de prendre part à un atelier de création de pannes. Il s’agit du même que j’ai effectué avec les exploitants de ma société pour préparer les premières sessions de nos Days of Chaos.

Faire des pannes, les plus vraies possibles

Autant le dire tout de suite, faire des pannes valables (plausibles, pertinentes, adaptées au contexte) est plus facile qu’il n’y parait. Il faut cependant ne pas sous estimer l’importance de cette atelier et organiser méticuleusement les sessions de création.

Ce que nous allons voir maintenant, c’est la manière dont nous avons amené nos participants du jour à exprimer leur vécu et leur connaissance du “possible”.

Des pannes ok, mais pour quoi faire?

Faire une bonne panne doit permettre de suivre au moins l’un de ces trois objectifs :

• Faire découvrir un outil, un système, des interactions, etc…
• Faire apprendre, au sens formation.
• Faire prendre conscience d’une situation existante (et souvent d’un manque).

Ainsi la panne de vient un vecteur d’apprentissage au sens large, que ça soit de connaissance ou de transmission d’expérience.

Timeline de l’atelier

Notre temps etait limité à 55 minutes car nous avons participé à un meta-meetup regroupant 3 autres meetups. J’ai d’ailleurs eu la chance de pouvoir assurer la keynote du meta-meetup avec Christophe Rochefolle et donc de pouvoir ramener tous les curieux sur le sujet, augmentant ainsi la diversité de la population participante. La timeline s’est décomposée comme suit :

• 10' : présentation du déroulement de l’atelier et constitution des équipes, nous étions 39 lors de l’atelier ce qui fait des équipes de 9–10 personnes.
• 15' : Première session d’idéation. La consigne est simple et claire “choisissez une panne issue d’un incident sérieux qui vous est déjà arrivée ou que vous savez pouvoir vous arriver”. (voir ci-dessous le template 1)
• 15' : Reformulation de cette panne sous forme d’une expérimentation de Chaos Engineering. (voir ci-dessous le template 2)
• 15' : Explication de la panne par chaque porteur aux autres participants. Cette partie est très importante car elle permet une confrontation des idées et une mise à l’épreuve des objectifs des pannes.

Les templates

Nous avons recyclé les templates initiaux des premiers Days of Chaos que j’ai remis au gout du jour en les séparant en deux fiches :

• Description complète de la panne. Cette fiche doit permettre entre autre de comprendre le contexte de la panne (fonctionnel, temporel, stratégique), son environnement technique (technologies en causes, pratiques adoptées) et les actions prises à la suite de la panne ou qu’il faudrait prendre si la panne est potentielle accompagnées de la résolution.

• Reformulation de cette panne sous forme d’une expérimentation de Chaos Engineering avec un focus sur le but de l’expérimentation, le périmètre impacté, ce qu’il faut mesurer et monitorer, comment injecter le Chaos (qu’on pourrait aussi formuler comment implémenter la panne). Afin d’être complet il convient d’ajouter les réactions attendues du système ainsi que les réactions des humains qui le gèrent et enfin quel est le public ciblé.

Les pannes réalisées

Après une courte phase de démarrage ou il faut re-préciser les objectifs pour qu’ils soient bien assimilés, la créativité des participants est au rendez-vous! Jugez par vous même :

1. Vampire VM. Une VM utilise trop de thread et entraine une saturation qui provoque un effondrement de l’hyperviseur. Cette panne nécessite d’avoir un environnement virtualisé avec hyperviseur et un certain nombre de machines virtuelles dessus. La résolution passe par un isolement de la VM et une reconfiguration de celle-ci pour caper les ressources utilisables. Une résolution a long terme peut être un check des configs des VM avant passage en production.
2. Numeric Alzheimer. Faire un “rm /” sur un NAS qui contient un historique de fichiers importants (ordre de paiement, etc…). Cette panne nécessite d’avoir un stockage de fichiers relativement sensible sur un NAS; en général la redondance des NAS ne “sauve” pas ces fichiers car les outils de réplications fonctionnent en temps réel et la suppression se fait en cascade, souvent il est trop tard quand on s’en aperçoit. Pour résoudre une panne comme celle-ci il faut disposer de sauvegardes “externes” avec un délai de synchronisation différent pour permettre une action de restoration de backup au cas ou (backup de backup). Une autre action peut aussi être de restreindre les actions sur les fichiers comme d’avoir du read-write only sans suppression ni modifications.
3. Crazy Pacemaker. Un monitoring haute disponibilité supprime une VM toutes les minutes pour tenter de la redémarrer sans lui laisser le temps de redémarrer correctement. Dans le cas d’un système de ce type, le gestionnaire de haute disponibilité (Pacemaker, corosync) doit pouvoir vérifier l’état des processus d’une VM, si le redémarrage ne laisse pas le temps au système monitoré de répondre on peut assister à des redémarrages en boucle si pour une raison quelconque le service est trop lent à redémarrer ou rencontre un problème lors du redémarrage. Il faut pouvoir détecter les redémarrages intempestifs pour éviter le problème.
4. Jet-lag. Un défaut de synchronisation NTP entrainant un décalage horaire sur un serveur rend impossible la connexion avec double facteur temporel sur ce serveur. Dans le cadre des authentifications fortes basées sur le temps, la gestion de la synchronisation du temps est primordiale pour permettre l’utilisation du second facteur par l’utilisateur souhaitant se connecter. Il faut pouvoir relancer le démon NTP et monitorer la dernière date de synchronisation du serveur. C’est une panne pernicieuse car “lente” à avoir des impacts, le temps que le décalage de temps se fasse.

La reformulation en expérimentation

Vampire VM.

• But : Vérifier que le système ne s’effondre pas sur une VM mal configurée.
• Périmètre : Un hyperviseur et toutes ses VM.
• A mesurer : le nombre de threads par VM.
• Comment injecter : Créer une VM vampire.
• Réaction système : les autres VM tournent correctement. Une alerte doit aussi être remontée.
• Réaction humaine : pouvoir trouver la VM vampire et identifier la cause (mauvais paramétrage).
• Public ciblé : Ops.

Numeric Alzheimer.

• But : Valider la persistance des données suite a de malencontreuses actions manuelles.
• Périmètre : tout ou partie de la sauvegarde.
• A mesurer : la taille des volumes et les flux I/O.
• Comment injecter : exécuter la commande “rm /” avec un utilisateur standard étant amené à pouvoir intervenir sur le NAS.
• Réaction système : Interdiction de la commande, alerte sur le différentiel rapide de taille des volumes ou sur un emballement inhabituel des IO.
• Réaction humaine : identification de la commande et restauration depuis un autre backup si besoin.
• Public ciblé : Ops.

Crazy Pacemaker.

• But : Valider la détection des actions trop fréquentes sur une VM.
• Périmètre : un groupe de VM en haute disponibilité.
• A mesurer : les logs de créations de VM ainsi que le statut des ressources pacemaker/corosync.
• Comment Injecter : Bloquer un des services monitoré par pacemaker/corosync.
• Réaction système : Détection d’une création/suppression en boucle.
• Réaction humaine : Stopper les actions de pacemaker/corosync, corriger les services en KO.
• Public Ciblé : Ops.

Jet-lag.

• But : Détecter la désynchronisation temporelle et les problèmes de connexion sur un serveur.
• Périmètre : La connexion en authentification forte au serveur ciblé.
• A mesurer : le nombre de connexions, le délai de synchronisation NTP.
• Comment injecter : Au choix en changeant la conf NTP, en coupant la route NTP ou en empêchant le batch NTP de tourner.
• Réaction système : Détection de la chute du nombre de connexion et alerte sur l’absence de synchronisation temporelle.
• Réaction humaine : ouverture d’incident suite a impossibilité de connexion. Validation de la conf NTP.
• Public ciblé : Utilisateurs et Ops.

Et maintenant, que faire de ces pannes?

Nous (Christophe Rochefolle et moi) ça nous a donné envie de les expérimenter chez nous.

Et vous?… ;)