Faire vos propres Days of Chaos? Par où commencer?

Kriss et moi même avons été sollicités par l’INSEE pour les accompagner dans la mise en place de leurs propres Days of Chaos. Nous allons en profiter pour suivre la construction de cette démarche et vous proposer un modèle pour les mettre en application dans vos propres organisations.

Rappel : le protocole de l’expérimentation

Les ingénieurs du Chaos du Netflix Technology Blog on proposé un protocole pour la mise en place d’expérimentations du Chaos Engineering. Les Days of Chaos sont un gameday qui a été contruit en respectant ce protocole. Même s’il s’agit d’un jeu, un Days of Chaos est une expérimentation de Chaos Engineering s’adressant à l’organisation ciblée.

Tout naturellement nous avons souhaité repartir de ce protocole :

1. Définir quelle est la question/objectif que l’on souhaite poser au système/atteindre
2. Définir le périmètre de l’expérience
3. Identifier précisément la métrologie nécessaire à l’expérience
4. Communiquer : prévenir l’organisation et impliquer les participants potentiels
5. Réaliser l’expérience
6. Analyser les résultats, mettre en place les éventuels plans d’action nécessaires
7. Élargir le scope pour la prochaine expérience

Définir la question / les objectifs

Cette étape est primordiale car elle va orienter la construction des pannes, le recrutement des participants (joueurs et préparateurs) et même la forme du jeu. On peut parler ici de question ou d’objectif : que souhaite-t-on démontrer? Que souhaite-t-on faire apprendre aux participants? Les sensibiliser sur un point en particulier?

La tentation de vouloir couvrir un grand scope est très tentante. Il faut cependant se rappeler la 7ème étape du protocole ci-dessus qui est d’élargir le scope à chaque nouvelle expérience. Rome ne s’est pas construite en un jour, prenez le temps de faire un bon premier exercice, même court, plutôt que de risquer de n’en faire qu’un seul.

Voici une liste non exhaustive d’axes d’attaque pour vos Days of Chaos :

• Améliorer la détection, le diagnostic et la résolution des pannes.
• Sensibiliser au suivi de production.
• Le monitoring en place est-il efficace?
• Former les développeurs à utiliser correctement leur monitoring.
• Favoriser la collaboration inter équipes : intra ops / intra dev / inter dev ops / inter dev ops metier / etc…
• Observer les comportements et le respect des procédures lors d’une simulation de crise.
• Que se passe-t-il si mes experts ne sont plus la? (plus de lead dev, archi, héros, pompiers, sachant)
• Tester la perte d’un data center
• etc…

La seule limite que vous avez est votre imagination et vos besoins. Faites en sorte de coller à l’actualité de votre organisation, c’est un bon tremplin.

Quels ont été les objectifs de nos propres Days of Chaos (DoC)?

DoC 1 : Entrainer les développeurs au suivi de production / Améliorer la détection, diagnostic, résolution des pannes / Renforcer ou créer le lien devops.

DoC 2 : objectif du DoC 1 couplé à une simulation de crise. Ce fut une mauvaise idée car la le premier objectif est sur la base du volontariat et le second non, entrainant une incompréhension pour la partie simulation de crise.

DoC 3 : Tester la réactivité du système sans ses experts. (Format DoC 1 sans les lead dev)

Définir le périmètre

Le périmètre est en grande partie fonction de la question. Il revient en gros à définir les acteurs, les outils et le terrain de jeu.

Public :

• Qui joue : Dev? Ops? Tout le monde?
• Qui organise : une team existante (SRE, Chaos Engineers)? Une team projet? Une direction (Excellence opérationnelle)?
• Qui prépare les épreuves et les déroule : Ops? Lead dev? Expert en gestion de crise?

Environnement :

La pré-production parait l’environnement idéal pour une première session, cependant une production peut aussi faire l’affaire. Utiliser la production dépendra notamment du coût qu’engendrera une éventuelle indisponibilité de tout ou partie de la production. Si elle est à disposition d’un public interne cela posera bien moins de problème que si vous êtes une entreprise de e-commerce où la moindre indisponibilité peut avoir des impacts catastrophiques sur votre chiffre d’affaire!

