Automatizza il triage giornaliero degli errori di produzione

Zero raccoglie gli errori non risolti da Sentry e Axiom ogni mattina, li deduplica, apre issue GitHub con gli stack trace completi e assegna automaticamente l'ingegnere giusto.

Zero connette:

Cosa offre Zero

Automatizza il triage giornaliero degli errori di produzione — sample output from Zero — screenshot 1

Qual è il problema

Ogni mattina qualcuno deve aprire Sentry, scorrere gli errori non risolti, capire quali sono nuovi, quali sono duplicati, quali sono davvero seri e decidere chi debba occuparsi di ciascuno. Sono dai 20 ai 30 minuti di tempo di sviluppo concentrato prima che inizi qualsiasi lavoro vero. Zero gira alle 8:45, controlla Sentry e Axiom, deduplica tra le due fonti, seleziona gli errori che contano, apre issue GitHub con lo stack trace completo già allegato e assegna ciascuna prima che chiunque apra il proprio laptop.

Come Zero lo risolve

Passo 1: Connetti i tuoi strumenti

Sentry

Obbligatorio

Zero interroga Sentry per gli errori non risolti e legge stack trace e conteggi degli eventi.

Connetti

GitHub

Obbligatorio

Zero apre issue GitHub strutturate con i dettagli completi degli errori e le assegna ai code owner.

Connetti

Axiom

Facoltativo

Zero interroga Axiom per i log degli errori per fare cross-reference e deduplicare rispetto ai risultati di Sentry. Opzionale ma consigliato.

Connetti

Passo 2: Chiedi a Zero

@Zero ogni giorno feriale alle 8:45, raccogli gli errori non risolti da Sentry e Axiom delle ultime 24 ore. Deduplica tra le fonti. Per qualsiasi cosa con 5+ occorrenze, apri una issue GitHub in vm0-ai/vm0 con lo stack trace completo e assegnala al code owner pertinente.

provalo

Zero raccoglie gli errori da Sentry e Axiom

Zero interroga entrambe le fonti per gli errori non risolti nella finestra temporale specificata. Applica la tua soglia di occorrenze per filtrare il rumore e concentrarsi sugli errori che stanno effettivamente accadendo su larga scala.

Errori deduplicati tra le fonti

Lo stesso errore spesso compare sia in Sentry che in Axiom con una formattazione diversa. Zero identifica i duplicati e li unisce in un unico record con i dati di entrambe le fonti.

Issue GitHub aperte e assegnate

Per ogni errore unico e qualificante, Zero apre una issue GitHub strutturata con lo stack trace completo, il numero di occorrenze, i timestamp di prima e ultima rilevazione, e la assegna all'ingegnere che con più probabilità è responsabile di quell'area del codice.

Passo 3: Vai oltre

Regola la soglia

Modifica il filtro delle occorrenze per ridurre il rumore o intercettare più problemi

@Zero aggiorna la pianificazione del triage giornaliero per aprire issue solo per errori con 10+ occorrenze. Per tutto ciò che è al di sotto, pubblica solo un riepilogo su #dev.

provalo

Aggiungi al brief mattutino

Combina con il caso d'uso del briefing sullo stato del prodotto

@Zero includi l'output del triage degli errori di oggi nel brief sullo stato del prodotto delle 9 che pubblichi su #standup.

provalo

Controllo di sicurezza post-deploy

Esegui il triage subito dopo un deploy in produzione

@Zero ogni volta che una PR viene mergiata in main su vm0-ai/vm0, aspetta 15 minuti e poi esegui un controllo degli errori su Sentry per i nuovi errori.

provalo

Suggerimenti per risultati migliori

●Imposta una soglia di occorrenze per mantenere gestibile il numero di issue. 5+ è un buon punto di partenza; regolalo in base al tuo volume.

●Usa i tag di progetto o gli ambienti di Sentry per restringere la query di Zero alla sola produzione, non allo staging.

●Concatena questo con il briefing sullo stato del prodotto: esegui il triage alle 8:45, includi l'output nel brief delle 9:00 così il team vede tutto in un unico posto.