Le guide de Chaos Engineering : Partie 1

Objectif

En d'autres termes, le chaos engineering (CE) permet aux ingénieurs de découvrir l'impact des incidents de production sur l'utilisateur final.  Le CE peut être appliqué grâce à des outils open source ou bien propriétaires, en exécutant différents types de perturbations sur un système d'information dans le but de renforcer sa résilience.
Le CE répond à la question fréquente : "voulez-vous être sûr du "bon" fonctionnement de votre système ?"

“There's no better way to test something than to break it”
Matt Fornaciari co-founder,CTO of Gremlin Inc

Les concepts

Qu’est-ce qu’un système résilient ?

Un système résilient :

• est hautement disponible et durable,
• permet de maintenir un niveau de continuité de service acceptable malgré des incidents inattendus "Unknowns" - exemple: erreur humaine,
• peut résister à la “tempête” (une mauvaise configuration, une catastrophe naturelle ou des actions de Chaos Engineering),
• sait comment revenir à son état stable.

Attention, on doit éviter la confusion entre la résilience et la robustesse.

Un système robuste :

• est hautement disponible et durable,
• permet de gérer les pannes attendues "Knowns" - exemple: fort traffic,
• peut résister pour une certaine durée à ces pannes avant qu'il ne devienne K.O.

Qu’est-ce qu’un système distribué et complexe ?

Le chaos engineering n'est pas un simple test ou une méthode qui sert à nuire au système. Il s'agit d'établir et implémenter une discipline d'apprentissage à travers des expérimentations sur le système. Le but est de renforcer la confiance dans son environnement, quelle que soit sa complexité.

Avant de passer à l'implémentation du Chaos Engineering, on doit tout d'abord vérifier la nature de notre système :

1. Un système distribué

Contrairement à un système centralisé, un système distribué est composé de plusieurs entités logicielles s'exécutant indépendamment et parallèlement sur un ensemble d’hôtes connectés en réseaux. Dans un système distribué, l'utilisateur et les entités n'ont pas besoin de connaître les détails de l'architecture système.
L’intérêt de l'utilisation des systèmes distribués réside dans l'utilisation et le partage des ressources distantes, l'optimisation des ressources disponibles et la robustesse grâce à la duplication qui assure une certaine fiabilité.
Parmi les principales caractéristiques des systèmes distribués :

Hétérogénéité : la diversité des systèmes d'exploitation (Centos 7, Windows 10...), différents hôtes (puissance, architecture, matérielle...), des langages de programmation des éléments logiciels formant le système, des réseaux utilisés (impact sur la performance, le débit, la disponibilité...)

