Avec l'essor des micro services et des architectures distribuées, les infrastructures sont devenues de plus en plus complexes. Nous dépendons tous plus que jamais de ces systèmes, mais les défaillances sont devenues beaucoup plus difficiles à prévoir. Même lorsque tous les services individuels d’un système distribué fonctionnent correctement, les interactions entre ces services peuvent provoquer des résultats imprévisibles. Ces résultats imprévisibles, aggravés par les événements rares, mais perturbateurs du monde réel qui affectent les environnements de production, rendent ces systèmes distribués intrinsèquement chaotiques.
Le chaos engineering est une discipline qui consiste à mener des expérimentations sur un système de façon à renforcer la confiance dans la capacité du système à résister aux conditions turbulentes de la production. Concrètement, le chaos engineering consiste à simuler la panne d’un ou plusieurs nœuds choisis aléatoirement (ex : éteindre des machines ou bloquer du trafic réseau) et de là, observer le comportement de l’ensemble du système. Ceci va permettre de relever d’éventuelles faiblesses et lacunes du système et de s’en prémunir. En d’autres termes, le chaos engineering est une approche empirique qui permet d’observer la réaction du système face à des événements réalistes et imprévus au cours d’une expérience contrôlée dans un but de fortification de l’infrastructure.
1. On commence par définir un « état stable » qui indique le comportement et les performances du système dans un état normal. On définit les attentes qu’on a du système sous forme de SRO (Service Level Objectives), et on pose des SLI (Service Level Indicators) pour les mesurer.
2. On émet une ou plusieurs hypothèses que cet état stable se maintiendra à la survenue d’un événement perturbant le bon fonctionnement du système. L’hypothèse émise reflète la confiance que l’on a en ce système.
3. Par la suite, on se met dans les conditions expérimentales en introduisant des variables qui reflètent des événements réels comme des serveurs qui tombent en panne, des disques durs qui fonctionnent mal, des connexions réseau qui sont rompues, etc.
4. On vérifie la solidité des hypothèses précédemment établies en observant l’écart que l’on a avec celle-ci. Il est aussi intéressant d’observer le rétablissement de l’état stable et le temps passé entre l’apparition du dysfonctionnement et le retour à la normale. Ceci va permettre d’identifier quels sont les nœuds les plus sensibles de l’infrastructure et de mettre en place des mesures permettant de mitiger les risques liés à la panne de ceux-ci.
Le principal avantage qu’offre le chaos engineering est d’accroitre la confiance que l’on a en notre système. En effet, cela permet d’établir une marge de panne mesurée et anticipée dans laquelle l’infrastructure conserve son état stable et continue de délivrer le service comme attendu.
Plus il est difficile de perturber l’état stable, plus nous avons confiance dans le comportement du système. Si une faiblesse est découverte, nous savons maintenant qu’elle est le potentiel maillon faible du système. Et on peut donc la corriger avant que la panne simulée ne survienne dans un environnement non maitrisé.
.png)
.png)
.png)
.png)
.png)
.png)