Automatisierte tägliche Fehler-Triage

Zero holt jeden Morgen ungelöste Fehler aus Sentry und Axiom, dedupliziert sie, erstellt GitHub-Issues mit vollständigen Stack-Traces und weist sie automatisch zu.

Zero verbindet:

Das liefert Zero

Automatisierte tägliche Fehler-Triage — sample output from Zero — screenshot 1

Worin das Problem liegt

Jeden Morgen muss jemand Sentry öffnen, durch ungelöste Fehler scrollen, herausfinden, welche neu sind, welche Duplikate, welche wirklich ernst sind, und entscheiden, wer sich um jeden kümmern soll. Das sind 20 bis 30 Minuten konzentrierte Engineering-Zeit, bevor echte Arbeit beginnt. Zero läuft um 8:45 Uhr, prüft Sentry und Axiom, dedupliziert über beide Quellen, wählt die relevanten Fehler aus, eröffnet GitHub-Issues mit dem vollständigen Stack-Trace bereits angehängt und weist jeden zu, bevor jemand den Laptop öffnet.

So löst Zero das Problem

Schritt 1: Tools verbinden

Sentry

Erforderlich

Zero fragt Sentry nach ungelösten Fehlern ab und liest Stack-Traces und Event-Zähler.

Verbinden

GitHub

Erforderlich

Zero erstellt strukturierte GitHub-Issues mit vollständigen Fehlerdetails und weist sie Code-Ownern zu.

Verbinden

Axiom

Optional

Zero fragt Axiom nach Fehler-Logs ab, um Querverweise zu erstellen und gegen Sentry-Befunde zu deduplizieren. Optional, aber empfohlen.

Verbinden

Schritt 2: Zero fragen

@Zero jeden Werktag um 8:45 Uhr, rufe ungelöste Fehler von Sentry und Axiom der letzten 24 Stunden ab. Dedupliziere über Quellen. Für alles mit 5+ Vorkommen, eröffne ein GitHub-Issue in vm0-ai/vm0 mit dem vollständigen Stack-Trace und weise es dem relevanten Code-Owner zu.

ausprobieren

Zero ruft Fehler von Sentry und Axiom ab

Zero fragt beide Quellen nach ungelösten Fehlern im angegebenen Zeitfenster ab. Es wendet Ihren Vorkommensschwellenwert an, um Rauschen zu filtern und sich auf Fehler zu konzentrieren, die tatsächlich in großem Umfang auftreten.

Fehler über Quellen hinweg dedupliziert

Derselbe Fehler taucht oft in Sentry und Axiom mit unterschiedlicher Formatierung auf. Zero identifiziert Duplikate und führt sie zu einem einzelnen Datensatz mit Daten aus beiden Quellen zusammen.

GitHub-Issues erstellt und zugewiesen

Für jeden einzigartigen, qualifizierenden Fehler eröffnet Zero ein strukturiertes GitHub-Issue mit dem vollständigen Stack-Trace, der Vorkommensanzahl, Erst- und Letztgesehen-Zeitstempeln und weist es dem Ingenieur zu, der am wahrscheinlichsten für diesen Codebereich zuständig ist.

Schritt 3: Weiterführende Aktionen

Den Schwellenwert anpassen

Den Vorkommensfilter ändern, um Rauschen zu reduzieren oder mehr Issues zu erfassen

@Zero aktualisiere den täglichen Triage-Zeitplan, sodass nur Issues für Fehler mit 10+ Vorkommen erstellt werden. Alles darunter, poste nur eine Zusammenfassung in #dev.

ausprobieren

Zum Morgenbriefing hinzufügen

Mit dem Produkt-Health-Briefing-Anwendungsfall kombinieren

@Zero füge die heutige Fehler-Triage-Ausgabe in das 9-Uhr-Produkt-Health-Briefing ein, das du in #standup postest.

ausprobieren

Post-Deploy-Sicherheitscheck

Triage unmittelbar nach einem Produktions-Deploy ausführen

@Zero jedes Mal, wenn ein PR in main in vm0-ai/vm0 gemergt wird, warte 15 Minuten und führe dann einen Sentry-Fehlercheck auf neue Fehler durch.

ausprobieren

Tipps für bessere Ergebnisse

●Setzen Sie einen Vorkommensschwellenwert, um die Issue-Anzahl handhabbar zu halten. 5+ ist ein guter Ausgangspunkt; passen Sie je nach Volumen an.

●Nutzen Sie Sentrys Projekt-Tags oder Umgebungen, um Zeros Abfrage nur auf Produktion einzuschränken, nicht auf Staging.

●Verketten Sie dies mit dem Produkt-Health-Briefing: Triage um 8:45 Uhr ausführen, Ausgabe in das 9:00-Uhr-Briefing einbeziehen, damit das Team alles an einem Ort sieht.