La parole est aux speakers : Nicolas Perussel
Jusqu’à l’AFUP Day 2025, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Chaos Engineering : venez, on va s'empoisonner !Discipline pratiquée principalement par les géants du web tels que Netflix, Linkedin ou encore Shopify, le Chaos Engineering est une pratique d'évaluation de l'impact de perturbations sur un environnement, provoquée de façon volontaire et contrôlée via l'introduction de dysfonctionnement dans cet environnement. Pour vous la faire simple, c'est l'art de mettre la panique dans les systèmes afin d'en étudier le comportement. Les objectifs de ce "Chaos" sont la recherche d'une fiabilité ainsi que l'assurance d'une bonne résilience. La prod ne doit pas tomber, c'est l'objectif, peu importe la tempête à traverser. À travers un cas concret, je vous partagerai mon expérience sur la mise en place d'un empoisonnement volontaire des connexions réseaux afin de simuler au plus proche les conditions de l’environnement de « production » et ainsi jouer les suites de tests liées, découvrir les erreurs dans le but d’optimiser nos connections TCP vers les systèmes concernés et améliorer nos perfs ! Cela permettra également de découvrir quelques solutions afin de rendre nos architectures et infrastructures plus résilientes lorsque des briques essentielles de l'infrastructure tombent ! Tout un programme. |
Maurice 16/05/2025 16:40-17:20 |
Faut-il réaliser des tests risqués en production, malgré le risque d’impact sur le service, ou vaut-il mieux se limiter à la préproduction, quitte à investir pour reproduire au mieux les conditions réelles ?
Ah là là, c’est une très bonne question! Dans la mesure du possible, il faut veiller à ce que les environnements de développement et de recettes soient iso-production. Alors oui, cela a un coût, mais c’est tellement plus confortable pour « debug » et « tracker » les problèmes. Cela permet d’effectuer des stress tests, d’éprouver les briques d’infrastructure etc… Cependant, la production se teste d’elle-même !
Si un souci intervient en production, c’est qu’il y a eu une faille en amont (et ça arrive souvent, mais ça tu le sais déjà). Donc pour répondre à la question, il ne faut pas stresser d’éprouver la production même si ce terrain de jeu doit être méticuleusement préparé. Dans l’idée, load balance une partie du trafic sur une partie spécifique et regarde ce qui se passe. Si tout va bien, agrandis le scope et observe.
Tout le monde n’est pas Netflix ou Amazon, une coupure de quelques minutes n’est pas si vitale.
Quels prérequis sont essentiels avant de réaliser ce type de test ? Logs, monitoring, tracing… ?
Dans l’idéal et si vous en avez les moyens, il faut viser l’observabilité totale. Être en mesure de suivre la requête HTTP de bout en bout, de tracer tout ce qui peut l’être.
Les logs sont cruciaux mais il faut qu’ils soient correctement valorisés, c’est dès le design de l’application qu’il faut prendre cela en compte. Le monitoring est un ange gardien, avec les bonnes sondes et les bonnes alertes, il permet d’être préventif et non réactif. Donc oui, un APM est essentiel, il permet d’avoir une surveillance globale sur toutes les couches.
De mon point de vue et pour les projets d’envergure, le end-to-end tracing est une feature obligatoire pour la production.
Les projets ne sont pas tous de la même taille et les équipes n’ont pas toutes les même niveau de séniorité. Dans quels cas conseillerais-tu ce genre de tests pour un retour sur investissement optimal ?
Pour moi, c’est une affaire de tous et toutes. DevOps ou SRE c’est un état d’esprit. Il se diffuse donc dans les esprits par la pratique et l’encadrement. C’est vraiment un mindset à insuffler.
La pratique de Game Day, à petite ou grande échelle, est un bon investissement car elle permet d’émuler des situations de stress, d’étudier les pistes de réflexions de résolution de problème et permet au final de travailler la résilience humaine. Tout se prépare et se travaille au final.
Une conférence présentée par
 Nicolas PERUSSEL |
Passionné par les nouvelles technologies, il est féru d'architecture logicielle. Sa spécialité : le développement web et les bonnes grosses architectures 😉 « Accro au technos », il aime se diversifier dans divers domaines pour être toujours plus efficace et compétent. Actuellement, il est en charge de la direction de l'équipe PHP chez ekino (CTO). Architecture, industrialisation, PHP (Symfony / Drupal), encadrement, formation sont ses activités quotidiennes ! Vous l'aurez compris, ses domaines de prédilection sont les casse-têtes architecturaux, les motifs de conception et le café ! |