Dans le cadre de l’évolution de l’exploitabilité de notre SI, nous sommes passés par plusieurs phases depuis une normalisation des logs pour unifier nos capacités de monitoring jusqu’à la définitions d’indicateurs plus précis. Le Chaos Engineering aura été un outil décisif pour mettre à l’épreuve notre monitoring. Outil de validation et d’amélioration continue de la résilience, il nous a démontré sa capacité à nous permettre d’évaluer notre niveau d’observabilité.

Un besoin d’améliorer l’observabilité

Voyages-sncf.com, devenu Oui.sncf depuis fin 2017, gère la vente de l’ensemble des billets de la SNCF. Ceci inclut le site internet, l’application mobile et le backend de la vente de billets depuis d’autres canaux de distribution tels que les BLS (bornes libre-service, ou aussi boites jaunes en gare), les guichets (Point de vente Mosaïc) ou nos concurrents.

La digitalisation de la vente des billets (train ou avion) a significativement augmenté le volume de nos ventes ces dernières années imposant des changements profonds d’architecture (micro-services et conteneurisation) et de méthodes de développement (agilité). Nous avons pris le virage des micro services depuis quelques années maintenant et la grande hétérogénéité des applicatifs de notre système d’information nous a amené à changer nos approches quant à la manière de récupérer des informations sur l’état de nos applications.

Normalisation des logs

Nous disposions déjà d’outils de monitoring mais ceux-ci étaient plus adaptés aux aspects système, notamment au travers de la surveillance des consommations de ressources standards telles que le CPU, la mémoire ou l’espace disque. Notre objectif était simple : pouvoir auditer, au travers de logs applicatives normalisées, les temps d’exécution de nos services sans avoir à faire d’introspection. Nous avons logiquement appelé ces types de logs « auditoutline ». Chaque service doit être audité en donnant des informations précises et obligatoires : nom de l’application, nom du serveur, nom du service, temps d’exécution (différence entre heure d’entrée et heure de sortie) et surtout un correlationId nous permettant de tracer la vie complète d’une requête utilisateur.

Nous pouvons ainsi à la fois disposer d’informations sur les temps de fonctionnement mais aussi des statistiques sur la consommation de nos services. Nous développons plus de 150 applications et pour certaines le volume de ces logs est assez conséquent. L’utilisation d’une stack big data est inévitable pour les stocker et pouvoir les exploiter à la fois dans le cadre du monitoring et après coup pour les analyses techniques et statistiques.

Informations techniques et métier

Il est très important ici de rappeler un point primordial sur le monitoring : ce n’est pas parce que les indicateurs techniques sont verts que cela signifie que l’application fonctionne. La surveillance des services au travers des auditoutline nous permet aussi de tirer des informations métier. Ainsi, un de nos indicateurs clé calculé après coup depuis les stockages de nos logs, correspond au ratio entre le nombre de recherches et celui des ventes effectives, le « look to book ». Utile d’un point de vue métier pour déterminer le taux de transformation, il peut se métamorphoser en indicateur technique décisif pour traquer le « scrapping« .

Le scrapping est une technique utilisée par certains moteurs de référencement ou concurrents pour aspirer l’ensemble des tarifs d’un site. Il nous coûte particulièrement cher! La solution est de débusquer au plus vite les scrappers et de bloquer leurs IP pour éviter une sur-utilisation non rentable de notre infrastructure.

Limite d’utilisation des logs et de leur exploitation

Nous avons vu qu’en corrélant les logs nous pouvons faire des déductions et tirer des informations métier depuis des informations à priori techniques. De la même manière nous pouvons recalculer certains indicateurs techniques statistiques en retravaillant les valeurs dans leur ensemble. Cependant, au delà d’une certaine volumétrie, se posent des contraintes de traitement qui nécessitent parfois une débauche de puissance de calcul mais aussi d’énergie et de temps pour développer ces traitements. Nous en arrivions même à être en inadéquation avec le volume d’affaire réellement traité. La valeur que nous tirons de ces analyses n’en vaut pas toujours le prix.

La solution qui nous est apparue a été d’accepter une dénormalisation de certains indicateurs et de la manière de les calculer. A charge de chaque équipe de définir ses propres indicateurs et la manière de les produire directement au cœur de leurs applications.

