Il dit pourquoi, et il dit à quel point il en est sûr

Un changement est un indice, pas de l’historique

Presque toutes les plateformes rangent les déploiements sur une page à part, comme une archive de ce qui s’est passé. C’est le mauvais endroit. Le déploiement le plus proche de la première apparition d’une erreur est le plus fort indice dont on dispose sur cette erreur, et sa place est sur l’erreur.

C’est donc là qu’il est. Un problème porte le déploiement le plus proche de sa première apparition, l’écart entre les deux et — c’est ce qui compte — de quel côté de cette première apparition le déploiement tombe. Une mise en production partie quatre minutes avant la première erreur est un fait tout différent d’une mise en production partie quatre minutes après, et une plateforme qui ne montre que « les déploiements récents » a jeté cette distinction.

On ne parle pas de « commit suspect », et ce refus est délibéré. La plateforme sait qu’un changement est parti près d’une panne. Elle ne sait pas que ce changement a causé la panne, et le qualifier de suspect, c’est tirer une conclusion d’une coïncidence. La page dit ce qu’elle sait, et dit qu’une corrélation n’est pas une cause.

Gradué, pas noté

Une conclusion revient en confiance haute, moyenne ou faible, et le grade est rattaché aux indices qui l’ont produite : un changement dans la fenêtre, une modification de configuration, des signaux indépendants qui concordent.

L’alternative — « 98 % de confiance » — est la norme du secteur et c’est une fabrication. Aucun calcul ne se cache derrière un tel nombre, et sa fonction réelle est de vous dissuader de demander quels étaient les indices. Un grade que vous pouvez remonter jusqu’à trois faits vaut mieux qu’une décimale que vous ne pouvez remonter jusqu’à rien.

Posez-lui la question sur votre propre système

Deux questions se posent directement à la carte des services, plutôt qu’à une fenêtre de discussion qui devrait deviner quels sont vos services. Pourquoi cela a-t-il échoué, et avec quoi cette chose parle-t-elle réellement — les deux répondues contre votre topologie réelle, construite à partir des spans que vous avez déjà envoyés.

Les réponses sont des sorties de modèle et sont présentées comme telles. Ce n’est pas une précaution de style : c’est la différence entre un outil utilisable pendant un incident et un outil à auditer pendant un incident.

Faire relire un changement avant sa mise en production

Le même moteur lit un diff. Une étape de build envoie le changement, les constats reviennent en annotations sur la pull request, et lorsqu’un constat justifie une modification précise, celle-ci l’accompagne — sous forme d’un couple recherche/remplacement vérifié contre le diff réellement envoyé.

Rien n’est committé et rien n’est poussé. SnagSpy ne détient aucun accès à votre dépôt : la modification revient à votre pipeline, et c’est votre pipeline qui décide de l’appliquer. Le job n’a besoin que de lire le contenu du dépôt, ce qui est bien plus petit à accorder qu’un accès en écriture sur votre branche principale.

npx snagspy review --base origin/main

# et, dans le checkout d’un développeur, pour appliquer le retour
npx snagspy review --base origin/main --fix

Deux consentements, désactivés jusqu’à ce que vous les activiez

La télémétrie et le code source sont deux catégories de secret différentes, et un consentement unique couvrant les deux serait un consentement sur lequel personne ne pourrait raisonner.

L’analyse par IA de votre télémétrie est un interrupteur, par projet. L’envoi de code source pour relecture en est un second, distinct, désactivé au départ, avec une permission propre qu’une clé d’API doit porter explicitement. Une clé qui peut lire vos erreurs ne peut envoyer votre code nulle part.

Ce qu’il ne fera pas

Le paragraphe le plus utile de cette page, et celui que les pages de ce genre omettent le plus souvent.

• Il ne prédit pas les pannes. Prédire une panne qui n’a pas eu lieu suppose de deviner, et une devinette portant un grade de confiance est pire que le silence.
• Il n’ouvre pas de pull request à votre place, et ne détient aucun accès qui le lui permettrait.
• Il n’a pas toujours raison. Un constat est une sortie de modèle : gradué, traçable, relisible — et cela reste quelque chose qu’une personne doit lire.
• Il n’est pas facturé par contributeur. Les enquêtes sont comptabilisées sur votre offre.