27. L'observabilité : voir le système à travers ses effets
Pourquoi ce chapitre existe
Un système peut produire des milliers de métriques, logs et traces sans être observable. L'abondance de données ne répond pas à la question qui compte pendant une livraison ou un incident : quel comportement utilisateur est dégradé, où, depuis quand, et quelle action est possible ? L'observabilité est une capacité de questionner l'état interne d'un système à partir des signaux qu'il émet, avec un coût compatible avec l'urgence.
Les idées essentielles
- Les signaux doivent partir des résultats utilisateurs et métiers, puis descendre vers les causes techniques.
- Métriques, logs et traces sont complémentaires : tendance, événement détaillé et chemin causal.
- Un signal est utile lorsqu'il est relié à une décision ou à une action, pas parce qu'il est facile à collecter.
- L'instrumentation doit respecter la confidentialité, les coûts et la lisibilité ; plus de données n'est pas toujours plus de connaissance.
Concevoir autour des parcours critiques
Pour un parcours de paiement, les questions peuvent être : quel taux de confirmation réussit ? où la latence augmente-t-elle ? quelle dépendance produit les erreurs ? quel segment d'utilisateurs est affecté ? La réponse demande un objectif de résultat, une métrique de service, des identifiants de corrélation et des événements structurés. Un CPU moyen peut aider au diagnostic, mais ne doit pas devenir l'objectif principal.
| Signal | Rôle | Exemple de question |
|---|---|---|
| Indicateur de résultat | Détecter le dommage | Les commandes confirmées diminuent-elles ? |
| SLO / budget d'erreur | Décider du niveau d'urgence | La fiabilité acceptable est-elle consommée ? |
| Trace | Suivre une requête ou un message | Où le parcours est-il bloqué ? |
| Log structuré | Expliquer un événement | Quelle erreur et quel état ont été rencontrés ? |
| Événement d'audit | Préserver l'histoire d'une décision | Qui a déclenché cette action sensible ? |
Les alertes doivent appeler une action
Une alerte saine contient le symptôme, le périmètre, la gravité, un lien de diagnostic et le premier geste raisonnable. Alerter sur toutes les ressources intermédiaires produit du bruit et fatigue l'astreinte. Les symptômes de service utilisateur, assortis d'alertes techniques de prévention ciblées, construisent un signal plus humainement soutenable.
Un identifiant de corrélation, une donnée de diagnostic ou un payload de log peut devenir une fuite de confidentialité. Définir ce qui est collecté, masqué, conservé et accessible fait partie de la conception d'observabilité, pas d'un nettoyage ultérieur.
Anti-patterns
Construire un dashboard sans question
Un tableau rempli de graphiques ne raccourcit pas un diagnostic si personne ne sait quelle décision chaque courbe informe. Commencer par la question d'exploitation et ne garder que les signaux qui y répondent.
Alerter sur une cause supposée
Une saturation de ressource peut être un symptôme ou une cause. Déclencher directement une urgence sans lier le signal à un impact utilisateur favorise les faux positifs et masque les dégradations silencieuses.
Journaliser sans structure ni contexte
Des messages libres sans identifiant, niveau, événement ni champs cohérents sont difficiles à interroger sous pression. Les logs utiles racontent des faits corrélables, sans exposer inutilement les données.
Bonnes pratiques
Définir les signaux avec le changement
Une nouvelle capacité critique doit introduire ou mettre à jour ses mesures, ses tableaux de bord et ses alertes au même moment que le comportement. Une instrumentation ajoutée après incident arrive trop tard pour la première erreur et manque souvent du contexte de conception.
Exercer le diagnostic
Pendant une revue de déploiement ou une simulation, demander à une personne non auteure de localiser un scénario dégradé à partir des signaux disponibles. Cet exercice révèle les identifiants manquants, dashboards confus et runbooks théoriques.
Checklist — Peut-on observer le comportement qui compte ?
- Quel résultat utilisateur ou métier permet de détecter une dégradation ?
- Quels signaux montrent le périmètre, la cause probable et l'évolution dans le temps ?
- Les logs, traces et métriques peuvent-ils être corrélés sans révéler de donnée sensible ?
- Quelle alerte déclenche quelle action, pour quelle personne ?
- Les seuils distinguent-ils bruit technique et dommage significatif ?
- Une personne d'astreinte peut-elle diagnostiquer sans dépendre de la mémoire de l'auteur ?
À retenir
L'observabilité n'est pas la collecte de télémétrie. C'est la capacité à voir les effets qui comptent, à les relier aux mécanismes du système et à agir avant que l'incertitude ne devienne un dommage durable.