L’ère de l’observabilité : Pourquoi l’avenir est ouvert, connecté et programmable

Lorsque le fondateur de New Relic, Lew Cirne, a créé APM (Application Performance Monitoring/surveillance des performances des applications), sa principale innovation était la visibilité approfondie du code dans les applications monolithiques fonctionnant dans un datacenter. Il a ensuite mis APM à la disposition de chaque ingénieur en développement et exploitation en tant que solution SaaS. Aujourd’hui, les nouvelles technologies et pratiques (cloud, microservices, conteneurs, sans serveur, DevOps, etc.) favorisent une plus grande vélocité et permettent un passage plus fluide des phases d’écriture du code à la production des logiciels, mais elles induisent aussi une complexité accrue. 

En tant qu’entreprise à la pointe de la surveillance des performances des applications, nous pensons que les défis auxquels sont confrontées les équipes logicielles modernes nécessitent une nouvelle approche. L’observabilité est le moyen de relever ces défis et d’aider les ingénieurs à maintenir la disponibilité des systèmes modernes et à offrir une excellente expérience aux clients.

L’observabilité gagne en popularité dans le monde des logiciels car elle permet aux ingénieurs d’offrir une excellente expérience client malgré la complexité de l’entreprise numérique moderne.

Soyons clairs, « observabilité » est bien plus qu’un mot à la mode pour parler de surveillance.

La surveillance fournit aux équipes logicielles des instruments pour recueillir des données sur leurs systèmes et leur permettre de réagir rapidement en cas d’erreurs et de problèmes. En d’autres termes, la surveillance consiste à développer des systèmes pour le recueil de données, afin de détecter les problèmes et réagir rapidement. 

L’observabilité, pour sa part, consiste à équiper ces systèmes avec des outils pour recueillir des données exploitables qui permettent non seulement de savoir quand une erreur ou un incident se produit mais, plus important encore, pourquoi. Cette information est essentielle aux équipes pour réagir rapidement et résoudre les urgences des logiciels modernes.

L’observabilité aide les équipes logicielles modernes à faire ce qui suit :

• Livrer des logiciels de qualité supérieure à grande échelle

• Développer une culture de l’innovation durable

• Optimiser les investissements en cloud et outils modernes

• Voir les performances de leur activité numérique en temps réel

Chez New Relic, nous pensons que les mesures, les événements, les logs et les traces (regroupés sous l’acronyme M.E.L.T.) sont les types de données essentiels de l’observabilité. Mais l’observabilité va bien au-delà des simples données.

Comment établir l’observabilité de vos systèmes ? Et quels résultats en attendre ? À notre avis, l’observabilité se définit par quatre défis clés. Et pour relever ces défis de front, les organisations doivent adopter une pratique d’observabilité basée sur trois composantes : une instrumentation ouverte, des données connectées et la programmabilité. Dans cet ebook, nous allons vous présenter ces tendances, ces défis et ces composantes.

La rapidité de l’innovation technologique de ces cinq à dix dernières années a été ahurissante, avec un impact énorme sur les équipes logicielles. Quelques tendances clés :

• Pression pour innover rapidement : les équipes logicielles sont confrontées à une pression énorme pour livrer rapidement et fréquemment de nouvelles fonctionnalités et expériences sur le marché, plus rapidement que la concurrence. Le cloud a élargi le paysage concurrentiel en abaissant les coûts, forçant les équipes logicielles à produire et à s’adapter plus rapidement que jamais, souvent avec moins de ressources. Les bons élèves déploient des logiciels entre une fois par heure et une fois par jour, et les meilleurs le font même à la demande plusieurs fois par jour.

• Attentes plus élevées des clients : les clients veulent toujours plus et sont moins tolérants. Les expériences utilisateur lentes, sujettes aux erreurs ou mal conçues, ne sont tout simplement plus acceptées par les clients. Si votre produit ne leur convient pas, vous pouvez leur dire au revoir. Selon le développeur d’applications mobiles Dot Com Infoway, 62 % des gens désinstallent une application s’ils subissent des pannes, des blocages ou des erreurs. Les meilleurs développeurs corrigent les erreurs remontées par leurs clients en moins d’une heure, alors que les autres mettent entre une semaine et un mois pour restaurer le service1.

