Le client fait pression, mais vous n'avez aucune idée de pourquoi le système est lent ? Ce n'est pas entièrement votre faute

Sur le papier, l'observabilité devrait être un outil accessible à chaque développeur, chef de produit et responsable des opérations. Mais la réalité est tout autre.

Par Yuval Susmanovich

Vous connaissez probablement le scénario suivant : le système tourne en production, il semble fonctionner correctement, mais soudain le client signale qu'il est lent, ou qu'une des fonctionnalités ne fonctionne pas comme prévu. Alors vous commencez à chercher : vous examinez les journaux dans un système, passez en revue les métriques dans un deuxième système, vérifiez les traces dans un troisième système et essayez de croiser les informations pour comprendre si la racine du problème se trouve dans le code, l'infrastructure ou les données du client.

Les systèmes que nous développons ne se comportent pas toujours comme nous l'attendons. Les raisons vont de l'oubli de la mise en œuvre d'une exigence à un goulot d'étranglement inattendu, en passant par des facteurs non pris en compte dans l'utilisation par le client. La responsabilité de comprendre ce qui se passe en temps réel repose sur les épaules des équipes de développement.

Ce n'est pas une tâche simple : les applications d'aujourd'hui sont composées de dizaines de microservices, d'infrastructures cloud et de bases de données, chacun étant surveillé différemment. C'est là qu'intervient l'observabilité : la capacité d'observer ce qui se passe à l'intérieur du système via des métriques, des journaux et des traces. Au lieu de passer des heures à essayer de reproduire une panne, nous voyons immédiatement où le problème s'est produit, même dans les cas d'inconnues inconnues (Unknown Unknowns).

Oui, mais…

Sur le papier, l'observabilité devrait être accessible à tous, mais en pratique, elle reste souvent le domaine des experts (DevOps ou SRE). Il y a trois raisons principales :

Surcharge d'informations : Les tableaux de bord sont remplis de graphiques et de traces complexes. Un développeur doit plonger dans une mer de données et filtrer le bruit.
Manque de standardisation : Il n'y a pas d'uniformité. Un projet est écrit en Node.js, un autre en Python, un troisième tourne sur un cloud différent. Il n'y a pas de langage commun ou de « chemin d'or ». Passer d'un projet à l'autre oblige à réapprendre les outils à chaque fois.
Plus de code, moins de temps : Les outils d'IA permettent de produire du code plus rapidement, mais la complexité des systèmes est telle que les enquêteurs ne connaissent plus leur propre code en profondeur. L'observabilité exige de savoir quoi chercher, mais avec la croissance des systèmes, les développeurs ne savent plus par où commencer.

L'observabilité est passée d'un outil de réponse à une base de données complexe nécessitant une expertise. La solution naturelle est l'IA, mais si chaque projet a une structure différente, il faudrait créer des centaines d'agents. La standardisation est le préalable indispensable.

Quatre étapes pour créer l'observabilité

Changer la façon dont nous créons l'observabilité demande du courage, mais décomposer la tâche rend le chemin plus simple.

1. Changer la méthode de reporting

La première étape consiste à rapporter la télémétrie de manière uniforme. OpenTelemetry est devenu la norme pour créer ce « chemin d'or ». Cela demande de revenir sur les projets existants pour garantir une flexibilité accrue.

2. Passer aux projets open-source

L'étape suivante consiste à remplacer les technologies propriétaires. Nous avons choisi des projets open-source (Prometheus, OpenSearch, Jaeger) plutôt que des fournisseurs payants (Grafana, Datadog, etc.). Cela garantit que les données restent sous notre contrôle et que nous pouvons les traiter selon nos besoins.

3. Infrastructure d'alerte intelligente

Une fois la télémétrie alignée, nous construisons un réseau d'alerte proactif. L'objectif est d'identifier les anomalies en temps réel. C'est un processus « vivant » qui nécessite un réglage constant pour minimiser les faux positifs. Les définitions d'alerte sont gérées dans un dépôt Git et déployées via Helm.

4. Rendre l'observabilité accessible via un IDP

Nous avons construit un IDP (Internal Developer Portal) qui rend la télémétrie accessible de manière consolidée. Cela permet de voir les corrélations entre métriques, journaux et traces. Les organisations peuvent utiliser Backstage de Spotify ou développer un portail sur mesure.

La prochaine étape est la connexion d'un agent intelligent via MCP. Comme tous les projets utilisent le même format, un seul agent de haute qualité suffit pour servir toute l'organisation via un chatbot dans l'IDP.

Pas seulement remplacer un outil par un autre

Deux ans après, nous avons réalisé des changements fondamentaux :

Indépendance : L'information est accessible à tous, chaque développeur peut enquêter seul.
Super-agent : Nous avons développé un agent qui analyse toutes les données et fournit un diagnostic complet en quelques minutes avec 90 % de précision.
Systèmes prédictifs : Nous utilisons le machine learning pour anticiper les problèmes basés sur des modèles passés.

En fin de compte, le « chemin d'or » est un changement conceptuel : passer d'un monde où chaque équipe choisit ses outils à un monde avec un langage et une infrastructure uniformes. À l'ère de l'IA, ce n'est pas un luxe, mais une condition nécessaire pour évoluer, automatiser et résoudre les problèmes rapidement.