Bienvenue dans l’épisode 7 de Data Talks, la série vidéo de Splunk dans laquelle des experts de la donnée décryptent pour nous les nouvelles tendances autour de la data. Nous retrouvons aujourd’hui un des spécialistes français de la donnée et de l’ITOps, Stéphane Estevez, alias M. Observabilité chez Splunk.
Au cours de ses vingt années d’expérience dans le monde de l’IT, cet expert de la gestion et du marketing produit a eu l’occasion d’observer les nombreuses évolutions du secteur avant de rejoindre Splunk, en 2018, en tant que directeur EMEA Product Marketing, Observability & IT Markets. C’était donc l’expert tout trouvé pour parler de l’une de ses spécialités : l’observabilité.
SOMMAIRE
Définition de l’observabilité
Principes fondamentaux de l’observabilité
Bénéfices de l’observabilité
Outils de l’observabilité
Bonnes pratiques en matière d’observabilité
Ecueil en matière d’observabilité
Futur de l’observabilité
La question est loin d’être aussi simple qu’il n’y paraît, car on ne dispose d’aucune définition claire faisant référence dans le secteur. Pour bien appréhender ce concept, il est donc nécessaire de comprendre d’où il vient, à quoi il sert et comment il est utilisé.
Tout d’abord, il est important de rappeler que l’observabilité n’est pas un mot nouveau, même s’il a pris un tout autre sens dans le monde du DevOps. Il a en effet été emprunté à la théorie du contrôle, un champ des mathématiques appliqué à l’ingénierie industrielle, développé dans les années 1960. Mais c’est en 2013 que le terme apparaît pour la première fois dans le domaine de l’IT, à une époque où les environnements distribués et le cloud modifient en profondeur notre manière de développer les applications.
Le mot d’ordre est dès lors aux microservices et aux conteneurs, qui augmentent certes les ressources de calcul, mais génèrent aussi une plus grande complexité. Le monitoring traditionnel ne permet tout simplement plus de couvrir les nombreux angles morts de ce nouvel environnement très prolifique en matière de données. L’observabilité est donc née du besoin des équipes DevOps d’accéder à ces inconnues pour mieux comprendre leur infrastructure.
Comme on le dit souvent, une image vaut mieux que mille mots, et il existe justement un exemple classique qui explique très bien ce qu’est l’observabilité : le biais du survivant. Il s’agit d’une erreur de logique très commune décelée par Abraham Wald au cours de la Seconde Guerre mondiale. L’idée est simple : pour améliorer leurs avions, les Anglais avaient décidé d’observer les appareils de retour à la base et de renforcer le blindage des zones contenant le plus d’impacts de balles. Le résultat fut décevant, et pour cause ! Les ingénieurs se concentraient sur les avions « survivants », au lieu de s’intéresser à ceux qui étaient tombés au combat.
Cet exemple illustre à merveille l’état d’esprit de l’observabilité, qui consiste à aller chercher ces données encore inconnues afin d’optimiser les opérations, au lieu de se contenter de ce que nous avons toujours eu sous les yeux.
Pour y parvenir, les équipes DevOps s’appuient sur trois piliers :
Toutes ces données se révèlent essentielles pour superviser efficacement les nouveaux environnements distribués dans lesquels nous évoluons. Contrairement à d’autres, je ne vois donc pas de raison de mettre l’observabilité et le monitoring en concurrence, les deux approches étant plutôt complémentaires.
Une des conditions fondamentales pour qu’un système soit observable repose sur l’accessibilité des données collectées. Et dans les environnements hybrides d’aujourd’hui, la tâche est souvent loin d’être aisée. Il est en effet nécessaire de recourir à de nombreux outils différents pour traiter les métriques, les traces et les logs provenant des systèmes hérités ou du cloud.
Mais la question de l’outillage n’est que la première étape du processus. Il faut également s’assurer que les équipes IT soient en mesure de naviguer dans ces données afin de pouvoir traiter efficacement les incidents. Malheureusement, les outils que nous utilisons sont encore très isolés, et leur décloisonnement est certainement un des plus grands défis de l’observabilité.
Tout d’abord, il faut reconnaître que le marketing est parfois un peu poussif sur la question et que chacun y va de sa propre définition pour mettre en avant ses solutions. C’est d’ailleurs une des raisons pour lesquelles je préfère parler d’état d’esprit. Mais cette approche commerciale n’enlève rien à la pertinence de l’observabilité d’un point de vue technique.
Notre conception du code et du monitoring a beaucoup évolué avec l’avènement des microservices, et les entreprises qui n’adaptent pas leurs pratiques perdent continuellement des données et du terrain sur la concurrence. Par exemple, ces microservices sont très distribués par principe et environnements nous rendent donc particulièrement dépendants du réseau, dans la mesure où ils doivent sans cesse dialoguer entre eux pour assurer la continuité et la qualité de l’expérience utilisateur. Le problème est qu’ils sont souvent déployés dans un cloud public où nous perdons l’accès direct au matériel réseau qui n’est plus notre propriété mais celle du prestataire, rendant le réseau moins “observable”, il faut donc trouver d’autres moyens pour collecter la donnée provenant des couches basses du réseau. La résolution des incidents est également beaucoup plus délicate à gérer que dans une architecture monolithique où tout reste cloisonné dans le monolith.
Ces changements technologiques ont donc généré une certaine complexité, et les données sont dorénavant des repères incontournables, même si elles ne sont pas toujours facilement accessibles. Il suffit de s’intéresser à la question du monitoring à l’ère du cloud pour s’en rendre compte. Les organisations s’appuient en effet de plus en plus sur des solutions cloud, qui sont loin de mettre l’ensemble de leurs informations à disposition de leurs clients.
Accéder à ces données en temps réel constitue dès lors un enjeu majeur pour les entreprises qui souhaitent moderniser leurs applications et leur infrastructure. Et ont-elles vraiment le choix lorsque 86 % des Français avouent pouvoir renoncer à un achat à cause d’un bug ?
Quel que soit le fournisseur choisi, les entreprises devront mettre en place un certain nombre d’outils de base pour rendre leur système observable, notamment en ce qui concerne la réception des données. On peut les classer en quatre catégories :
Ces outils modernes de gestion des performances applicatives (APM) permettent de suivre le cheminement des utilisateurs dans des environnements de type microservices.
C’est dans les logs que se cache la cause première des incidents. Il est donc essentiel de disposer d’un outil efficace permettant de répertorier et de traiter ces informations.
Des solutions de monitoring classiques permettent généralement de prendre en charge les métriques.
La pandémie de COVID-19 a considérablement accéléré notre transformation numérique et, en Europe, 55 % des interactions avec les clients sont désormais digitales. Dans ce contexte, les nouvelles attentes des utilisateurs ont entraîné un regain d’intérêt pour des outils autrefois très populaires, et depuis tombés en désuétude. C’est notamment le cas du real user monitoring et du synthetic monitoring, qui permettent d’avoir une visibilité permanente sur des éléments situés hors du contrôle de l’entreprise (opérateurs de téléphonie, appareils, etc.).
Tous ces outils sont essentiels pour disposer de données exploitables, mais encore faut-il être en mesure de les collecter en amont. Et la tâche n’est pas aisée lorsque l’on considère que chaque solution nécessite, entre autres, d’installer un agent qui lui est propre. C’est là qu’entre en jeu un projet open source que je recommande à tout le monde : OpenTelemetry. Il permet de s’appuyer sur un agent unique, capable d’aller chercher les logs, les métriques et les traces, et de les envoyer vers n’importe quelle destination. J’ai bien conscience que les équipes IT redoutent le changement et je les comprends, mais le moment est particulièrement bien choisi pour se saisir de cette solution unique en son genre, qui simplifie grandement la collecte des données sur le long terme.
Avant toute chose, le succès d’une démarche d’observabilité repose, selon moi, sur la capacité des organisations à procéder par étapes. La transition vers une architecture de microservices, par exemple, implique de nombreux changements en termes de développement, de gestion opérationnelle et même de culture d’entreprise. Chaque équipe souhaite profiter de l’occasion pour adapter ses pratiques, et la multiplication des projets peut vite devenir ingérable.
Au contraire, pour passer efficacement au cloud-native et à l’observabilité, les décideurs doivent se concentrer sur leur objectif et définir clairement les différentes phases du processus. Ils doivent aussi intégrer les aspects organisationnels, car rien ne sert de s’équiper d’outils décloisonnés si les équipes et les process fonctionnent encore en silos. Encore une fois, comme on l’observe chez nos clients qui ont réussi cette démarche, l’observabilité est avant tout un état d’esprit. C’est donc par là qu’il faut commencer avant de se jeter sur les solutions techniques.
L’observabilité doit s’envisager sur le long terme, et le principal écueil que j’ai pu observer concerne sans doute le manque d’anticipation. C’est un problème que l’on constate souvent au moment de la mise en production. Le passage à l’échelle génère en effet de nombreuses difficultés supplémentaires en matière de répartition de charge, de sécurité, d’authentification, etc., et les entreprises n’ont souvent pas le recul nécessaire pour affronter ces complications pourtant prévisibles.
Dans l’idéal, elles devraient même anticiper les risques inhérents à l’observabilité. Cela peut paraître contradictoire, mais il faut s’attendre à ce que les énormes volumes de données accessibles dans un système observable perturbent le fonctionnement des équipes DevOps. Le nombre d’incidents se multiplie quand on voit tout, mais le nombre de collaborateurs n’évolue généralement pas en parallèle. Les entreprises doivent donc prévoir d’adopter une approche AIOps et des outils de machine learning pour automatiser les tâches, décharger les équipes de production et se focaliser sur les incidents prioritaires.
Les technologies évoluent rapidement, mais l’état d’esprit de l’observabilité va certainement perdurer sous une forme ou sous une autre. En revanche, on peut imaginer que les outils vont s’adapter à cette nouvelle réalité. Une étude commanditée par Splunk sur l’État de l’observabilité en 2022 montre d’ailleurs que les organisations les plus matures en la matière ont déjà tendance à multiplier leurs outils, tout en limitant le nombre de fournisseurs auxquels elles font appel. On peut donc s’attendre à ce que les plateformes soient de plus en plus complètes et centralisées afin d’offrir aux entreprises tous les outils que nous avons mentionnés depuis une interface unique.
Peut-être même que les analystes réussiront à donner une définition de l’observabilité qui mettra tout le monde d’accord.
***
Merci, Stéphane. On se donne donc rendez-vous lors de la publication de la définition pour voir si nous avons vu juste ! N’hésitez pas à commenter cet article et à nous proposer des idées de sujets pour nos prochaines éditions. En attendant un nouvel épisode de Data Talks, vous pouvez aussi vous rendre sur notre chaîne YouTube pour en apprendre davantage sur la data.
Autres épisodes disponibles :
La plateforme Splunk élimine les obstacles qui séparent les données de l'action, pour donner aux équipes d'observabilité, d'IT et de sécurité les moyens de préserver la sécurité, la résilience et le pouvoir d'innovation de leur organisation.
Fondée en 2003, Splunk est une entreprise internationale. Ses plus de 7 500 employés, les Splunkers, ont déjà obtenu plus de 1 020 brevets à ce jour, et ses solutions sont disponibles dans 21 régions du monde. Ouverte et extensible, la plateforme de données Splunk prend en charge les données de tous les environnements pour donner à toutes les équipes d'une entreprise une visibilité complète et contextualisée sur l'ensemble des interactions et des processus métier. Splunk, une base solide pour vos données.