• Plus d’options technologiques : aujourd’hui, les organisations mettent en place des architectures de microservices et des systèmes distribués sur un nombre illimité de fournisseurs cloud et de plateformes informatiques. Ces services sont plus faciles que jamais à adopter et à utiliser, et fonctionnent de plus en plus de manière transparente. Vous pouvez choisir différents systèmes et services pour prendre en charge tout ce dont vous avez besoin dans une pile moderne, tout en éliminant les tâches de configuration et de maintenance de la pile.

• Montée en puissance du DevOps et de l’automatisation : les entreprises s’organisent en équipes autonomes chargées de la conception, de la livraison et de l’exploitation de bout en bout des services qu’elles maîtrisent en production. Elles exploitent parfois des plateformes et des outils communs fournis en tant que services par des équipes de plateformes internes. L’automatisation réduit le travail répétitif et de faible valeur et améliore la fiabilité. Dans une architecture cloud native, toute la pile est contrôlée par logiciel ; toute la zone de surface est programmable. Et puisque toute cette automatisation est pilotée par logiciel, elle peut échouer. Les équipes doivent surveiller leur CI/CD et autres outils d’automatisation exactement comme elles le feraient pour les applications qui servent directement leurs clients. Le recueil de données sur chaque composant au sein d’un système est l’essence même de l’observabilité.

Ces tendances induisent quatre défis majeurs qui favorisent le besoin d’observabilité des systèmes modernes :

1. Complexité accrue : si les technologies du cloud natif ont transformé la façon dont les applications sont conçues, livrées et exploitées, elles ont également créé plus de complexité pour les équipes chargées de leur maintenance. À mesure que les applications monolithiques sont transformées en microservices, où la durée de vie d’un conteneur peut être mesurée en quelques minutes, voire moins, les équipes logicielles font à présent face à des services en constante évolution. Étant donné que chaque application individuelle est scindée en des dizaines de microservices, les équipes d’exploitation sont confrontées à une complexité d’échelle : elles sont désormais responsables de la maintenance de services qu’elles connaissent mal.

2. Risque plus élevé : des déploiements fréquents et une infrastructure dynamique entraînent plus de risques, plus fréquemment. Ce risque accru renforce l’importance de la détection et de l’annulation d’installation instantanées, contrairement à l’époque des déploiements peu fréquents. Et comme les entreprises adoptent des pratiques agiles et une livraison continue pour expédier les logiciels plus rapidement, elles ajoutent une autre dimension à leurs logiciels (via des outils de livraison et des pipelines) qui doivent être surveillés et maintenus.

3. Compétences insuffisantes : l’explosion des architectures de microservices a introduit de nouveaux défis car les équipes logicielles doivent repenser la façon dont elles conçoivent, développent et déploient les applications. Chaque membre de l’équipe doit également comprendre et être capable de dépanner des parties d’une application qu’il ne connaissait pas auparavant ; aujourd’hui, un expert en bases de données, par exemple, doit comprendre le réseau et les API. L’inconvénient est que le nombre de technologies nouvelles et différentes que les équipes doivent apprendre à utiliser est trop vaste pour être maîtrisé par une seule personne. Les équipes ont besoin de mieux comprendre ces technologies dans le contexte du travail qu’elles accomplissent.

4. Surmultiplication des outils : les environnements hybrides, les milliers de conteneurs en production et les nombreux déploiements quotidiens entraînent d’énormes volumes de données de mesures d’exploitation. Jongler avec plusieurs outils de surveillance et changer de contexte pour trouver et corréler les données les plus importantes, ou pour trouver et résoudre les problèmes, prend un temps précieux dont les équipes ne disposent pas lorsque leurs clients sont touchés par un problème de production.

