Tous les cas d'usage

Automatisez le triage quotidien des erreurs de production

Zero récupère chaque matin les erreurs non résolues depuis Sentry et Axiom, les déduplique, ouvre des issues GitHub avec les stack traces complètes et assigne automatiquement le bon ingénieur.

Zero se connecte à :SentryAxiomGitHub

Ce que Zero livre

Quel est le problème

Chaque matin, quelqu'un doit ouvrir Sentry, faire défiler les erreurs non résolues, déterminer lesquelles sont nouvelles, lesquelles sont des doublons, lesquelles sont réellement sérieuses, et décider qui doit prendre en charge chacune. Cela représente 20 à 30 minutes de temps d'ingénierie concentré avant le moindre vrai travail. Zero s'exécute à 8h45, vérifie Sentry et Axiom, déduplique entre les deux, sélectionne les erreurs qui comptent, ouvre des issues GitHub avec la stack trace complète déjà jointe et assigne chacune avant que quiconque n'ouvre son ordinateur.

Comment Zero le corrige

Étape 1 : Connectez vos outils

Sentry
Sentry
Requis
Zero interroge Sentry pour les erreurs non résolues et lit les stack traces et le nombre d'événements.
Connecter
GitHub
GitHub
Requis
Zero crée des issues GitHub structurées avec tous les détails de l'erreur et les assigne aux propriétaires du code.
Connecter
Axiom
Axiom
Optionnel
Zero interroge Axiom pour les logs d'erreurs afin de les recouper et de les dédupliquer par rapport aux constats Sentry. Optionnel mais recommandé.
Connecter

Étape 2 : Demandez à Zero

@Zero chaque jour de semaine à 8h45, récupère les erreurs non résolues de Sentry et Axiom pour les dernières 24 heures. Déduplique entre les sources. Pour tout ce qui compte 5 occurrences ou plus, ouvre une issue GitHub dans vm0-ai/vm0 avec la stack trace complète et assigne-la au propriétaire du code concerné.
Zero récupère les erreurs de Sentry et Axiom
Zero interroge les deux sources pour les erreurs non résolues dans la fenêtre temporelle indiquée. Il applique votre seuil d'occurrences pour écarter le bruit et se concentrer sur les erreurs qui se produisent réellement à grande échelle.
Erreurs dédupliquées entre les sources
La même erreur apparaît souvent à la fois dans Sentry et Axiom avec un formatage différent. Zero identifie les doublons et les fusionne en un seul enregistrement combinant les données des deux sources.
Issues GitHub créées et assignées
Pour chaque erreur unique et qualifiée, Zero ouvre une issue GitHub structurée avec la stack trace complète, le nombre d'occurrences, les horodatages de première et dernière apparition, et l'assigne à l'ingénieur le plus susceptible de posséder cette partie du code.

Étape 3 : Allez plus loin

Ajuster le seuil
Modifiez le filtre d'occurrences pour réduire le bruit ou capturer plus d'erreurs
@Zero mets à jour le calendrier de triage quotidien pour ne créer d'issues que pour les erreurs comptant 10 occurrences ou plus. Pour tout ce qui est en dessous, publie simplement un résumé dans #dev.
Ajouter au brief du matin
Combinez avec le cas d'usage du brief de santé produit
@Zero inclus le résultat du triage des erreurs du jour dans le brief de santé produit de 9h que tu publies dans #standup.
Vérification de sécurité post-déploiement
Lancez le triage immédiatement après un déploiement en production
@Zero chaque fois qu'une PR est fusionnée dans main sur vm0-ai/vm0, attends 15 minutes puis lance une vérification Sentry des nouvelles erreurs.

Conseils pour de meilleurs résultats

Définissez un seuil d'occurrences pour garder le nombre d'issues gérable. 5 et plus est un bon point de départ ; ajustez selon votre volume.
Utilisez les étiquettes de projet ou les environnements de Sentry pour restreindre la requête de Zero à la production uniquement, pas au staging.
Enchaînez cela avec le brief de santé produit : lancez le triage à 8h45, incluez le résultat dans le brief de 9h00 pour que l'équipe voie tout au même endroit.