Transparence : dans le but de cacher l'architecture, le fonctionnement de l'application ou du système distribué apparaît aux utilisateurs comme une application unique cohérente. Il existe plusieurs types de transparence (l'ISO définit plusieurs transparences (norme RM-ODP Reference Model-of Open Distributed Processing)).

2. Un système complexe

Un système complexe est un système distribué composé de plus petites unités et en évolution en fonction du temps. Ces entités se répartissent en fonctions clés au sein du système. De nombreux styles d'architectures permettent de réaliser de tels systèmes, comme ceux basés sur les micro-services qui sont capables d’évoluer en ajoutant d’autres micro-services au système.

3. Un micro-service

J’apprécie beaucoup la description faite sur le blog de Xebia :
“Un micro-service est avant tout une unité fonctionnelle. Il correspond à une fonctionnalité précise, logique et cohérente du système.

Il est donc autonome vis à vis de la fonctionnalité qu’il réalise. Il a son propre code, gère ses propres données et ne les partage pas - pas directement en tout cas - avec d’autres services.

Dans ce style architectural, un service correspond, de plus, à un processus système indépendant. Dans certains cas, un micro-service peut être constitué de plusieurs processus mais l’inverse n’est pas vrai. Une conséquence de ce constat est que les services communiquent entre eux par des appels réseaux et non par des appels de fonctions en interne dans un processus.

Un micro-service est donc une unité de service fonctionnelle qui se développe, se déploie, s’exécute et gère ses données indépendamment des autres services du système.”

On pourra avoir du chaos dans les systèmes réguliers (la latence, la charge des CPU, …).
Les systèmes complexes et distribués représentent les meilleurs candidats à l’échec.

État d’esprit

Avant de commencer à tout “détruire”, il faut s’assurer d’avoir un état d'esprit qui correspond à la démarche du chaos engineering :

• On ne doit pas laisser une panne se perdre. On doit apprendre des échecs quand ils se produisent.
• Il faut avoir une attitude pré-mortem. On doit apprendre des pannes, mais il vaut mieux explorer les faiblesses avant qu'elles ne se produisent.
  Il faut avoir un esprit collaboratif : on n'exécute pas d'expériences sur des systèmes tiers.
• Toute l'équipe devrait décider de la cible des expérimentations.
• On doit commencer "petit" avec une petite expérience. Si le système survit, on doit alors augmenter la portée.
• On commence à travailler manuellement sans utiliser les outils existants sur le marché. Après cela, on peut automatiser en utilisant des outils disponibles.

Conditions idéales

1. Équipe DevOps et Agile

Le chaos engineering nécessite de la communication et de l’hétérogénéité au sein de l’équipe. La coordination entre les membres de l'équipe sert à faciliter la connaissance de l'état stable du système qui va être soumis aux expérimentations.
L’équipe s'organise et se concentre en formant un cercle d'échange d'expertises. Elles doivent susciter une symbiose entre des compétences complémentaires.

2. L'existence d'un outil de monitoring

Avant de s’intéresser à ce prérequis, il est indispensable de définir quelques termes en relation avec le Monitoring.
On commence par la métrologie; cette méthode permet d’archiver les données relevées et d’effectuer des traitements dessus, notamment grâce à des mécanismes de filtration. Le but est de les présenter sous forme de graphes pour faire du reporting. Ces données serviront à apporter des correctifs à posteriori, sur le développement ou le paramétrage des services dans le but de les optimiser. La métrologie devient alors très importante car c’est elle qui donne la possibilité d'améliorer la qualité de service.
On passe ensuite à la supervision. Elle sert à vérifier l'état d'un service ou d'un hôte. La supervision remonte une alerte sur la détection d'un comportement anormal (la latence par exemple).
Le monitoring est le fait de superviser des équipements et des services et détecter les évolutions du système dans le temps grâce à la lecture des courbes de données métriques.
L'utilisation de l'outil de monitoring dans le cas du chaos engineering est indispensable pour connaître l'état du système à chaque attaque de chaos. La visibilité sur le comportement du système permet de tirer les conclusions des expérimentations de chaos.

3. Un système distribué

Avoir un système distribué n’est pas un prérequis, malgré tout, le graphe suivant représente un arbre de prise de décision qui vous permet de vous rapprocher des conditions idéales :

Prérequis

Les prérequis indispensables pour une bonne implémentation du Chaos sont les suivants :

Alerting

Netflix défini des guidelines pour adhérer à une certaine philosophie de l’alerting.Pour pouvoir appliquer du chaos engineering, il faut être sûr de la mise en place d'un système d'alerting.

Les alertes doivent obéir avant tout aux principes suivants :

• Garder des conditions simples.
• Etre exploitables.
• Ne pas avoir de cas particulier pour la maintenance quotidienne.

Méthode d’expérimentation

Netflix a identifié 4 principes pour désigner une expérimentation de chaos :

• Développer une hypothèse autour de l'état stable du système,
• Appliquer des événements réels sur le système.
• Tester les expérimentations en production.
• Automatiser les expérimentations.

Ces principes mènent à définir les phases de CE :

L'état stable (Steady State)

Quel est cet état ? Comment puis-je l'identifier ?
Cette question sera à la base d'une équipe compétente et maîtrisant son système. Des réponses vont y être apporté à l'aide du monitoring et de la collecte de métriques (KPI, latence, taux d'erreur ...). Vous apporterez également des réponses avec la compréhension et la définition de la satisfaction des utilisateurs du système.

Les hypothèses

Pour toute expérimentation, Il est nécessaire de faire une hypothèse qu’on vérifiera via l’expérimentation de chaos.
C'est pour cette raison qu'on développe les hypothèses autour de l'état stable du système. Si on sait que l'expérimentation entraînera des perturbations sur l’environnement de production (après dialogue avec l’équipe qui maîtrise le système), on devra la repousser. On doit tout d'abord travailler à renforcer la fiabilité du système avant d’expérimenter dessus, il ne s’agit pas de le casser.

Expérimenter

Dans cette étape, on effectue les tests et les expérimentations en commençant par des tests simples. Ces tests peuvent affecter la disponibilité des micro-services centraux afin de tester la résilience du système. Parmi les tests courants, vous trouverez par exemple des tests de défaillance de matérielle, surcharge de ressources, injection de latence et de défaillance réseau, etc.

Par la suite, on passera aux expérimentations de chaos utilisant des outils qui s’appliquent sur le système global (cela doit être préparé par une étude).

Vérifier et corriger

Pour cette étape, on compare les résultats obtenus par les expérimentations aux métriques de l'état stable du système. Puis, on corrige les erreurs et les problèmes pour renforcer la résilience du système.

Automatiser

Pour des implémentations efficaces de Chaos Engineering, l'automatisation des tests et l'exécution des expérimentations sont nécessaires. Netflix a développé ChAP (Chaos Automation Platform) qui est une plateforme d'automatisation de chaos (Nous en parlerons bientôt dans le prochain article).

Où peut-on faire du chaos engineering ?

Le chaos engineering peut être injecté dans les différentes couches du système. J’aborderais ce point plus en détail dans mes prochaines articles mais vous pouvez tout à fait imaginer faire du chaos sur vos APIs, dans vos applications, bases de données, systèmes de cache, vos hôtes et leurs OS, le réseau, l’énergie ou même sur vos équipe

RoadMap to Become a Chaos Engineer

Une RoadMap a été réalisée par Yury Niño, l'une des grandes enthousiastes du Chaos Engineering.

Elle illustre les différentes technologies applicatives, de base de données, de conteneurisation, d'architectures cloud etc, que l’on rencontre sur le chemin que nous venons d’emprunter et que l’on devra surement apprendre à maîtriser pour devenir un ingénieur du Chaos.

Il faut commencer par avoir une idée des concepts de CE tels que les phases et les principes. Ensuite on doit définir les domaines (représentés par les couleurs) où l'on veut faire du chaos (par exemple le niveau applicatif, cloud…) et une partie des technologies à connaître jusqu’au choix des outils de CE à utiliser.

Cette RoadMap reste évidemment toujours ouverte à des nouveaux concepts et technologies qui favorisent l’implémentation de CE.

Conclusion

Parmi les bénéfices à retirer de la pratique du Chaos Engineering, ce qui me motive le plus est :

• D’aboutir à un système "presque" sans problème,
• De ne plus avoir à me lever la nuit.
• D’approfondir la connaissance des forces mais aussi des faiblesses du système.
• D’interagir avec la communauté Chaos, qui est de plus en plus importante.

Une deuxième et une troisième parties suivront prochainement cet article. On parlera des outils Open Source de Chaos Engineering existant et je vous présenterai également un REX sur le sujet.

PS : I want to thank Russ Miles and Sylvain Hellegouarch for their help into becoming a Chaos Engineer.