Tentative de vulgarisation de l’observabilité en informatique.

TL;DR : Ce texte explique qu’est-ce que l’observabilité et l’importance de l’observabilité pour les entreprises. Il distingue trois concepts clés — monitoring, supervision et observabilité — en mettant l’accent sur la manière dont l’observabilité permet une vision holistique et intégrée des systèmes informatiques. À travers un cas pratique d’un site de vente en ligne, il illustre comment l’observabilité aide à détecter et résoudre des problèmes complexes, impliquant diverses équipes (SRE, DevOps, Management, etc.). Le texte souligne l’importance de l’observabilité pour la collaboration efficace, la prise de décision éclairée et la gouvernance d’entreprise, tout en conseillant une approche plus accessible pour les décideurs avec peu de compétences techniques.

Qu’est ce que l’observabilité ? Redéfinissons les concepts !

Tout le monde parle d’observabilité et il existe déjà un grand nombre d’articles et de notes qui en font la définition. Les éditeurs et fournisseurs ont leur propre définition, souvent orientée pour la promotion de leur service. Les visions s’affrontent en fonction de paradigmes différents, parfois techniques, parfois produits. Nous proposons notre propre définition qui nous apparaît plus universelle, en évitant les mots valises et en prenant du recul.

Monitoring : Le monitoring se concentre sur la surveillance de mesures spécifiques et connues de serveurs. Historiquement, c’est la notion qui est apparue en premier. Sa portée est limitée aux serveurs individuels et aux applicatifs qu’ils hébergent. Les données recueillies sont quasi exclusivement techniques. En résumé c’est le déploiement d’agents de surveillance sur les serveurs, le recueil des valeurs relevées, leur stockage et leur visualisation. C’est l’étape numéro une de l’observabilité. Cela répond principalement aux besoins des équipes techniques infra (SRE / DevOps).

Supervision : La supervision est le monitoring d’un ensemble de serveurs coopérants mais aussi de leurs interactions logiques et des différents matériels permettant leur collaboration. C’est la surveillance de mesures spécifiques et connues de serveurs, flux, routeurs, load-balancers, onduleurs, firewall, clusters, sauvegardes, etc … Les données recueillies sont quasi exclusivement techniques. En résumé, c’est le déploiement d’agents de surveillance sur les éléments concernés, le recueil de valeurs relevées, leur stockage et leur visualisation. C’est l’étape numéro deux de l’observabilité. L’ensemble des valeurs relevées concernant une plateforme complète, les interactions et les dépendances entre éléments sont surveillés. Il est possible de faire des corrélations entre événements distants relevés sur différentes parties du système. Cela répond principalement aux besoins des équipes techniques dans leur ensemble (SRE / DevOps / Dev ) mais surtout aux besoins de pilotage et de gouvernance technique (Management Infra / Platform / Dev).

Observabilité : L’observabilité, c’est la supervision de la globalité d’un écosystème. On parle parfois de vision holistique qui est une approche selon laquelle la surveillance et l’analyse doivent partir de la totalité, de l’ensemble, du collectif, qui est plus que la somme des parties. C’est la dernière étape conduisant à l’observabilité. Cela inclut le monitoring de chaque serveur, la supervision des plateformes, mais en ajoutant de multiples sources d’informations (métric, log, tracing, APM, profiling, real user monitoring, synthétique monitoring) et en ajoutant également des monitoring non techniques (métier, business, delivery, déploiement, incident, recovery). Le tout permet de surveiller des plateformes complexes dans leur écosystème global. Cela répond aux besoins des équipes techniques (SRE / DevOps / Dev ), aux besoins de pilotage et de gouvernance technique (Management Infra / Platform / Dev), aux besoins métiers (BI, Finance, Marketing, Retail) et produits (Product Owner / Manager) et aux besoins gouvernances business de tous les acteurs de l’entreprise sur la base métriques porteuse d’un sens commun (Product / Customer support / Technical account management / C level).

Une réelle synergie émerge où chacun se rend compte des enjeux et contraintes des uns et des autres.

Pourquoi dépasser la supervision pour aller vers l’observabilité ?

Autrement dit, qu’est ce que la surveillance des sources d’informations et des métriques en provenance d’autres domaines que l’infrastructure et l’hébergement d’application va apporter comme plus value à l’entreprise ?

