Ingénierie du Chaos — Comment Commencer? — Partie 2 : Choisir ses expérimentations
Vous êtes résilient, ou tout du moins vous en êtes convaincu? Vous avez suffisamment confiance en vous? Vos équipes sont au point?
L’expérimentation en production sera pour vous le moyen de prouver que tout ce que vous avez mis en place fonctionne.
Vous de ne devriez pas avoir de problème pour “mettre au défi” vos équipes de subir un Chaos Monkey. Ce sont même peut-être elles qui viendront vous trouver pour mettre leurs efforts à l’épreuve!
Les principales pistes
S’il est le plus connu, le Chaos Monkey n’est pas la seule expérimentation du Chaos Engineering. Vous trouverez dans l’article suivant un bon résumé des principales “cibles” d’expérimentations proposé par les Gremlins : 4 Chaos experiments to start with. Cet article est assez court et je vous recommande de lire même s’il est en anglais :). Ces expérimentations pourraient même être suffisantes à l’ensemble de votre démarche. En résumé :
- La consommation excessive d’une ressource. Consiste à réduire la disponibilité d’une ressource système (cpu, mémoire, disque, etc…) soit en baissant le quota de la ressource, soit en la consommant de manière artificielle.
- Les perturbations réseau. Véritable fibre nerveuse de nos SI, que ce se passera-t-il en cas d’engorgement réseau ou de messages tronqués voir incohérents? Les protocoles de base sont l’ajout de latence et la suppression de chemin vers une ressource externe.
- L’utilisation excessive des bases de données. Saturer les accès, ajouter de la latence sur chaque requête, faire disparaitre la base, “quand la mémoire est inaccessible” c’est un peu l’équivalent de la maladie d’Alzeimer pour vos applications.
- La panne DNS. On l’oublie souvent mais sans référencement et sans backup du référencement c’est tout le système qui disparait. C’est encore plus problématique quand les services sont exposés à l’externe. Souvenez-vous des impacts des pannes DNS mondiaux sur la disponibilité des grands site.
Un bon point de départ
Avant de vous lancer dans votre choix, je vous conseille très fortement de vous concentrer dans un premier temps sur le Chaos monkey (ou l’expérimentation de la défaillance d’une instance).
En effet, connu et compris de tous, tout en jouissant de sa réputation, il permet à chacun de s’habituer à l’injection de Chaos en production. Il permet entre autre d’ancrer la démarche du Chaos Enginnering dans l’entreprise en servant d’exemple simple.
Le Chaos Monkey est une valeur sûre pour commencer.
Étendre l’adhésion plutôt que la couverture des expérimentations
Une démarche globale et partagée par le maximum d’équipes est plus importante que d’avoir une ou deux applications en mode “blockbuster”. C’est la résilience globale du système que l’on souhaite accroitre.
La résistance d’une chaine est égale à la résistance de son maillon le plus faible.
La démarche globale apportera aussi une cohérence des efforts apportés à la résilience sans compter les “a côté”. Par exemple la mise en place de solutions transverses pourra entrainer un effet de dé-silotage des équipes en les faisant travailler ensemble à résoudre un problème plutôt que de le faire chacune dans leur coin.
Rapidement vous identifierez quelles sont les équipes les plus motrices. Vous pourrez alors leur proposer d’aller plus loin et de choisir elles même leurs futures expérimentations. Ce point est très important car les équipes sont les plus à même de connaître leurs limites et leurs faiblesses. Ce sont elles qui ont fait les impasses ou accumulé de la dette technique : ce sont donc elles qui sont les plus à même de faire leurs choix.
Au final?
Au final, c’est aux équipes de choisir les expérimentations qui leur conviennent. Débuter d’abord avec un spectre réduit et avec le temps et la pratique l’étoffer de nouvelles pratiques. Bien entendu, il faut les accompagner dans les réflexions et les décisions. Pour cela elle doivent à tout prix avoir bien compris la démarche et y avoir adhéré.
Aller à la partie 3: Expliquer et faire partager la démarche >>>
