Nous vous parlions il y a peu de temps du chaos engineering, qui vise à améliorer la fiabilité des architectures IT à travers l’expérimentation. Si le Chaos Engineering est une discipline émergente, pratiquée par des sociétés comme Netflix et Amazon, en France OUI.sncf est pionnier sur le sujet et a intégré le Chaos Engineering dans son SRE (site reliability engineering). Pour approfondir ce sujet, nous avons rencontré Benjamin Gakic, Chaos Engineer et SRE chez OUI.sncf : comment initier une démarche de Chaos Engineering ? Quels sont les changements culturels induits par le Chaos Engineering et que retenir d’une année d’expérimentation sur ce sujet ?

Benjamin Gakic

Ancien développeur et architecte technique depuis plus de 10 ans, Benjamin Gakic, anime la communauté Chaos Engineering de OUI.sncf. Cette dernière a en particulier adapté le Chaos Monkey de Netflix. Au sein de l’entité Excellence Opérationnelle, Benjamin promeut une approche DevOps axée sur la sûreté de fonctionnement.

Comment définir le Chaos Engineering ?

Le Chaos Engineering, selon la définition de Netflix (Principles of Chaos), consiste à expérimenter en production pour prendre confiance dans un système distribué. Les systèmes distribués sont des systèmes complexes, sur lesquels sont menés un certain nombre d’actions pour les rendre résilients, et le chaos engineering permet de valider cette résilience, dans des conditions réelles. Il s’agit d’expérimentation, et non de test : valider que le système répond correctement, et de la manière dont on veut qu’il réponde. Cette validation ne peut se faire que dans des conditions de production. L’objectif n’est pas de casser la production, parce que les enjeux business sont importants, donc il faut faire en sorte que les expérimentations soient les moins impactantes possibles pour les clients. On va casser des éléments dont on sait qu’ils sont résilients.

Comment avez-vous initié une démarche Chaos Engineering chez OUI.sncf ?

Il y a deux ans nous ne parlions pas de chaos engineering mais de résilience. Nous avons commencé par faire un POC du Chaos Monkey (le chaos monkey arrête une instance sur un scale group Amazon, qui doit détecter la perte de performance et réallouer de nouvelles instances pour prendre la charge) de Netflix, que nous avons adapté à notre infrastructure. Le Chaos Engineering est nécessairement très spécifique à l’environnement de l’entreprise qui souhaite le mettre en oeuvre. Nous avons commencé nos premiers tests sur des environnements hors production, pour vérifier les hypothèses de départ. Ensuite, en production, nous vérifions que le composant réagit comme en test, mais également qu’il ne créée pas pas d’impact en cascade (également appelé effet papillon). Ces impacts en cascade ne peuvent pas forcément être observés dans des environnements hors production, parce qu’ils sont rarement 100% identiques aux environnements de production.

Comment avez-vous travaillé ensuite ?

Nous avons fait beaucoup de travail de sensibilisation et de culture, de façon à prendre en compte la possibilité des pannes dans l’application dès les phases de développement. Sur tout système en production, qu’il s’agisse d’un système informatique ou du corps humain, il y a toujours un moment où survient une panne. Est-ce qu’elle a été prévue ? Est-ce que le système est conçu pour gérer cette panne ? L’intérêt d’un outil comme le Chaos Monkey est de faire survenir cette panne plus tôt, et de s’assurer que le développement intègre l’arrivée certaine de cette panne en production. Nous ne sommes plus dans une démarche passive et corrective, mais dans une démarche pro active où la résilience est pensée en amont. Cela demande une vraie sensibilisation culturelle, et dans notre cas cette phase a duré plus d’un an.

Comment avez-vous fait progresser la culture du Chaos Engineering en interne ?

Nous avons expérimenté le premier Chaos monkey en production en mai 2017 : nous avons dû convaincre la direction que nous n’allions pas casser la production pour nous amuser. Puis nous avons mis en place les Days of Chaos pour continuer à inscrire le Chaos Engineering dans notre culture. Le Chaos Engineering vise à tirer des enseignements de l’expérimentation : on émet une hypothèse, que veut-on expérimenter et prouver ? Le périmètre choisi est le plus réduit possible de manière à éviter les effets de bord. Ensuite, après l’expérimentation, on mène une analyse. Est-ce que ça s’est bien passé ou pas ? Quels sont les résultats qui étaient attendus , inattendus ? Petit à petit, on élargit le périmètre, on change l’expérimentation, on l’enrichit.

Peux-tu nous donner un exemple d’expérimentation ?

