Le Chaos engineering

Simian Army - chaos engineering
Simian Army - chaos engineering

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 :

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) :

pyramide des tests
pyramide des tests

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

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 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
  • 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.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 446 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.