Un bon exemple d’indicateur technique calculé directement au cœur des applications est l’indicateur percentile. Le percentile est le tri des valeurs d’un ensemble sur une base de 100. Dans le cas du 90ème percentile cela revient à regrouper les valeurs de telle manière que 90% des valeurs sont inférieures à celles représentées par le 90ème percentile et 10% supérieures. Appliqué au temps de réponse d’un service, nous pouvons donc savoir que 90% des utilisateurs auront un temps de réponse inférieur à cette valeur de référence. Cet indicateur est donc beaucoup plus précis qu’une moyenne car il donne une idée de la représentativité des valeurs « acceptables au maximum » en excluant les extrémités de la courbe. Couplé à la moyenne et au maximum nous devenons capables de déterminer si les temps de réponse sont (trop) irréguliers et indiquent un fonctionnement anormal. Pour calculer le 90ème percentile d’un temps de réponse il faut disposer de l’ensemble des valeurs sur une durée pour pouvoir les trier. Ce n’est possible qu’en récoltant et en retravaillant ces données dans la masse, et il faut le faire pour tous les temps de réponse qui nous intéressent! Nous avons donc décidé de laisser les équipes choisir d’utiliser ou non une librairie maison de statistiques calculant ces temps : moyenne, maximum et 90 percentile (mais aussi d’autres percentiles). Nous avons perdu l’information d’ensemble mais l’avons remplacé par un 90ème percentile par instance plus précis qu’il reste possible d’agréger. Inutile alors de devoir faire de coûteux traitements Big Data type « map reduce » sur de grandes quantités de données et de devoir le refaire pour chaque application et chaque temps utile. Les données sont collectées et calculées au cœur des applicatifs.

De l’utilité des indicateurs et de leur exploitation

Le plus difficile lors de la définition des indicateurs est de savoir s’ils seront pertinents, utilisés et utilisables :

• Pertinents car ils doivent apporter une information compréhensible, comportementale et représentative de l’application/système.
• Utilisés car ils doivent être utiles et jugés comme tel au quotidien.
• Utilisables car suffisamment précis et facilement interprétables par le plus grand nombre.

Le meilleur moyen que nous avons trouvé pour valider ces trois conditions est de les mettre à l’épreuve du feu. C’est en les utilisant en conditions réelles qu’on peut déterminer l’utilité des indicateurs. Nous pouvons pour cela les « laisser vivre » en production et ajuster le tir en amélioration continue. C’est la solution par défaut de la plupart des équipes et entreprises. Elle présente pourtant un désavantage considérable : les indicateurs ne sont optimisés qu’avec le temps et offrent un risque opérationnel fort lors de l’exploitation des applications à leur début. Pour pallier à ce désavantage, nous avons choisi un autre moyen d’accélérer cette validation et d’améliorer les indicateurs, le Chaos Engineering.

Définition et intérêt du Chaos Engineering

La définition du Chaos Engineering, telle que proposée par Netflix sur le site Principles of Chaos est la suivante : « Le Chaos Engineering est la 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.« 

Pour clarifier cette définition qui, bien qu’elle soit très précise, peut passer pour ambiguë, nous pourrions la reformuler ainsi dans le contexte actuel : « Le Chaos Engineering est la discipline de l’expérimentation par la destruction ou la dégradation partielle des composants d’une infrastructure de production en vue de vérifier sa résilience. »

Cette discipline a été propulsée sur le devant de la scène notamment grâce au « Chaos Monkey » de Netflix. Le Chaos Monkey est une application qui se comporte comme un singe qu’on lâche dans un datacenter et qui va causer des pannes au hasard de ses allées et venues. Ainsi le Chaos Engineering est « l’art de créer des pannes » en production pour valider la résilience globale, « dans la vraie vie », d’un système d’information. Tout système subira forcément à un moment de sa vie une altération empêchant son bon fonctionnement. La vraie question n’est pas de se demander si le système va planter, ni même quand il va planter. La vraie question est de savoir ce qu’on peut faire pour que le système continue de fonctionner quitte à basculer en mode dégradé. En provoquant des pannes au hasard et en continu, le chaos monkey ne va pas laisser le choix aux concepteurs du système, qu’ils soient développeurs ou exploitants ou autre, que de prévoir des mécanismes de protection, de contournement ou d’auto-réparation.