Compte tenu de ces tendances et de ces défis, ainsi que du rythme des changements technologiques, les équipes ont besoin d’une solution unique qui réduit la complexité et les risques, ainsi que les coûts généraux. La solution doit combler les lacunes de compétences et être facile à utiliser, à comprendre et à parcourir lors du recueil du contexte essentiel. Elle doit permettre à toute équipe au sein d’une organisation de voir toutes ses données d’observabilité à partir d’un seul endroit et d’obtenir le contexte dont elle a besoin pour en tirer des conclusions et prendre les mesures adéquates.

^{1. « Accelerate: State of DevOps 2019 », DORA, septembre 2019}

La notion de surveillance remonte au moins au début de l’ère Unix (la première version est sortie en 1971), mais le terme « APM » (Application Performance Monitoring) ne s’est répandu qu’au début des années 2000. Depuis, la surveillance a évolué pour fournir des mesures ou indicateurs détaillées, un suivi et des alertes sur les performances et l’expérience utilisateur sur l’ensemble de la pile technologique, cloud compris.

À mesure que les environnements modernes gagnent en complexité, l’observabilité est extrêmement importante pour le succès futur des équipes logicielles et de leurs organisations. Elle procure aux équipes une visibilité connectée de toutes leurs données de performances en un seul endroit, en temps réel, ce qui leur permet d’identifier les problèmes plus rapidement, de comprendre leurs causes et, au bout du compte, d’offrir une excellente expérience aux clients.

L’observabilité est tout sauf un nouveau concept. Elle dérive à l’origine de la théorie de contrôle et d’ingénierie introduite par l’ingénieur américain d’origine hongroise Rudolf E. Kálmán pour les systèmes linéaires dynamiques. Une définition généralement acceptée de l’observabilité telle qu’appliquée à la théorie du contrôle est une mesure de la façon dont les états internes d’un système peuvent être déduits de la connaissance de ses sorties externes.

Dans le cycle de vie des logiciels, l’observabilité englobe le recueil, la visualisation et l’analyse des mesures, événements, logs et traces afin d’acquérir une compréhension globale du fonctionnement d’un système. L’observabilité vous permet de comprendre pourquoi quelque chose ne va pas, par rapport à la surveillance qui vous indique simplement quand quelque chose ne va pas.

Yuri Shkuro, auteur et ingénieur logiciel chez Uber Technologies, explique la différence de cette façon : la surveillance consiste à mesurer ce que vous décidez à l’avance comme étant important, tandis que l’observabilité est la capacité à poser des questions auxquelles vous n’aviez pas pensé auparavant au sujet de votre système.

Comme nous l’avons dit précédemment, chez New Relic, nous pensons que les mesures, les événements, les logs et les traces sont les types de données essentiels de l’observabilité et que les événements sont un type de télémétrie critique (et souvent ignoré) qui doit faire partie de toute solution d’observation (nous en reparlerons bientôt). En fin de compte, lorsque nous instrumentons tout et utilisons ces données de télémétrie pour développer des connaissances fondamentales et fonctionnelles des relations et des dépendances au sein de notre système, ainsi que de ses performances et de sa santé, nous pratiquons l’observabilité. Cependant, chez New Relic, notre approche est encore plus nuancée que cela, car nous croyons fermement en trois composantes fondamentales de l’observabilité.

Jusqu’à présent, nous avons défini l’observabilité comme reposant sur l’instrumentation des systèmes pour recueillir des données exploitables afin de savoir non seulement quand une erreur ou un incident se produit, mais aussi pourquoi. La capacité à répondre au pourquoi est la façon dont les équipes résolvent réellement les problèmes à la racine et garantissent la fiabilité du système. Pour réussir à observer vos systèmes, nous pensons que vous avez besoin de trois composantes principales :

1. Instrumentation ouverte : nous définissons l’instrumentation ouverte comme le recueil de données de télémétrie open source ou spécifiques au fournisseur à partir d’une application, d’un service, d’un hôte d’infrastructure, d’un conteneur, d’un service cloud, d’une fonction sans serveur, d’une application mobile ou de toute autre entité qui émet des données. Elle offre une visibilité sur toute la surface des applications et des infrastructures essentielles à l’entreprise.