Partons d’un retour d’expérience sur l’observabilité que nous avons constaté sur un site de vente en ligne.

Dans les dernières 24h, le support client note une hausse des questions portant sur la validation des achats. Un plus grand nombre de clients rencontre des problèmes à la validation de leur achat et ne semble pas savoir si la commande a été passée et si le paiement a été effectué. Ce nombre de questions est basé sur le nombre de tickets support ouverts avec le label “Problème paiement” dans la dernière heure.

Toujours dans les dernières 24h, le product owner service paiement, au sein de l’équipe de développement du même nom, note une hausse des paniers abandonnés. Le nombre de paniers abandonnés est calculé toutes les 5 min sur la base du nombre de paniers activés (avec au moins 1 item dedans) et qui a expiré (15 min sans activité de la session client).

L’engagement (SLA) de l’équipe paiement est un taux de disponibilité de 99.9%, soit 1,26 minute d’indisponibilité par 24h. Ce taux de disponibilité est basé sur un scénario de synthetic monitoring qui reproduit la session d’un utilisateur achetant un item. Ce test est joué toutes les 5 min et il conduit à l’achat du même item à chaque fois. L’achat est annulé par la suite automatiquement par une procédure de back-office. Cet indicateur de niveau de service (SLI) est actuellement de 99,4% sur les 7 derniers jours glissants. Cela représente 8 minutes et 38 secondes d’indisponibilité. L’hypothèse de l’équipe paiement pour expliquer la différence entre l’objectif et la réalité constatée est que le déploiement est en cause. Cette hypothèse a été partagée avec les DevOps en charge du CI/CD.

CI/CD fait justement l’objet de surveillance. Le temps de déploiement, le temps de retour en arrière sur la version précédente en cas d’incident (une action faite systématiquement en cas d’incident) et la fréquence de déploiement font l’objet de métrique dans le système d’observabilité. Le temps de déploiement et la fréquence de déploiement n’ont pas significativement varié depuis une semaine et il n’y a eu aucun incident conduisant à un retour en arrière. Les DevOps jugent peu probable que l’hypothèse de l’équipe paiement soit validée et ils ont partagé l’information.

Le product owner service paiement se concentre alors sur le module de real user monitoring (RUM) de l’outil d’observabilité qui relève l’ensemble des actions sur les navigateurs client sur un échantillon de 10% des sessions. Le mode échantillonnage a été privilégié pour réduire les coûts d’observabilité. Relever toutes les actions sur les navigateurs client pour 100% des sessions aurait un coût démesuré. Avec l’aide du support, sur une sélection de cas, en corrélant date, heure et id client, des sessions enregistrées sont retrouvées dans le RUM. Dans 100% des sessions enregistrées corrélées à un incident remonté au support, l’action de validation du paiement n’a pas obtenue de réponse de la plateforme.

Le support et l’équipe de développement paiement se tournent alors vers le module d’application performance monitoring (APM) de l’outil d’observabilité. L’APM permet de visualiser et explorer le chemin d’exécution complet d’une requête entrant sur la plateforme. L’APM est également configuré pour n’enregistrer que 10% de requêtes entrantes pour les mêmes raisons que le module RUM. Les sous-requêtes entre services, des différents appels et durées d’exécution sont disponibles. Ceci a été rendu possible car l’équipe de développement paiement a instrumentalisé ses services avec l’aide du Technical Account Manager de l’outil d’observabilité. Les ID de requêtes RUM (côté navigateur) sont reprises par le module APM, les mêmes 10% d’activités sont donc enregistrés. Il est donc possible de suivre de bout en bout une requête. Les appels navigateur sont retrouvés et une sous-requête au service de remise est identifiée comme n’obtenant pas de réponse, ce qui conduit le service de paiement à ne pas répondre à l’action côté navigateur faute d’information.

L’équipe SRE est consultée. Elle note que le nombre de containers de chaque service est correct et que le seuil supérieur de consommation de mémoire est parfois brièvement dépassé mais que tout revient dans l’ordre rapidement. Ces valeurs de monitoring sont relevées directement auprès des agents de monitoring installés sur le cluster de hosting toutes les 30 secondes. En regardant de plus près il est constaté que c’est spécifiquement l’unique container du service de validation de remise qui surconsomme de la mémoire.

