Le Chaos engineering est une discipline d’ingénierie qui va tester la robustesse de vos infrastructures et applications. C’est une discipline qui a été popularisée par Netflix en 2011 qui commence également à se populariser en France.
Voici d’ailleurs la définition de Netflix sur le Chaos engineering :
Le Chaos Engineering est la discipline de l’expérimentation sur un système afin de renforcer la confiance dans la capacité du système
résister aux turbulences de la production.
La pratique la plus utilisée dans le chaos engineering est le Chaos Monkey sur lequel j’avais déjà fait un article dans le passé.
Article : Qu’est-ce que le Chaos monkey ?
Le Chaos engineering
Cette discipline a pour but d’amener les équipes techniques à mettre en place des systèmes qui assurent une résilience presque parfaite. Rien est parfait, mais si le système est capable de subir des pannes de toute nature mais que le service fonctionne toujours, cela permettra d’offrir un service de très grande qualité à vos utilisateurs.
Avec l’utilisation de plus en plus massive du cloud, des conteneurs et d’orchestrateurs de conteneurs, il peut s’avérer très complexe de mettre en place des systèmes d’une grande résilience… Et pourtant ce sont ces mêmes outils qui permettent d’obtenir une résilience haut de gamme.
Les tests classiques
Les équipes ont l’habitude de tester la non regression de leurs applications sur des environnements dédiés. Il existe une représentation relativement connue qui se nomme la pyramide des tests (il en existe plusieurs versions) :
Mais si cela permet de consolider la résilience des applications, ces tests ne vont pas pour autant offrir une résilience des systèmes et des infrastructures qui sont autour.
Certains y ajoutent également des tests de charges ou des tests de tolérances sur des environnements de recettes pour assurer un minimum de solidité de l’application dans sa globalité et du système qui l’entoure.
Cependant, cela n’est pas suffisant…
Plus loin dans nos tests avec le Chaos engineering
Alors qu’il était conseillé depuis des dizaines d’années de ne jamais faire des tests sur les environnements de production, la discipline du chaos engineering recommande l’inverse… Seule la production peut nous fournir de vraies informations sur la résilience du système dans sa globalité.
En effet, bien que de nombreux outils comme le cloud et les conteneurs permettent de rapprocher les environnements de recette et de production, il y aura toujours une différence :
- peu d’utilisateurs
- des mises à jour de données moins fréquentes
Expérimentons nos tests en production
Avec le Chaos engineering, nous allons tester la résilience de l’ensemble du système, de l’infrastructure et des applications directement en production avec des concepts de pannes aléatoires.
Grâce à ces tests, nous pourrons également découvrir de nouvelles failles que nous n’avions pas encore découvert ; nous pourrons alors solidifier l’ensemble de notre système d’information.
Mise en application du Chaos engineering
Voici les étapes clés pour mettre en place cette discipline :
Etape 1
définir un état stable avec des mesures viables représentant cet état stable :
- débit global du système
- les taux d’erreur
- les percentiles de latence
- …
Cette mesure doit se faire sur un lapse de temps et non à un moment T afin de s’assurer des mesures réalisées.
Etape 2
Définir des évènements variables qui peuvent arriver en temps normal en hiérarchisant par impact potentiel ou fréquence estimée. Voici le type d’évènements que nous pouvons imaginer :
- panne de serveurs (ou d’un composant)
- pic de trafic
- reboot d’une application
- redémarrage d’un serveur
Nous allons regrouper tous les évènements qui pourraient venir perturber l’ensemble du système en place. L’objectif premier est de découvrir les conséquences de certains évènements et de trouver des solutions pour ne plus les revivre plus tard.
Etape 3
Il faut automatiser les évènements mais également les rendre aléatoire. L’enchainement d’évènements aléatoirement peuvent faire apparaitre des failles jamais découvertes.
L’ingénieur du chaos devra faire très attention à ce que les utilisateurs ne soient jamais impacté.
Technique du chaos engineering
Il existe à présent différents outils qui vont provoquer des évènements différents qui font parti de la suite Simian Army pour faire du Chaos engineering créée par Netflix comme :
- Chaos Kong : fait tomber une région complète sur Amazon
- Chaos Gorilla : fait tomber une zone complète de disponibilité d’Amazon
- Janitor Monkey : met hors service les instances non utilisées
- Chaos Monkey : met des instances en arrêt (technique la plus connue du Chaos engineering)
- Latency Monkey : ajoute des délais supplémentaires au niveau des couches de communication ou coupure complète
- Doctor Monkey : détecte les instances en surcharges et les écarte pour les analyser.
- Conformity Monkey : arrête toutes les instances non conforme pour laisser le système refaire de nouvelles instances
- Security Monkey : arrête toutes les instances comportant des anomalies
- 10-18 Monkey : détecte des soucis de localisation et de langues.
Conclusion Chaos engineering
J’espère que cet article vous a éclairé sur ce qu’est le Chaos engineering. Nous verrons ces différents outils dans de prochains articles.
Avez-vous adoptez le Chaos engineering dans votre entreprise ? Quels sont les effets positifs de la mise en place du Chaos engineering dans vos entreprises ?
Lien utile autour du Chaos engineering : github de chaos monkey
1 Rétrolien / Ping