Aller au contenu principal

Le problème que l'observabilité résout

Résumé : sans instrumentation, une équipe apprend l'existence d'une panne par ses propres clients, puis passe des heures à deviner la cause au lieu de la constater. Cette leçon détaille les cinq problèmes structurels d'une production non observée, chiffre le coût réel de l'indisponibilité, et montre pourquoi les deux métriques qui comptent sont le temps de détection et le temps de diagnostic.

1. Le scénario que toute équipe a vécu​

Le détail le plus révélateur de ce scénario : sur deux heures d'incident, plus d'une heure a été consacrée au diagnostic, pas à la correction. La correction elle-même a pris quelques minutes. C'est le cas dans la grande majorité des incidents — comprendre coûte bien plus cher que réparer.

2. Les cinq problèmes structurels​

Le problème 5 est celui qui bloque l'amélioration. Sans mesure, chaque discussion technique devient un débat d'opinions : « je trouve que c'est plus lent depuis la dernière version » contre « moi je ne vois pas de différence ». Une équipe instrumentée tranche en trente secondes avec un graphique.

3. Les deux métriques qui comptent vraiment​

Ce qu'il faut retenir de ce découpage : quand une direction demande « combien de temps pour réparer ? », la vraie question est « combien de temps pour savoir qu'il y a un problème, et pour comprendre lequel ? ». C'est là que l'observabilité produit son retour sur investissement, et c'est un argument efficace pour obtenir un budget.

4. Le coût réel de l'indisponibilité​

Le coût 5 est celui qui tue les équipes à long terme. Une équipe qui passe la moitié de son temps à éteindre des incendies ne livre plus de valeur. Et comme elle ne livre plus, elle n'a pas le temps d'améliorer la fiabilité — ce qui augmente le nombre d'incendies. C'est un cercle vicieux, et l'observabilité est le premier levier pour en sortir.

5. Les signaux qui annonçaient la panne​

Presque tous les incidents graves sont précédés de signaux faibles que personne ne regardait.

Le signal 4 mérite une attention particulière et sera développé en leçon 4. Une latence moyenne stable peut parfaitement masquer une dégradation sévère pour une partie des utilisateurs. Si 95 % des requêtes répondent en 50 ms et 5 % en 8 secondes, la moyenne reste flatteuse — mais un utilisateur sur vingt subit un service inacceptable.

6. Ce que l'observabilité change concrètement​

Le point 6 fait le lien avec le reste de la démarche DevOps. Comme vu dans le cours CI/CD, le canary release consiste à exposer 5 % des utilisateurs à une nouvelle version et à comparer les métriques. Sans observabilité, cette comparaison est impossible — vous exposez des utilisateurs sans pouvoir détecter la dégradation. L'observabilité conditionne les pratiques de déploiement modernes.

7. L'erreur classique du débutant​

Ce renversement de perspective est le message central du cours. Surveillez d'abord les symptômes vécus par l'utilisateur (erreurs, lenteur), et seulement ensuite les causes techniques (processeur, mémoire, disque). La leçon 4 formalise ce principe avec les quatre signaux dorés.

Retenir en 30 secondes​

  • Sans observabilité, vous apprenez les pannes par vos clients, ce qui est déjà un échec.
  • Le diagnostic représente souvent 60 à 80 % de la durée d'un incident, la correction est le poste le plus court.
  • Cinq problèmes structurels : détection tardive, diagnostic au hasard, aucun historique, aucune prévention, aucune preuve.
  • Trois métriques : MTTD (détecter), MTTI (identifier), MTTR (réparer). L'observabilité agit sur les deux premières.
  • Le coût le plus destructeur est le coût d'opportunité : une équipe qui éteint des incendies n'avance plus.
  • Presque tous les incidents graves sont précédés de signaux faibles que personne ne regardait.
  • La moyenne masque tout : 5 % de requêtes à 8 secondes restent invisibles dans une moyenne flatteuse.
  • Erreur classique : surveiller la charge processeur au lieu de l'expérience utilisateur. Un serveur peu chargé peut renvoyer 100 % d'erreurs.
  • L'observabilité est le prérequis du canary release et du déploiement continu.

Suivant : Monitoring ou observabilité ? La distinction enfin claire →