Le chaos engineering - L'arbre qui cache la forêt ?

1. Chaos Engineering
L’arbre qui cache la forêt ?

2. Objectifs de la présentation
● Présenter l’état d’esprit derrière le chaos engineering
● Comprendre que le CE est un outil pour quelque chose de plus important
● Vous donnez envie d’aller en apprendre plus :)

3. Non-Objectifs de la présentation
● Pas de démo ;(
● La prochaine fois !

4. Votre entreprise
Photo by Mike Morgan on Unsplash

5. Votre produit
Photo by sunorwind on Unsplash

6. Produire et vendre les meilleures lasagnes !
Quel est l’objectif de
l’entreprise ?

7. Un plan d’enfer !

8. J’imagine que...
● Votre fournisseur est sûr et fiable
● Votre matériel est robuste
● Votre équipe réactive
● Vous êtes à l’écoute des signaux négatifs

9. Vous pensez ou avez-vous
des preuves ?

10. Des preuves ?
Vous basez-vous sur un a
priori ?
Une expérience passée ?

11. Sans preuves, sur quelles
bases décidez-vous ?

12. Montrez vos preuves que...
● Votre fournisseur est sûr et fiable
● Votre matériel est robuste
● Votre équipe réactive
● Vous êtes à l’écoute des signaux négatifs

13. Le Chaos Engineering
offre un protocole de
recherche de preuves
autour d’une hypothèse

14. “Nous servons N portions à base de
produits frais quotidiennement”
Hypothèse

15. Conditions expérimentales
● Pas de livraison aujourd’hui
● Pas de livraison pendant 3 jours
● Le fournisseur a fermé
● Livraison trop faible en qualité
● Livraison trop faible en quantité
● Les serveurs sont absents
● Le client n’aime pas les lasagnes
● Le client veut des lasagnes végétariennes

16. Vos mesures / collecte de données
● Nombre de portions réalisées
● Temps d’exécutions des plats
● Alertes sur des signaux négatifs (nombre d’assiettes retournées…)

17. Par où démarrer ?

18. Pas de recette miracle ici...
● Tout le monde devrait remonter quelque part (trello, github) ses
inquiétudes, questions, hypothèses… puis un travail de
discussion/priorisation
● Une communauté de pratiques est une bonne approche (l’équipe chaos
engineering est un antipattern)
● Effectuer un gameday avant d’automatiser peut fédérer sur l’exercice
● Rinse and repeat: La pratique s’installe comme une habitude avec la
répétition

19. Le protocole Chaos Engineering,
c’est quoi ?
• C’est une approche qui s’inspire de la méthode scientifique: hypothèse,
expérimentation / observation, analyse puis confirmation / infirmation de
l’hypothèse
• Proposée par des anciens ingénieur(e)s de Netflix dans le Principle of
Chaos
• L’objectif est de poser des hypothèses sur la manière dont un système se
comporte lors de turbulences ou conditions dégradées

20. Rapide point sur les familles d’outils
• Injection de fautes systèmes : réseau, CPU, stockage...
• Litmus, Gremlin, Pumba, Chaos Mesh, Powerful Seal, Toxi Proxy
• Utilisation d’APIs dédiées à l’injection de fautes. On retrouve ce genre
d’APIs dans certains services mesh
• Istio
• Pilotage d’APIs existantes qui peuvent être appelées dans le cycle naturel
de vie d’un applicatif (ROLLOUT DEPLOYMENT, REBOOT VM, CHANGE
SECURITY POLICY)
• All cloud providers and beyond (Chaos Toolkit)
• Pilotage d’outils spécifiques (test de charge…)
• vegeta, hey

22. Chaos Toolkit: Unifier l’UX du chaos
engineering
• Implémente le protocole :
• steady state hypothesis before/after/during method => dévie-t-on de notre statut de base ?
• method: conditions expérimentales et measures
• Offre une interface pour piloter des outils d’injection de fautes et de
mesures
• Déclaratif
• Ligne de commande pour automatisation :
$ chaos run experiment.json
• Open Source (Apache v2), Python 3
Voir https://asciinema.org/~Lawouach

25. Super, c’est simple !

26. Oui mais...

27. Le Chaos Engineering
reste un outil

28. Il fait parti d’une
aptitude/capacité plus
large de résilience

29. La résilience est une
composante interne
mesurable

30. Le chaos engineering est
un outil approprié pour
déterminer les points
d’améliorations

31. Revenons à notre
hypothèse de base un
instant

32. “Nous servons N portions à base de
produits frais quotidiennement”
Hypothèse

33. Cette hypothèse peut être
aussi considérée comme
un objectif de l’entreprise

34. Du point de vue
utilisateur, la résilience
n’a pas beaucoup de
réalité tangible

35. L’utilisateur s’attend à un
service et en tire une
opinion sur votre fiabilité
(reliability)

36. La fiabilité est subjective
à vos utilisateurs

37. Pourquoi est-ce
important ?

38. La fiabilité détermine le
comportement de vos
utilisateurs

39. Être fiable s’est favoriser
la rétention et la
croissance de votre
produit

40. Le Chaos Engineering
explore la résilience
mesurée de vos systèmes
afin d’améliorer la
fiabilité perçue de vos
utilisateurs

41. Dans ce cadre, le chaos
engineering s’inscrit
pleinement dans les
cultures DevOps/SRE

42. tl;dr;
● Le Chaos Engineering est un moyen, pas une fin
● Il s’inscrit pleinement dans les cultures DevOps et SRE
● Le chaos engineering vous aide à mesurer votre résilience
● …afin de mieux fidéliser et satisfaire vos utilisateurs en améliorant leur
perception de votre fiabilité
Pratiquez, pratiquez, pratiquez !

43. Merci!