L’ensemble des acteurs conclut que le code a une fuite mémoire. La taille de la mémoire utilisée augmente à chaque demande de validation de remise gérée. Jusqu’à atteindre la mémoire maximum utilisable par le container hébergeant le code. L’ordonnanceur de container à la limite maximum de mémoire autorisée tue le container et en relance un nouveau. Tous les cas de non réponse à l’action de validation du paiement par le client sur son navigateur, relevés dans le module RUM et APM, ont eu lieu durant un changement de container du service de validation remise pour surconsommation mémoire.

Immédiatement, un retour en arrière sur la version précédente du service de validation remise est envisagé. Le service n’ayant pas de couplage fort avec le service de validation paiement, ceci est donc réalisé. La perte de fonctionnalité est mineure et porte sur un unique partenaire sur une campagne de promotion. L’équipe marketing est informée et l’arrêt de la campagne sera décalé autant de temps que nécessaire après que le code du service de validation remise soit réparé de cette fuite mémoire.

Aller vers l’observabilité pour faire émerger une synergie entre les acteurs autour de données communes.

Suite à cet incident, une réunion d’autopsie est conduite avec l’ensemble des acteurs sur la base du constat effectué. Les différents acteurs ont recherché les actions suivantes correctives possible:

• Le lead technique de l’équipe de développement paiement s’engage à corriger la fuite mémoire (DEV).
• Le product owner de l’équipe de développement paiement décide que le service validation paiement doit gérer le cas de non réponse du service de validation remise. Il est décidé que le service de paiement fera deux tentatives de validation remise et en cas de non réponse annoncera que la remise n’est pas validée. Le travail sera entrepris à la prochaine itération de l’équipe et la fonctionnalité ajoutée dans le code du service paiement. (PRODUIT)
• L’équipe de développement paiement comprend que son SLA basé sur un scénario de synthetic monitoring n’est pas optimum et décide de prendre comme référence les informations du module APM de l’outil d’observabilité sur le service paiement. (DEV)
• L’équipe SRE décide d’un changement dans l’hébergement du service de validation remise. Celui-ci ne doit pas dépendre d’un unique container mais de plusieurs containers, même si la charge de travail ne le justifie pas. La charge de travail de doit être répartie équitablement entre chaque container. Chaque container devant être instancié tous les 15 secondes au changement de version pour prévenir l’indisponibilité de tous en cas de nouvelle fuite mémoire. (OPS)
• L’équipe finance utilise le module APM avec l’aide de l’équipe SRE pour retrouver l’ensemble des requêtes au service de validation remise ayant échoué. En tenant compte que seul 10% des requêtes sont enregistrées, on fait une estimation sur la base du panier moyen pour calculer l’impact financier. L’incident est apparu dans les dernières 24h et le cas est rare. L’impact est très faible, ce qui rassure tout le monde. (Business)

Tous les acteurs travaillant avec le même outil, il n’y a pas de rupture de vision. Les corrélations fastidieuses entre les informations provenant de différents outils ont été évitées. Les données sont communes et interdépendantes. Les liens de causalité et d’interdépendance sont immédiatement à disposition. Les adhérences et frictions dans la recherche et l’analyse sont minimisées. L’ensemble des acteurs, quel que soit leur prisme de lecture, est aligné sur les mêmes données elles-même disposées sur une échelle de temps commune.

Aller vers l’observabilité pour parfaire la gouvernance.

La gouvernance a toujours eu besoin d’informations pour baser ses décisions. La gouvernance par la donnée pour piloter une production industrielle, une chaîne logistique ou une politique de prix est maintenant une chose entendue. Il est désormais possible de gouverner une activité numérique sur le même modèle, en abandonnant la supervision du seul domaine technique pour l’observabilité, où les métiers, le business et le management de la productivité des équipes de développement ont toute leur place.

Il ne s’agit pas de fusionner la data analyse, le business intelligent et la supervision. Les outils d’observabilité sont conçus pour gérer des données sur un temps court avec un fort rafraîchissement. Dans l’exemple, nous parlons de 24h d’incident, d’échantillonnage de 10% et d’un rafraîchissement des informations toutes les 30s. Gérer un historique de vente, fixer un prix ou packager une offre n’est pas de l’observabilité.