Applications :

• Toutes les applications : parfait pour une gestion de crise.
• 1 ensemble d’applications interdépendantes : idéal pour s’entrainer sur des pannes ensemblistes et sensibiliser à l’importance des interactions avec les autres équipes. Que faire si je ne détiens qu’une seule pièce du puzzle?
• 1 application : exemple, dans le cadre d’un tournoi ou chaque équipe met en jeu son application.
• 1 application fake : c’est le cas des GameDay AWS qui utilisent l’application Unicorn Rentals. Dans ce cas le but n’est pas la connaissance de l’application mais plutôt des outils qui sont autour (la console EC2 ici).

Les périmètres de nos DoC?

DoC 1 :

Public : Joueurs “Equipes de dev volontaires” / Organisation “direction excellence opérationnelle” / Préparateurs “Ops”

Environnement : Pré-production

Applications : une application de chaque équipe de dev inscrite (qui joue sur sa propre application)

DoC 2 :

Public : Joueurs “Equipes de dev volontaires + tout le monde pour la crise y compris le CODIR” / Organisation “direction excellence opérationnelle” / Préparateurs “Ops”

Environnement : préprodution

Applications : une application de chaque équipe de dev inscrite + un ensemble d’application interdépendantes pour la crise.

DoC 3 :

Public : Joueurs “Equipes de dev volontaires” / Organisation “direction excellence opérationnelle” / Préparateurs “Lead devs”

Environnement : Pré-production

Applications : une application de chaque équipe de dev inscrite

Identifier la métrologie

Fonction du périmètre et en particulier de l’environnement. Si en général les organisations sont bien équipées sur les environnements de prod, les environnements hors prod sont les parents pauvres en particulier du monitoring. Dès lors il convient de vérifier les points suivants :

• Le monitoring existe-t-il dans l’environnement choisi? Si oui, est-il correctement configuré exploitable?
• Est-il accessible pour les joueurs? Les devs n‘ont pas forcément accès à des outils comme centreon ou nagios…
• Les joueurs savent-ils l’exploiter ou même l’utiliser? Si non, mettre en place des kits de survie pour leur permettre de gagner. Un support de formation lui ne sera pas lu… :)

Quel que soit le format de votre Days of Chaos, quel que soit le public ciblé, il faut toujours insister sur l’importance de coupler le monitoring applicatif qui observe les métriques métier et le monitoring technique qui observe l’état des infrastructures. Une infrastructure qui fonctionne bien n’est pas un gage de bon fonctionnement applicatif. Que se passe-t-il si tous les indicateurs techniques sont bon mais qu’on ne réalise plus aucune vente?…Comment s’en apercevoir sans les indicateurs métier?

La métrologie de nos DoC?

DoC 1 : Utilisation des dashboards applicatifs de chaque équipe + apprentissage de l’utilisation de centreon. Beaucoup d’équipes ne disposaient pas de système de monitoring sur le pré-production. Nous avons donc profité de la préparation du jeu pour monter ces systèmes en hors production.

DoC 2 : Dashboards devs optimisés depuis la précédente session de DoC & centreon. Ouverture d’esprit et apprentissage des dashboards des applications directement autour de la leur.

DoC 3 : Scope identique au DoC 2 mais sans l’expert qui en général et celui qui maitrise le mieux le monitoring voir qui l’a mis en place.

La suite au prochain numéro!

Nous voyons bien que les étapes 2 et 3 découlent de manière très importante de la “Question / Objectif”. C’est le point central dont dépendra l’organisation de vos Days of Chaos. Prenez bien le temps de le/les définir! Corriger le tir après coup…ne sera pas évident et impactera énormément ce que vous aurez déjà accompli.

Nous nous pencherons plus en détail sur l’aspect communication dans un prochain article. Ce point en lui même a été une des clés du succès de nos propres sessions et mérite un article dédié.