2. Entités connectées : toutes ces données de télémétrie doivent être analysées afin que les entités qui les produisent puissent être identifiées et connectées, et les métadonnées doivent être incorporées pour créer une corrélation entre les entités et leurs données. Ces deux actions créent du contexte et du sens à partir de grands volumes de données. Dans ce contexte, il est possible de mettre en place une organisation sous forme de modèles visuels du système ou de la technologie sans aucune configuration supplémentaire. Le dernier avantage des entités connectées est que l’intelligence peut être appliquée pour dériver encore plus de sens. L’intelligence appliquée est l’application du machine learning et de la science des données pour rechercher des répétitions ou des anomalies dans les données afin que les humains puissent prendre les mesures adéquates.

3. Programmabilité : chaque entreprise est unique et l’organisation automatique, si performante soit-elle, ne saurait répondre à tous ses différents besoins ou s’adapter à tous ses types d’utilisation. Les entreprises ont besoin de créer leur propre contexte et leur propre organisation en plus de toutes les données de télémétrie, en associant les données et les dimensions critiques de l’entreprise. New Relic se positionne de façon unique dans le domaine de l’observabilité en reconnaissant l’importance de ce besoin, permettant aux clients de créer des applications en plus de toutes ces données de télémétrie. Un exemple : avoir la possibilité de montrer clairement le coût des erreurs et des échecs dans un processus métier, consacrer un budget à ces échecs et fournir un chemin d’accès aux données pour trouver les causes.

Pour en savoir plus sur la façon dont l’observabilité évolue pour prendre en charge les logiciels modernes, lisez Les 10 principes de l’observabilité : les étapes de la voie du succès avec les logiciels modernes.

Quand New Relic a vu le jour en 2008, la meilleure façon de recueillir des mesures de télémétrie consistait à utiliser des agents. Les développeurs de logiciels et les équipes d’exploitation déployaient des agents intégrés à leurs applications et hôtes, et ces agents recueillaient des mesures, des événements, des traces et des données de logging, les packagaient de manière propriétaire et les envoyaient pour agrégation et affichage.

Bien que cela reste un moyen efficace pour recueillir des mesures de télémétrie aujourd’hui, le secteur a changé. Il existe désormais de nombreuses autres sources de télémétrie. De nombreux systèmes et frameworks ouverts pour le développement de logiciels ont des mesures, des événements, des logs et des traces intégrés qu’ils émettent dans des formats courants. Pour l’observabilité, vous devez recueillir des données à partir de sources ouvertes et propriétaires et les regrouper en un seul endroit. Vous devez appliquer automatiquement de l’instrumentation là où cela a du sens et en ajouter là où vous avez le plus besoin de visibilité.

Dans la plupart des cas, les mesures (ou indicateurs) sont le point de départ de l’observabilité. Elles sont peu coûteuses à recueillir et à stocker, dimensionnelles pour une analyse rapide et un excellent moyen de mesurer la santé globale. Pour cette raison, de nombreux outils ont émergé pour le recueil de mesures, tels Prometheus, Telegraf, StatsD, DropWizard et Micrometer. De nombreuses entreprises ont même créé leurs propres formats propriétaires pour le recueil des mesures en plus des datastores ouverts et conviviaux comme Elasticsearch. Une solution d’observabilité doit être capable d’exploiter les mesures provenant de n’importe laquelle de ces sources que diverses équipes ont adoptées dans l’entreprise numérique moderne.

Les traces sont utiles pour montrer la latence de bout en bout des appels individuels dans une architecture distribuée. Ces appels donnent un aperçu spécifique de la myriade de parcours clients via un système. Les traces permettent aux ingénieurs de comprendre ces parcours, de trouver les goulots d’étranglement et d’identifier les erreurs afin qu’elles puissent être corrigées et optimisées. Comme pour les mesures, de nombreux outils ont vu le jour (Jaeger, Zipkin et AWS X-ray, pour n’en citer que quelques-uns) à partir de solutions personnalisées créées par des organisations sophistiquées.