Le Chaos Engineering, de la résilience à l’observabilité

Initialement notre démarche de Chaos Engineering visait en premier lieu à sensibiliser les équipes à la résilience de leurs applications. Après avoir développé notre Chaos Monkey « maison » ainsi que toute une palette d’outils permettant de varier les expérimentations il s’est avéré que proposer ces outils, aussi amusants ou innovants et puissants soient-ils, ne suffisait pas à permettre l’essor du sujet de la résilience que nous espérions.

Nous avons alors initié les « Days of Chaos », un Gameday de résolution de pannes sur les environnements des développeurs, en nous inspirant d’un article de Jesse Robbins, ancien pompier et initiateur du concept de Gameday. Nous avons adapté et étendu le concept initial des Gamedays en appliquant la résolution des pannes directement aux applications maintenues par les équipes et en transformant le jeu prévu pour quelques équipes à un événement d’entreprise global.

L’objectif pour les équipes était d’appliquer systématiquement les trois étapes de la résolution d’une erreur : Détection, Diagnostic, Résolution. Vous pourrez constater que les deux premières étapes sont entièrement axées sur le monitoring et l’analyse de l’état du système. A des fins de promotion de la résilience, nous avons donc commencé par promouvoir l’importance de pouvoir observer le système pour pouvoir ensuite agir correctement dessus : on ne peut corriger que ce que l’on peut mesurer.

Il y a clairement eu un avant et un après  » Days of Chaos « Chapter One «  (nous en avons fait 3 à ce jour). Des dashboards génériques nous sommes passés à la customisation et à la réflexion sur l’utilité des indicateurs et de leur traitement. Nous pouvons ici parler d’une prise de conscience dans le sens ou les comportements face à la problématique du monitoring ont été profondément changés. De la relative indifférence nous sommes passés à la proactivité et à la remise en question régulière.

La sûreté de fonctionnement, véritable objectif du Chaos Engineering

Comme nous l’avons vu dans sa définition initiale, avec le Chaos Engineering il est question de « confiance ». La résilience est un vecteur de confiance mais ce n’est pas le seul. D’où l’émergence d’une autre discipline dont le Chaos Engineering est le corollaire : la sûreté de fonctionnement. La sûreté de fonctionnement peut se définir comme la propriété qui permet aux utilisateurs d’un système de placer dans le service qu’il délivre une confiance justifiée. Par extension la sûreté de fonctionnement est la discipline qui étudie cette propriété, nous pouvons ainsi la considérer comme la « science des défaillances et des pannes« .

La confiance repose sur un ensemble des facteurs pouvant varier d’un environnement à l’autre. Quatre grands facteurs sont des piliers de base : fiabilité, maintenabilité, disponibilité, et sécurité. Ces facteurs peuvent être enrichis en fonction de l’environnement : Intégrité, Résilience, Confidentialité, Testabilité, Diagnosticabilité, Observabilité, etc… C’est à chacun de définir pour son environnement les facteurs et leur ordre d’importance. Dans certains cas certains de ces facteurs sont gérés de manière native par les méthodes de travail, dans d’autres cas il faut fournir des efforts pour les mettre en avant.

La création de perturbations que propose le Chaos Engineering dans l’environnement de production permet de « tester » directement le niveau de résilience du système et de manière indirecte les aspects Diagnosticabilité et Observabilité. Il répond à la question de la capacité des intervenants à voir s’il y un problème dans le système, ce qui n’est pas toujours le cas même lors d’une perturbation avérée comme nous avons nous même pu nous en apercevoir. De la même manière il permet de juger de la pertinence, de l’utilisation et de l’utilisabilité des indicateurs en les mettant à l’épreuve.

Le Chaos Engineering au service du développement de l’observabilité

Le Chaos Engineering ne se limite pas à chercher à accroître le niveau de résilience d’un système. La plupart des composantes de la sûreté de fonctionnement, et en particulier l’observabilité, peuvent faire l’objet des expérimentations qui seront toujours spécifiques au système,aux infrastructures, aux applications. Avoir recours au Chaos Engineering paraît, à défaut d’être indispensable, un puissant outil au service du développement de l’observabilité du système.

Cet article est tiré du E-book « Observabilité : Analyser et comprendre les applications à l’ère du Cloud », téléchargeable gratuitement à cette adresse.