Voyages-SNCF sème, volontairement, le chaos dans sa production informatique

Encore vus comme la norme dans la profession, les tests sur des environnements de préproduction virent au casse-tête avec les principes de l’intégration continue. Fort de ce constat, Voyages-SNCF développe des outils testant la résilience de son système d’information directement en production. En y semant le chaos ! A l’image d’un Netflix, un des pionniers de cette pratique.

Avec un système d’information en perpétuelle évolution, via des pratiques comme l’intégration continue ou le Devops, les tests ne suffisent plus. C’est ce constat – couplé à une sévère panne d’AWS – qui a poussé Netflix à se lancer dans une démarche originale. Une pratique qui a de quoi faire dresser les cheveux sur la tête de plus d’un directeur de production IT puisqu’elle consiste à tester, en live, l’effet de l’arrêt d’un service.

Un principe inspiré des théories de l’ingénierie du chaos (Chaos Engineering) qui a vu Netflix développer toute une série d’agents, la Simian Army (l’armée simiesque), afin de tester la fiabilité, la sécurité ou la résilience d’AWS. Ces outils (Chaos Monkey, Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey…) sont aujourd’hui disponibles pour la plupart en Open Source.

C’est l’exemple de ce pionnier du Chaos Engineering qu’a décidé de suivre Oui SNCF Technologies (anciennement Voyages-SNCF Technologies). « Nous mettons en production 5 modifications applicatives par jour en moyenne et environ autant de changements dans notre infrastructure technique. S’il a toujours été difficile de bâtir des environnements de préproduction pour conduire des tests, avec le Continuous Delivery, c’est devenu tout simplement impossible. La seule solution consiste à tester en production, sur un système stable et performant », résume Christophe Rochefolle, le directeur de l’excellence opérationnelle de Oui SNCF Technologies. « Et disposer d’une architecture sous forme de microservices ne suffit pas à garantir la résilience d’un système, ajoute Sylvain Hellegouarch, co-créateur du Chaos Toolkit, un framework Open Source dédié à l’ingénierie du chaos dans les infrastructures informatiques. Car le lien entre les conteneurs peut, par exemple, s’avérer fragile. »

Un bestiaire chez Oui SNCF

Démarrée fin 2015, la démarche du voyagiste débouche très vite sur un premier Proof-of-concept, un agent appelé Chaos Monkey qui arrête une instance applicative pour vérifier que le système va encaisser ce dysfonctionnement sans perturber la qualité de service. « Nous nous sommes vite rendus compte que nous allions avoir besoin de davantage de scénarios pour tester la robustesse d’ensemble de notre système », dit Benjamin Garik, expert en sûreté de fonctionnement chez Oui SNCF (en photo).

Ce constat, et la volonté du voyagiste de faire de l’ingénierie du chaos une démarche au long cours, ont abouti à la création d’une communauté Résilience et tests techniques (soit… RTT), puis au développement d’un bestiaire à l’image de la Simian Army de Netflix. En plus de tester l’arrêt d’une instance, ces nouveaux ‘petits monstres’ doivent, par exemple, permettre aux équipes de valider la solidité des liens avec des partenaires, d’évaluer l’effet d’un effacement de données, de l’arrêt brutal d’un processus serveur ou encore d’un changement de propriétés d’une application suivi d’un redémarrage.

Chaos Monkey : lâcher le fauve ?

Reste encore à convaincre les équipes, notamment celles chargées de l’exploitation, du bien-fondé de la démarche qui rompt avec des principes bien ancrés dans toutes les productions informatiques. Un choc culturel qui explique en partie pourquoi le Chaos Monkey de Oui SNCF n’est pas encore totalement sorti de sa cage. « Son fonctionnement est pour l’instant bridé : ce sont les développeurs qui pilotent le déclenchement de l’outil. Ce sont également eux qui effectuent les analyses post-incidents, même si ce sont bien les exploitants qui sont chargés des réparations », indique Benjamin Garik.

Si, depuis mai dernier, le Chaos Monkey tourne bien après chaque sprint de développement sur une application, et si Oui SNCF prévoit de l’étendre à 5 applications avant la fin de l’année, le ‘fauve’ n’a donc pas été encore totalement lâché. « Mais quand on aura atteint un niveau de stabilité suffisant, on a bien l’intention de laisser la Chaos Monkey s’exécuter en permanence », reprend l’expert.

Pour développer la culture du Chaos Engineering en interne, Oui SNCF a monté une première journée de simulation. Un jeu appelé Day of Chaos mettant les développeurs face à des pannes imaginées par les exploitants. Au total, plus de 110 joueurs répartis dans 18 équipes se sont affrontés sur la résolution de 8 pannes. De quoi les sensibiliser au suivi de production et aux problématiques de résilience des systèmes. Ce premier succès a poussé le voyagiste à organiser une seconde journée de même nature, axée sur la gestion de crise et impliquant directement la production informatique, la relation client et même le comité de direction.

« Intégrer des applications critiques »

Intégrée à un programme appelé ‘2020 sans les mains’ (sic), visant notamment à éliminer les interventions de nuit, les interventions manuelles sur des serveurs, les infrastructures surdimensionnées sans générer des impacts négatifs pour l’activité, la démarche de Chaos Engineering commence à faire son trou. Il est par exemple significatif de constater que l’application de CDN interne, par laquelle passe tout le trafic du voyagiste, figure parmi les 5 applications qui serviront de terrain de jeu au Chaos Monkey avant la fin 2017. « C’est important d’intégrer des applications critiques car cela permet d’instaurer, sur les sujets de la résilience, un dialogue avec les équipes en charge de celles-ci, dit Benjamin Garik. On s’aperçoit parfois que la solution à certaines fragilités ne dépend pas de l’équipe en charge de l’application à proprement parler, mais de composants tiers. »

La DSI du voyagiste a aussi réussi à susciter la curiosité des équipes informatiques de la SNCF, à la tête du système de réservation sur lequel se connecte le site marchand. Créant ainsi un lien de dépendance fort vis-à-vis de ce système sur mainframe. Les deux équipes ont déjà prévu de travailler ensemble sur des sujets relatifs à la résilience de l’édifice.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s