La plupart des piles d’observabilité sont excellentes pour répondre à une question: que s’est-il passé?
Ils sont plus faibles à la question suivante: où pouvons-nous résoudre ce problème?
C’est dans cet écart que la réponse aux incidents ralentit. L'équipe voit le taux d'erreur, ouvre la trace, lit les journaux, vérifie le calendrier de déploiement, puis doit encore rechercher manuellement la base de code.
Un incident familier
Imaginez qu'une API commence à renvoyer 500 secondes par intermittence après un déploiement. Le tableau de bord montre le pic. Les points de trace au service de caisse. Les journaux incluent une erreur de validation, mais le message est générique.
A ce moment-là, l’équipe n’a pas besoin d’une autre carte. Il a besoin d’une direction:
- le référentiel qui possède la caisse
- le gestionnaire connecté à la route défaillante
- le commit récent qui a changé le comportement de validation
- la personne ou l'équipe qui doit examiner le correctif
C'est le contexte du code.
Pourquoi le contexte du code est important
L'observabilité sans contexte de code crée une prise de conscience. L'observabilité avec le contexte de code crée un chemin à réparer.
La différence est faible mais importante sur le plan opérationnel. Une trace peut vous indiquer qu'une requête a échoué POST / paiement. Le contexte du code peut pointer vers la branche de validation, le fichier qui a été modifié hier et le propriétaire qui examine habituellement cette zone.
Cette cartographie permet d'économiser la première heure de nombreux incidents.
Le contexte minimum utile
Vous n’avez pas besoin de joindre l’intégralité de l’enquête à une pull request. Un évaluateur a généralement besoin d’un ensemble compact de faits:
- symptôme de production
- service concerné
- fichier ou fonction probable
- déploiement récent ou changement de code
- propriétaire ou évaluateur
- prochaine action proposée
Rien de plus ne devrait étayer ces faits, et non les enterrer.
Là où s'arrêtent les tableaux de bord
Les tableaux de bord permettent de visualiser le comportement du système. Les demandes d'extraction servent à modifier le comportement du système. Un flux de travail de remédiation sain connecte ces mondes au lieu de demander aux ingénieurs de les relier manuellement à chaque fois.
Si le signal ne parvient pas à trouver le code, l'alerte devient un autre élément de la file d'attente. Si le signal parvient à trouver le code, l'équipe peut décider de corriger, de restaurer, d'ouvrir un élément du backlog ou d'enquêter plus en profondeur.
Vers quoi construire
L’objectif pratique n’est pas une plus grande surface d’observabilité. C'est un chemin plus court:
signal de production -> contexte de code -> action révisable
Cette action pourrait être une pull request. Cela pourrait être un problème avec Jira. Il peut s'agir d'une note indiquant que le problème appartient à un fournisseur en amont. Le fait est que l’équipe ne devrait pas avoir à repartir d’une enquête vide à chaque fois que la production parle.
L’observabilité montre l’échec. Le contexte du code donne à l'échec quelque part où aller.
