Ingénierie du chaos — Chaos Engineering in French — Partie 1 : (pour)quoi ?

Si ce n’est pas cassé, ne le répare pas.
Bert Lance, Nation’s Business, 1977

Si ce n’est pas encore cassé, essaye plus fort.
Philosophie Chaos Engineering, 2015

La discipline d’ingénierie du chaos a été initiée par Netflix et le principe a été défini sur http://principlesofchaos.org/

Discipline de l’expérimentation sur un système distribué afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes en production.

L’ingénierie du chaos, ou Chaos Engineering, est une discipline émergente qui vise à éprouver la solidité de l’infrastructure socio-technique afin de toujours mieux préserver la qualité de service. Cette pratique expérimente les lacunes et les faiblesses des applications et de l’infrastructure sur un système distribué. La complexification et l’automatisation des systèmes rendent cette pratique de plus en plus importante pour maintenir l’expérience utilisateur. Expérimentée depuis 6 ans par des pure-player comme Netflix, elle s’est structurée autour de process et d’outils dédiés.

La question que pose cette discipline est donc :

A quel point votre système est-il proche du précipice et peut sombrer dans le chaos ?

Everything fails all the time
Werner Vogels, CTO Amazon

A chaque instant, quelque chose, quelque part, tombe en panne. Il ne s’agit plus de croiser les doigts pour que ça n’arrive pas, mais de mettre en place la résilience nécessaire dans nos systèmes pour tolérer les pannes, et de s’assurer que cette résilience est opérationnelle et fiable en production.

Et pourtant, on teste !

La réponse usuelle : la pyramide des tests tout au long du process de développement et conception. Nous avons tous mis en place l’ensemble des tests nécessaire à la qualité de nos applications et pour garantir la conformité aux normes d’exploitabilité, pour atteindre le niveau de confiance nécessaire aux déploiements de plus en plus fréquents des évolutions de notre SI.

Cependant, une des plus importantes problématiques dans les pratiques de test est la représentativité des environnements hors production.

Nous nous sommes tous confrontés à une dure réalité : c’est quasi impossible et très coûteux à maintenir à jour.

L’avènement des démarches Agile & Devops contribue à complexifier le sujet en permettant de livrer de plus en plus fréquemment, jusqu’à plusieurs fois par jour.

Par ailleurs, les environnements hors production sont et seront de moins en moins représentatifs quand vous êtes dans le Cloud et que votre infra s’adapte à votre trafic par de l’auto-scalling.

La personnalisation de plus en plus poussée de nos applications - donc avec des comportements basés sur de la donnée — nous met face à des parcours clients qui s’adaptent en temps réel.

Et çà va empirer avec le déploiement de l’Intelligence Artificielle.

Il devient donc nécessaire d’expérimenter en production afin d’avoir le bon niveau de confiance dans nos systèmes.

Oui, vous avez bien lu, il s’agit bien d’effectuer des tests en production :

• Expérimenter pour éprouver nos systèmes : plutôt qu’attendre une panne, il s’agit d’en introduire une pour tester la résilience du système,
• Expérimenter pour apprendre : il ne s’agit pas de provoquer le chaos pour s’amuser, mais bien pour découvrir des faiblesses inconnues de nos systèmes.

Il s’agit par contre d’expérimenter en production sur un système stable et performant.

Ce n’est pas un jeu, mais la vie réel, avec des impacts humains et financiers potentiellement important.

L’ingénieur du Chaos n’est pas un savant fou, c’est un explorateur en recherche de connaissances sur le système qu’il étudie.

Qu’est-ce qu’une expérimentation ?

Dans l’ouvrage présenté en fin d’article, les ingénieurs du Chaos de Netflix Technology Blog ont proposé ce protocole :

1. Définir quelle est la question que l’on souhaite poser au système : souhaite-t-on tester la résilience d’un composant, d’une application, d’une organisation ?
2. Définir le périmètre de l’expérience : est-ce tout ou partie de la production ? est-ce uniquement l’environnement technique seul ou inclure également les interventions humaines (surveillance, exploitation, support),
3. Identifier précisément les métriques qui permettront de valider l’expérience et éventuellement de l’arrêter instantanément en cas d’impact critique,
4. Communiquer, prévenir l’organisation de l’existence de l’expérimentation — pour éviter l’escalade en cas d’incident critique
5. Réaliser l’expérience
6. Analyser les résultats, mettre en place les éventuels plans d’action nécessaires
7. Elargir le scope pour la prochaine expérience.

Cependant, faire un test une fois permettra de se rassurer sur la résilience de votre système, mais avec des changements permanents, la seule façon de bien dormir la nuit est d’automatiser l’expérience pour qu’elle se réalise en continue afin de suivre l’évolution du système.

Exemple d’expérimentation

• Mettre en place des Chaos Monkey — simuler des pannes en environnement réel et vérifier que le système informatique continue à fonctionner.

L’expérience consiste à régulièrement choisir au hasard des instances dans l’environnement de production et de les mettre délibérément hors service. En «tuant» régulièrement des instances au hasard, on s’assure avoir anticipé correctement la survenue de ce type d’incidents en mettant en place une architecture suffisamment redondante pour qu’une panne de serveurs n’impacte d’aucune façon le service rendu.
Mise en place par Netflix début 2011, ils ont intégré la Simian Army qui présentent d’autres types d’interruption : Chaos Kong (qui fait tomber une zone complète de disponibilité Amazon), Latency Monkey (qui permet de tester la tolérance à la perte de performance d’un composant externe), Security Monkey (qui met hors service toutes instances qui présentent des vulnérabilités), …

• Mettre en place un Gameday : pour tester la résilience de l’organisation et l’entrainer à réagir en cas d’incidents, Jesse Robbins, ex- « Master of Disaster » chez Amazon, a mis en place le concept de Gameday qui consistent à simuler des pannes pour tester la capacité des équipes à réagir et revenir à une situation nominale.
• Mettre en place un Days of Chaos, une déclinaison de GameDay par OUI.sncf à destination de toutes les équipes IT et visant à l’entrainement à la détection, au diagnostic et à la résolution des incidents de production.
• Mettre en place des Test de Récupération après Sinistre (Disaster Recovery Testing) de manière récurrente.

Pour en savoir plus

On vous recommande cet ebook gratuit chez O’Reilly: Chaos Engineering, Building Confidence in System Behavior through Experiments

Mettre en place du Chaos n’est pas la meilleure façon de rencontrer vos nouveaux collègues, mais c’est la plus rapide.

Nora Jones (@nora_js)

En espérant que vous nous rejoignez bientôt dans ces expérimentations en ingénierie du Chaos .

Pour échanger, rejoignez-nous sur le groupe Meetup Paris Chaos Engineering Community http://meetu.ps/c/3BMlX/xNjMx/f

Aller à la partie 2 : Où en sommes-nous ?>>>