W3C Trace Context deviendra bientôt la norme pour propager le « contexte de trace » au-delà des limites des processus. Le contexte de trace fournit un moyen standard de suivre le flux des données à travers un système, en suivant les appels d’origine (parents et enfants) sur des systèmes distribués complexes. Lorsque les développeurs utilisent une norme pour leur contexte de trace, les périmètres de nombreux systèmes différents peuvent être assemblés de manière fiable pour être affichés et interrogés au sein d’une plateforme d’observabilité. Le contexte de trace contient d’autre part des balises importantes et d’autres métadonnées qui rendent la recherche et la corrélation plus performantes.

Au sein de la Cloud Native Computing Foundation (CNCF), le projet OpenTelemetry fusionne le recueil de mesures et de traces dans un format ouvert. Alors que de plus en plus d’organisations adoptent OpenTelemetry, nous nous attendons à voir une instrumentation intégrée plus normalisée et commune évitant d’avoir à exécuter des agents pour l’instrumentation de bytecode à l’exécution. Compte tenu de l’étendue des outils comme Kubernetes et Istio dans la CNCF et leur adoption rapide, OpenTelemetry est susceptible de devenir omniprésent dans les logiciels modernes en tant que source de télémétrie.

Les logs sont importants lorsqu’un ingénieur est en mode de débogage « approfondi », essayant de comprendre un problème. Les logs fournissent des données haute fidélité et un contexte détaillé autour d’un événement afin que les ingénieurs puissent recréer ce qui s’est passé milliseconde par milliseconde. Tout comme pour les mesures et les traces, des outils ont émergé pour réduire le travail et les efforts de recueil, de filtrage et d’exportation des logs. Les solutions courantes incluent Fluentd, Fluent Bit, Logstash et AWS CloudWatch, ainsi que de nombreuses autres normes émergentes.

Tous ces projets de mesures, de logs et de traces préparent un avenir dans lequel l’instrumentation devient plus facile pour tout le monde grâce à cette approche « batteries incluses ».

Les événements sont un type de télémétrie critique (et souvent ignoré) qui doit faire partie de toute solution d’observabilité. Malheureusement, bien que les événements et les logs partagent certaines similitudes, les deux sont souvent confondus par erreur. Les événements sont des enregistrements discrets et détaillés de points d’analyse importants, mais contiennent un niveau d’abstraction plus élevé que le niveau de détail fourni par les logs. Les logs sont des enregistrements complets et discrets de tout qui se produit dans un système ; les événements sont des enregistrements de choses significatives sélectionnées qui se sont produites, avec des métadonnées jointes à l’enregistrement pour affiner son contexte. Par exemple, lorsque New Relic recueille des événements de transaction (instances individuelles de l’exécution d’une méthode ou d’un bloc de code dans un processus), des données sont automatiquement ajoutées pour indiquer le nombre d’appels de base de données exécutés et la durée de ces appels.

Bien que la plupart des outils open source qui fournissent une instrumentation essentielle soient également livrés avec un datastore discret pour le recueil, le stockage et la mise à disposition des données pour analyse, cela minimise l’intérêt de l’observabilité : les ingénieurs et les équipes sont obligés de connaître et comprendre plusieurs outils. Sans datastore unifié, lorsque des problèmes (ou pire, des urgences) surviennent, les ingénieurs doivent passer d’un outil à un autre pour trouver la source du problème. Une solution d’observabilité ouverte permet l’interopérabilité de toutes ces données, quelle qu’en soit la source. Et elle crée automatiquement les entités et les connexions entre elles, fournissant un contexte essentiel.