Nous avons une application au cœur de notre système de distribution, qui est critique. Nous avions des latences sur la remontée d’erreur : il fallait 20 minutes pour détecter que l’instance était tombée, et que l’alerte remonte jusqu’au pilotage. Au fur et à mesure des expérimentations, nous avons constaté que cette durée était variable et pouvait aller jusqu’à 40 minutes. L’infrastructure pouvait tenir la charge, mais nous voulions savoir pourquoi. Nous avons réalisé que nous avions des double check, et le premier ne remontait pas d’alerte : potentiellement, l’instance pouvait redémarrer. Le 2ème check remontait l’erreur, mais les checks étaient espacés de 10 minutes. Dans ce cas, comment accélérer la remontée d’alerte pour s’assurer qu’en cas de problème on soit prévenu plus rapidement? Nous allons chercher à faire des vérifications supplémentaires dès le premier check : est-ce que l’instance est redémarrée, quel est l’état du serveur… et pouvoir dès la première vérification remonter l’erreur.

Quels sont les apports sur le long terme ? Comment cela a changé votre façon de travailler ?

Le concept de résilience est désormais bien connu de tous nos développeurs, qui l’ont intégré dans leur travail. C’est l’impact culturel que nous souhaitions, le concept de résilience oriente les infrastructures, les choix techniques, la manière de développer, et surtout les questions que se posent les développeurs. Nous espérons que sur le long terme les développeurs vont choisir les expérimentations, déterminer sur quel composant ils veulent valider une hypothèse. Et proposer des idées de scénario qui vont permettre d’avoir toujours plus de résilience sur les applications.

Quelles sont les bonnes pratiques ? Comment se lancer dans une démarche de Chaos Engineering ?

Je conseille de ne pas se lancer immédiatement dans une expérimentation en production, mais d’abord de se poser la question de la résilience de la globalité du système d’information. La résilience peut s’appliquer à beaucoup de niveaux différents : applications, infras, architecture, organisation. Chaque être humain est une production, on parle d’ailleurs souvent du “truck factor” (également appelé bus factor). Le truck factor est un élément de résilience organisationnelle que nous avons voulu mettre en évidence.

La gamification est aussi une approche à prendre en considération, pour ça nous avons aussi mis en place les Days of chaos, qui sont un entraînement au suivi de production proposé par les exploitants aux développeurs sous forme de gameday. L’idée est de faire prendre conscience de manière ludique aux développeurs de l’importance des outils de monitoring et de supervision dans le suivi de leur production. Les dashboards résultants doivent être spécifiques à chaque application et bien entendu maîtrisés par les équipes qui les exploitent. Concrètement nous avons fait un tournoi où chaque équipe jouait avec son application dans un environnement hors production et des pannes étaient déclenchées régulièrement. Le premier Day of Chaos a eu pour conséquence une réappropriation des outils de supervision par les équipes applicatives et une sensibilisation accrue à la résilience .

Pour se lancer dans une démarche de Chaos Engineering, la première question à se poser concerne donc le niveau de résilience global. Si le niveau est bon, on peut alors commencer par de petites expérimentations. Dans le cas contraire, si les équipes n’ont pas confiance, il faut déterminer pourquoi, et mettre en place des actions permettant de donner assez de confiance aux équipes pour lancer l’expérimentation en production.

Le Chaos engineering est vraiment un sujet culturel ?

Dans les années 2000, personne ne testait à part sur son poste. En 2007, on commençait à faire du TDD, mais pour beaucoup de managers c’était de l’argent perdu. Aujourd’hui il ne viendrait pas à l’idée de mettre en production sans tester. Nous sommes acutellement sur la même problématique pour la résilience, l’ensemble des pratiques et manières de développer doit prendre en compte la résilience. Nous allons développer en prenant en compte dès le départ le fait qu’il faut être résilient, et c’est un changement culturel important.

Cela implique également de beaucoup communiquer ?

Le chaos engineering demande beaucoup de communication : il faut communiquer sur ce que c’est, sur le pourquoi de la démarche et sur la résilience. Le but est que les gens adhèrent à la démarche. Si c’est imposé, ça ne peut pas fonctionner, il faut réussir à convaincre de l’intérêt de cette démarche, en s’appuyant aussi sur les aspects ludiques de l’expérimentation. La démarche de casser quelque chose pour prouver son bon fonctionnement est contre-nature mais elle est attire néanmoins. Il est plus compliqué de convaincre à haut niveau, les arguments ne sont pas les mêmes. On peut parler de l’impact financier, mais dans le contexte d’un changement culturel, le ROI n’est pas très pertinent. On peut par contre parler des économies potentielles, par rapport au temps de disponibilité d’une application en production. Nous connaissons le coût de l’indisponibilité, comment faire en sorte que cela coûte moins cher ? Le Chaos Engineering est une discipline émergente, donc il est nécessaire de communiquer et de rassurer, et de rappeler qu’au delà de son aspect ludique, le plus important est l’enseignement que l’on peut tirer des différentes expérimentations.

Pour échanger sur le sujet, rejoignez le Meetup Chaos Engineering