L’intégration de métriques autres que techniques permet de surveiller l’apparition de symptômes de dysfonctionnement. Une baisse soudaine du nombre de paniers validés, d’inscriptions, ou de bons de livraison sont des méta-indicateurs d’un problème sous-jacent. Cela permet de mieux surveiller la qualité du produit numérique, son design, le dimensionnement de son infrastructure, mais aussi de mieux saisir les effets de bord et les impacts financiers.

Il est possible d’aligner les équipes et de les faire fonctionner de façon synchrone :

• en permettant de réunir l’ensemble des acteurs l’observabilité
• en ayant des dashboards globaux ou des dashboards dédiés à une activité ou à un workflow de travail
• en ayant un système d’alerting routant les notifications à la meilleur compétence
• en matérialisant les effets et conséquences des choix de chacun.

En permettant de réunir l’ensemble des acteurs l’observabilité avec des dashboards globaux ou des dashboards dédiés à une activité ou encore à un workflow de travail ainsi qu’un système d’alerting routant les notifications à la meilleur compétence, il est possible de matérialisé les effets et conséquences des choix de chacun et d’aligner les équipes en les faisant fonctionner de façon synchrone. Les bénéfices sont nombreux:

• la communication est plus directe
• les données sont communes
• les visualisations sont à disposition de tous et non plus cloisonnées
• la productivité est mesurée par le nombre de déploiements et leur fréquence
• La qualité est mesurée par le nombre d’incidents, leur durée et le rayonnement de leur effet.

Une direction exécutive visualisera les ralentissements des mises en production, l’augmentation des incidents et donc la baisse de qualité, voire même leur effet. Elle pourrait voir les changements de planification des projets pour faire de la place à des actions correctives. Elle pourrait mesurer les différents coûts (temps, ressources). En cela l’observabilité est un outil de gouvernance.

Glossaire

• SRE (Site Reliability Engineering) : Discipline qui incorpore des aspects de l’ingénierie logicielle dans l’infrastructure informatique et les opérations pour créer des systèmes hautement fiables et évolutifs.
• DevOps : Pratique qui vise à unifier le développement logiciel (Dev) et les opérations informatiques (Ops), mettant l’accent sur la communication, la collaboration et l’automatisation pour améliorer la vitesse et la qualité du développement et du déploiement des logiciels.
• SLA (Service Level Agreement) : Accord formel entre un fournisseur de service et son client définissant le niveau de service attendu, souvent avec des métriques spécifiques comme la disponibilité ou le temps de réponse.
• APM (Application Performance Monitoring) : Technologie et outils utilisés pour surveiller et gérer la performance et la disponibilité des logiciels applications, en fournissant des informations détaillées sur la façon dont les applications fonctionnent et sur les problèmes potentiels.
• RUM (Real User Monitoring) : Technique de surveillance de l’expérience utilisateur qui capture et analyse chaque transaction des utilisateurs finaux avec une application web ou mobile.
• CI/CD (Continuous Integration/Continuous Deployment) : Pratique de développement logiciel où les changements de code sont automatiquement testés et déployés, permettant une livraison rapide et efficace de nouvelles fonctionnalités et mises à jour.
• Synthetic Monitoring : Technique de surveillance qui simule les actions des utilisateurs pour tester les performances des applications web ou mobiles, souvent utilisée pour anticiper les problèmes avant qu’ils n’affectent les utilisateurs réels.
• Container : Méthode de virtualisation au niveau du système d’exploitation pour déployer et exécuter des applications distribuées sans lancer une machine virtuelle entière pour chaque application.
• Back-office : Partie de l’entreprise ou du système informatique qui est dédiée à la gestion administrative, et qui ne fait pas partie de l’interaction directe avec les clients.

Note de l’Auteur : La réalisation de ce document a été soutenue par l’utilisation de plusieurs outils et ressources précieuses. J’ai bénéficié de l’assistance de ChatGPT pour l’organisation du texte et l’élaboration de certains concepts techniques (15% de l’article). La mise en page et le design graphique ont été effectués grâce à Canva, tandis que la rédaction et la compilation des documents se sont faites sur Google Docs. De plus, les formations proposées par les entreprises Grafana, DataDog et Dynatrace ont été des ressources essentielles pour assurer l’exactitude technique de ce document.