Obtenir des données de télémétrie de pratiquement n’importe où et les regrouper en un seul endroit est un bon début, mais ce n’est pas suffisant. Vos données doivent être connectées de manière à vous permettre de comprendre les relations entre entités et elles doivent être mises en corrélation avec les métadonnées afin que vous puissiez comprendre leur relation avec votre activité. Ces connexions donnent à vos données un contexte et un sens. Le contexte, par exemple, permet d’obtenir des vues organisées qui font apparaître les informations les plus importantes sur vos données et modélisent leur environnement spécifique. De plus, lorsque toutes vos données et connexions de télémétrie sont stockées en un seul endroit, vous pouvez appliquer l’intelligence à ces très grands ensembles de données, ainsi qu’aux modèles de surface, anomalies et corrélations qui ne sont pas facilement identifiables par des humains regardant des tableaux de bord.

Essentiellement, vous avez besoin de voir comment toutes les entités de votre système sont liées les unes aux autres à tout moment. Il n’est tout simplement pas possible de maintenir une carte mentale de votre système lorsqu’il change chaque jour, chaque heure ou chaque minute. Il n’est pas non plus possible de s’appuyer sur la configuration pour gérer ces relations. À mesure que les équipes ajoutent de nouveaux services, refactorisent les anciens et accélèrent et arrêtent les instances d’applications éphémères, il devient impossible de maintenir une carte mentale. Mais les entités, leurs connexions et leurs relations sont une partie du contexte essentiel pour l’observabilité.

Impossible de créer un contexte sans métadonnées et dimensions. Selon votre système, votre entreprise ou votre application, le volume de données pertinentes est potentiellement énorme. Par exemple, dans le cas d’une application d’e-commerce, le contexte utile comprend, sans s’y limiter :

• Détails sur l’équipe propriétaire de l’application, du runbook (dossier d’exploitation) et du référentiel de code

• Balises de Docker ou du fournisseur de cloud où il est déployé

• Son type de service et sa fonction

• Les régions où il a été déployé

• Ses dépendances en amont et en aval

• Ses événements de déploiement ou de modifications

• Son statut d’alerte

• Toutes les données de trace ou de log associées aux transactions qu’il effectue

• Les données métier supplémentaires (par exemple, valeur du panier)

L’organisation des visualisations de données est un outil puissant pour faire apparaître des entités connectées, bien comprises et bien définies. Nous savons déjà comment représenter au mieux un processus d’application Java exécuté dans un conteneur, ou une fonction AWS Lambda qui appelle DynamoDB après un appel depuis SQS, ou un cluster Kubernetes exécutant un déploiement dynamique ; nous avons déjà résolu ces problèmes. Et pour un ingénieur SRE ou DevOps débordé, la modélisation de ces environnements dans un ensemble de tableaux de bord est une perte de temps précieux. Une plateforme d’observabilité doit intégrer les meilleures pratiques des leaders du secteur et présenter les signaux de santé les plus importants, ainsi que fournir des expériences interactives permettant aux ingénieurs de résoudre rapidement les problèmes. La création manuelle de visualisations et de tableaux de bord pour une technologie spécifique et omniprésente représente un travail énorme.

L’organisation par contexte aide également à relever le défi du manque de compétences dans une entreprise numérique complexe. Elle constitue une solution pour tous les membres de l’organisation en leur permettant de visualiser les flux et les dépendances dans leurs systèmes complexes et d’observer tout ce qui est pertinent pour l’ensemble de l’environnement. Parce que cette organisation modélise bien une variété de systèmes, elle facilite la compréhension, même si les personnes concernées ne connaissent pas bien une technologie ou un code spécifique.

L’observabilité ne sert à rien si vous ne pouvez pas agir rapidement lorsque votre système ne fonctionne pas correctement. Grâce au machine learning et aux analyses prédictives, l’intelligence appliquée rend les données d’observabilité pertinentes et exploitables. Parfois appelée intelligence artificielle pour les opérations informatiques, ou AIOps par la firme d’analystes Gartner, l’intelligence appliquée sépare le signal du le bruit afin que vous puissiez prendre les bonnes décisions. 

