Concrètement, le chaos engineering c’est choisir comme cible une ou plusieurs pièces de l’infrastructure à éprouver et les rendre indisponibles :
L’infrastructure doit réagir à cette perte et retrouver rapidement son état stable. Cela passe par l’automatisation de recréation de ressources comme le fait nativement Kubernetes. C’est cette capacité à s’auto-régénérer, appelée résilience, qui est mise à l’épreuve en chaos engineering. Comme expliqué dans les principes du chaos engineering, l'approche se base sur 4 principes :
L’état stable est celui dans lequel l’infrastructure délivre le service attendu dans les temps attendu. Ces niveaux d’attentes sont définis par le SRE sous forme de SLO, pour Service Level Objectives et surtout ils sont mesurés par des SLI, pour Service Level Indicators.
Le monitoring est le moyen de définir l’état stable de l’infrastructure, d’y parvenir et de le maintenir. Plusieurs outils de monitoring open source et très performants sont disponibles. Ci-dessous, vous pouvez trouver un exemple de dashboard Grafana représentant l’activité d’une application.
Cette partie est essentielle afin de pouvoir descendre dans la mise en place du chaos engineering et heureusement, ce travail est déjà l’adage des Site Reliability Engineers qui savent dégager les indicateurs clefs du cycle de vie d’une application.
La confiance n'évite pas le contrôle.
C’est l'action de définir des hypothèses qui marquent l’entrée dans la réflexion chaos engineering. Par exemple : “Mon infrastructure conserve son état stable après la perte d’un nœud Kubernetes, de 2 ou après une panne de disque ”.
Sous la forme d’une affirmation, l’hypothèse établie le niveau de confiance souhaité. À l’image de l’évaluation des risques en cybersécurité, le chaos engineer place ses hypothèses selon la gravité et la probabilité de l’apparition du dysfonctionnement.
Les ingénieurs ont dégagé des niveaux de qualité à atteindre pour obtenir un niveau de confiance dans leurs produits. Le but de la manœuvre est de construire une plateforme résistante à des conditions 'menaçantes', supérieures à ce qu'elles seraient en production.
Une fois les hypothèses précisées, il faut définir des conditions expérimentales en adéquation avec les briques d’infrastructure à éprouver. La perte d’un nœud Kubernetes se traduit par l’extinction planifiée de la VM dans l’hyperviseur VMWare par exemple et pour la panne de disque, cela peut être une surcharge d’IO ou bien sa déconnexion pure et simple.
Pour appliquer ces conditions, il faut ensuite se tourner vers les outils de chaos engineering adaptés. Tout déploiement peut être envisagé comme faillible : de la panne hardware à la saturation du réseau en passant par l'envoi de réponses HTTP mal formées. Même les AWS lambda peuvent être ciblées, (voir l'outil open source chaos-lambda).
Ce qu’il faut observer dans l’écart c’est d’une part le rétablissement de l’état stable et le temps passé entre l’apparition du dysfonctionnement et le retour à la normale.
Sur cette demo de chaos-mesh (outil de chaos engineering que je détaille plus bas), on voit très nettement sur les graphes de Grafana, un retour très lent à l’état stable. C’est grâce à la bonne supervision de l’infrastructure induite par le principe de définition de l’état stable que les indicateurs permettent de dégager des écarts pertinents.
L’étape suivante consiste à catégoriser ces écarts en gardant en tête la question suivante : “Combien coûte 1 / 2 / 5 minutes de déni de service ?”. L'objectif est d'établir quels sont ceux à traiter en axes d’améliorations et ceux qui sont acceptés.
"D'accord mais comment je mets ça en place ?"
La palette des outils de chaos engineering s'est étoffée ces dernières années. La plupart d'entre eux sont créés pour être déployés sur un cluster Kubernetes (les kubes dont on parlait dans l'intro 😉). Ceux-ci implémentent les conditions expérimentales que les chaos engineers ont conceptualisées.
Tous les outils que je vous présente ci-dessous sont affichés sur le site de la cncf.
Il y a ceux qui s’attaquent à Kubernetes :
Il y a les couteaux suisses :
Il y a les outils guidés :
Les avantages du chaos engineering sont nombreux et tournent tous autour du gain de confiance que cette pratique apporte. 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.
Après avoir fait vos premiers pas dans ce modèle, si vous sentez avoir gagné en maturité, il devient envisageable d'appliquer les conditions expérimentales du chaos engineering à votre production. En décision avec votre SRE, et selon “l'error budget”, des dénis de service sont acceptés s'ils sont contrôlés, surveillés et contenus et peuvent dégager de nouveaux axes d'amélioration.
Ce qui n’est pas forcément un inconvénient mais qui peut freiner la mise en place de chaos engineering sur son infrastructure c’est la remise en question que cela implique. Il faut faire preuve d’une humilité vertueuse qui amènera à plus de résilience, c’est un passage obligé.
Ensuite c’est la mise en évidence des dysfonctionnements qui peuvent être tellement divers qu’il est facilement possible d’en oublier certains et ceux-ci peuvent s’avérer relativement graves et probables.
Le chaos engineering s'adresse à toute équipe de production informatique soucieuse de la qualité de sa livraison d'infrastructure et de la résilience de cette dernière : sa capacité à résister aux chocs et à s'auto-régénérer.
Les barrières à l'entrée technique sont relativement faibles, en revanche, il faut un certain temps de conception pour implémenter ces pratiques sur une infrastructure existante voire pour l'intégrer au déploiement d'une future plateforme.
On peut prendre en exemple les GAFAM qui ont implémenté le chaos engineering et autres Netflix, Dailymotion, LinkedIn, UnderArmour, Expedia, Target / Wallmart et qui sont parmi les plateformes les plus robustes à l'heure actuelle.
"Mais alors les singes dans cette histoire ?" Et bien je vous laisse lire cet article sur Kube-monkey