Observabilité : comment définir des indicateurs clés et des objectifs associés sans tomber dans le piège du trop

Quand on parle d’observabilité, la tentation est grande de vouloir tout mesurer.

Disponibilité, latence, CPU, mémoire, erreurs, retries, timeouts, saturation, logs applicatifs, logs techniques, métriques infrastructure, métriques réseau…
Les outils le permettent.
Les équipes savent faire.

Et pourtant, dans beaucoup d’organisations, plus on mesure, moins on comprend.

Des dashboards illisibles.
Des alertes en continu.
Des décisions prises au ressenti.

Le problème n’est pas le manque d’indicateurs.
Le problème, c’est l’absence de priorisation.

‍

Le faux bon réflexe : partir de ce qui est mesurable

‍

Dans la majorité des systèmes d’information, les indicateurs sont définis à partir :

• de ce que l’outil remonte facilement,
  
• de ce que l’infrastructure sait exposer,
  
• de ce que chaque équipe juge important.
  
  

Résultat :

• des centaines de métriques,
  
• aucune hiérarchie,
  
• et une question simple qui reste sans réponse :
  
  

Est-ce que mon service fonctionne correctement pour l’utilisateur ?

Une bonne démarche d’observabilité ne part jamais des métriques.
Elle part de la valeur.

‍

Le bon point de départ : qu’est-ce qui compte vraiment ?

‍

Avant de définir le moindre indicateur, il faut répondre collectivement à trois questions :

1. Quels sont les parcours critiques pour le business ?
   
2. Quelles sont les fonctionnalités sans lesquelles le service ne vaut plus rien ?
   
3. À partir de quand considère-t-on que l’expérience est dégradée ?
   
   

Ce travail est souvent plus difficile que l’implémentation technique, parce qu’il oblige à arbitrer, à renoncer à tout mesurer, et à assumer des choix.

Mais c’est précisément là que tout se joue.

‍

SLI, SLO, SLA : remettre les concepts dans le bon ordre

‍

Pour éviter le piège du trop, il est indispensable d’être clair sur les rôles de chacun.

‍

SLI – Service Level Indicator

‍

Ce que l’on mesure réellement.

Exemples :

• pourcentage de requêtes réussies,
  
• temps de réponse observé,
  
• taux d’erreur sur une fonctionnalité,
  
• temps de chargement côté utilisateur.
  
  

Un bon SLI est objectif, mesurable et compréhensible.

‍

SLO – Service Level Objective

‍

L’objectif que l’on se fixe sur ce SLI.

Exemples :

• 99,9 % de disponibilité sur 30 jours,
  
• 95 % des requêtes sous 500 ms,
  
• un MTTR inférieur à 30 minutes.
  
  

Un SLO n’est pas un idéal.
C’est un compromis assumé entre fiabilité, coût et capacité d’évolution.

‍

SLA – Service Level Agreement

‍

L’engagement contractuel éventuel.

Tous les SLO ne deviennent pas des SLA, et heureusement.
Un SLO est avant tout un outil de pilotage interne.

‍

Les grandes familles d’indicateurs (et comment ne pas en abuser)

‍

Voici les principales familles d’indicateurs utilisées en observabilité, et surtout comment les exploiter sans tomber dans l’excès.

‍

Disponibilité

‍

SLO de disponibilité : objectif de pourcentage de temps où le service doit rester opérationnel.

La disponibilité n’a de sens que si le périmètre est clair.
Un service peut être « up » techniquement tout en étant inutilisable pour l’utilisateur.

Il est souvent plus pertinent de mesurer :

• la disponibilité d’un parcours,
  
• ou d’une fonctionnalité clé,
  plutôt que celle d’un composant isolé.
  
  

Performance

‍

SLO de performance : objectifs de latence, de taux d’erreur et d’indicateurs garantissant une expérience utilisateur acceptable.

Attention aux moyennes, qui masquent souvent des situations très dégradées.
Il est préférable de travailler avec des percentiles (p95, p99) et des seuils alignés sur l’expérience réelle.

‍

Récupération (MTTR)

‍

SLO de récupération : objectif de temps de rétablissement en cas de panne.

Un système fiable n’est pas un système qui ne tombe jamais, mais un système qui se rétablit vite et de manière maîtrisée.

Le MTTR est souvent plus actionnable que la disponibilité brute, car il met en lumière l’efficacité opérationnelle des équipes.

‍

Utilisation des ressources

‍

Mesure de la capacité des serveurs, de la mémoire, de la bande passante et du stockage.

Ces indicateurs sont indispensables pour le diagnostic et l’anticipation, mais rarement pertinents comme objectifs de pilotage métier.

Ils doivent rester des signaux techniques, pas des SLO centraux.

‍

Taux de saturation

‍

Mesure de la pression exercée sur les systèmes par les demandes utilisateur.

Ces indicateurs permettent d’identifier les limites de charge supportables et d’anticiper les effets de seuil.
Ils n’ont toutefois de valeur que s’ils sont reliés à un impact réel sur les parcours utilisateurs.

‍

Temps de chargement côté utilisateur

‍

Mesure de la latence telle qu’elle est perçue par les utilisateurs finaux.

C’est souvent l’un des indicateurs les plus représentatifs de l’expérience vécue, et pourtant l’un des moins exploités.

Il permet de sortir d’une vision purement technique pour se rapprocher de la réalité terrain.

‍

Disponibilité des fonctionnalités clés

‍

Mesure de la fiabilité des fonctionnalités les plus utilisées : connexion, recherche, transaction, paiement, etc.

C’est ici que l’observabilité devient réellement orientée produit.
Plutôt que de mesurer si une application est disponible, on mesure si l’utilisateur peut accomplir ce pour quoi il est venu.

‍

Moins d’indicateurs, mais mieux choisis

‍

Une règle simple peut servir de garde-fou :

Si un indicateur ne permet ni de décider, ni d’alerter, ni d’arbitrer, alors il ne doit pas devenir un SLO.

Les autres métriques continuent d’exister, mais elles restent des outils de diagnostic, pas des instruments de pilotage.

‍

Conclusion : mesurer moins pour piloter mieux

‍

Une démarche d’observabilité mature ne cherche pas l’exhaustivité.
Elle cherche la clarté.

Définir les bons indicateurs, c’est accepter de dire :

• ce qui est critique,
  
• ce qui l’est moins,
  
• et ce qui peut être temporairement dégradé.
  
  

Paradoxalement, c’est en mesurant moins que l’on devient beaucoup plus fiable.

‍