L’intelligence appliquée fournit des instructions claires, même lorsque les jeux de données sont volumineux et complexes. Les machines sont très efficaces pour identifier les modèles, les tendances et les erreurs dans les données à une échelle que les humains ne peuvent tout simplement pas reproduire. Les capacités d’intelligence appliquée appropriées détectent les problèmes le plus tôt possible à partir des données de télémétrie, et corrèlent et hiérarchisent les événements pour minimiser les alertes inutiles. L’intelligence appliquée peut enrichir automatiquement les alertes d’incident avec un contexte, des conseils et des suggestions pertinents, notamment par des recommandations qui peuvent vous aider à identifier rapidement la véritable cause première d’un problème et à savoir comment le résoudre.

Voici un exemple d’intelligence appliquée en action : votre équipe reçoit une alerte concernant une violation du seuil de temps de réponse pour une application. L’intelligence a automatiquement examiné le débit, les erreurs de latence et les signaux de transaction liés à l’application dans les six heures précédant l’alerte. Dans ce scénario, l’intelligence détecte la latence dans le datastore sur lequel s’appuie l’application et révèle une connexion directe entre le problème de base de données et le temps de réponse lent de l’application. Les avantages sont doubles :

1. Étant donné que l’intelligence appliquée a déjà effectué une analyse de dépannage cruciale et réduit votre temps moyen de détection (MTTD), votre équipe peut résoudre plus rapidement le problème sous-jacent et, à son tour, réduire son délai moyen de résolution (MTTR).

2. Parce que l’intelligence appliquée devient plus utile lorsqu’elle exploite plus de données et est capable de filtrer le bruit des alarmes mineures ou des fausses alarmes, votre équipe réduira considérablement la fatigue globale engendrée par les alertes et pourra se concentrer sur sa mission première : livrer de meilleurs logiciels, plus rapidement.

En visualisant les dépendances et en explorant les types de télémétrie en temps réel, vous pouvez comprendre plus rapidement et plus facilement les problèmes du système et les résoudre pour comprendre les véritables causes de ces problèmes, au-delà des données. Lorsqu’elles modélisent efficacement l’environnement technique automatiquement, les visualisations organisées facilitent la recherche des causes profondes pour tout le monde. Et l’application de l’intelligence à de grands jeux de données fait apparaître des connexions dans les données, ce qui favorise la prise de décisions informées dans les situations difficiles.

Connecter les données d’observabilité aux résultats de l’entreprise est une étape critique que les organisations doivent franchir pour devenir des entreprises numériques matures. Vous devez commencer par des mesures essentielles de la réussite, puis identifier les indicateurs de performances clés (KPI) qui contribuent directement au succès de ces mesures. Les mesures telles que la latence, les erreurs ou le temps de chargement des pages sont des choix évidents pour comprendre les performances des applications, mais elles ne sont pas aussi utiles pour comprendre l’impact d’une application sur l’expérience client et les indicateurs de performances clés de l’entreprise.

C’est pourquoi il est important de reconnecter l’observabilité à l’entreprise et de fournir aux équipes les informations dont elles ont besoin pour prendre des décisions basées sur les données. La question est, comment faire ? 

Pour la plupart des solutions, la réponse a été de visualiser les KPI dans des tableaux de bord. Les tableaux de bord sont un excellent outil pour afficher rapidement des vues ad hoc des données. Ce sont des outils souples et puissants, essentiels pour toute solution d’observabilité. Mais compte tenu de l’environnement technologique particulier de votre entreprise et des KPI uniques, il est plus important que jamais d’aller au-delà des tableaux de bord et de développer des applications pour importer des données sur votre entreprise numérique et les combiner avec vos données de télémétrie. En connectant des données d’entreprise par dessus votre plateforme d’observabilité, une application offre une expérience organisée et interactive ; elle intègre fréquemment des workflows et permet la combinaison de jeux de données externes en temps réel. Les tableaux de bord n’en sont pas capables, mais les applications le peuvent.

Pour connecter des données de gestion et de télémétrie dans des applications, votre solution d’observabilité doit être une plateforme que vous pouvez développer. Elle doit être programmable.

Lorsque vous disposez d’une plateforme d’observabilité sur laquelle vous pouvez créer des applications adaptées à vos besoins uniques, cela vous permet de faire des choses qui n’étaient pas possibles auparavant dans un outil d’observabilité, telles que :

• Hiérarchiser les investissements en logiciels et mesurer l’efficacité de ces investissements en temps réel

• Comprendre, dans un contexte riche, les relations entre votre technologie, votre activité et vos clients

• Prendre des décisions basées sur les données qui ont un plus grand impact direct sur des KPI spécifiques

• Partager vos conclusions grâce à des visualisations interactives conçues pour modéliser votre activité spécifique, et pas seulement votre environnement technologique

Enfin, une plateforme d’observabilité programmable permet aux équipes de créer des applications qui s’intègrent à leur système d’enregistrement unique sans avoir à déployer un autre outil. Cela offre un certain nombre d’avantages : moins de changement de contexte entre les outils en cas d’urgence ; moins de temps et d’efforts nécessaires pour approvisionner, exploiter, maintenir et surveiller un autre système ; et moins de dépenses d’achat, de développement ou d’apprentissage d’un nouvel outil.

À mesure que l’innovation logicielle progresse, le monde continuera d’évoluer plus rapidement et de se complexifier. Tout comme les dernières technologies et tendances qui ne pouvaient pas être anticipées il y a quelques années à peine, nous ne savons pas de quoi seront faites les prochaines évolutions. Ce que nous savons, c’est que cette innovation et cette complexité continues obligeront vos équipes à évoluer plus rapidement, à adopter plus de technologies tout en éliminant complètement les erreurs, et ce à une vitesse fulgurante. Vous devrez également automatiser davantage et suivre le rythme des attentes des clients qui ont été définies par d’autres entreprises, notamment vos concurrentes, pour offrir des expériences client de pointe.

Compte tenu de ces défis, vous avez besoin d’une plateforme d’observabilité unique qui réduit la complexité et les risques, et ce avec des frais généraux réduits. Vous avez besoin d’une plateforme qui comble le déficit de compétences en étant facile à utiliser, à comprendre et à adopter pour regrouper le contexte essentiel, afin d’être facilement exploitable par n’importe quelle équipe au sein d’une organisation. Vous avez besoin d’une plateforme qui permet à vos équipes de voir toutes leurs données de télémétrie et de gestion en un seul endroit, d’obtenir le contexte dont elles ont besoin pour trouver rapidement du sens et prendre les bonnes décisions, et de travailler avec les données de manière significative pour vous et votre activité.

Une plateforme d’observabilité devrait offrir les fonctions suivantes :

• Recueil et rassemblement en un seul endroit des données de télémétrie provenant de sources ouvertes et propriétaires. Cette instrumentation ouverte permet d’éviter la prolifération des outils et le changement de contexte lorsque des problèmes et des urgences surviennent, car elle assure l’interopérabilité de toutes les données, quelle qu’en soit la source.

• Établissement de connexions et de relations entre les entités et application de ces connexions pour créer un contexte et un sens afin que vous puissiez comprendre les données. Le contexte doit être présenté dans des vues organisées qui présentent les informations les plus importantes.

• La capacité de créer une couche supérieure d’applications personnalisées. Contrairement aux tableaux de bord, les applications offrent des expériences interactives et organisées, elles disposent souvent de workflows intégrés et elles permettent de combiner des jeux de données externes en temps réel. La programmabilité redéfinit les capacités de l’observabilité.

Avec une plateforme d’observabilité ouverte, connectée et programmable, les avantages pour votre entreprise sont importants : innovation et déploiements plus rapides, charge de travail et coûts réduits et meilleure compréhension de la façon de hiérarchiser votre temps et votre attention. Tout cela conduit à une compréhension partagée beaucoup plus profonde de vos données, de vos systèmes et de vos clients. Cela améliorera votre culture et favorisera la croissance de votre entreprise grâce une vision en temps réel des performances de vos systèmes numériques et de la façon dont vos clients interagissent avec vos logiciels, ce qui vous permettra de vous concentrer sur ce qui compte le plus : les résultats de l’entreprise.