Alle Anwendungsfälle

Triagieren Sie Produktionsfehler jeden Morgen, ohne Sentry zu öffnen

Planen Sie Zero für tägliche Ausführung. Es ruft ungelöste Fehler von Sentry und Axiom ab, dedupliziert über Quellen hinweg, eröffnet ein GitHub-Issue mit dem vollständigen Stack-Trace und weist es automatisch dem richtigen Ingenieur zu.

Zero verbindet:SentryAxiomGitHub

Warum die morgendliche Fehler-Triage die erste Stunde Engineering-Zeit frisst

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 richten Sie die tägliche automatisierte Fehler-Triage mit Zero ein

@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.

Wie Zero Fehler aus Sentry und Axiom abruft, dedupliziert und erfasst

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.

Issues zuweisen, Schwellenwerte anpassen oder mit dem Standup-Briefing kombinieren

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.
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.
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.

Erforderliche Integrationen: Sentry, GitHub und Axiom

Sentry
Sentry
Zero fragt Sentry nach ungelösten Fehlern ab und liest Stack-Traces und Event-Zähler.
Erforderlich
GitHub
GitHub
Zero erstellt strukturierte GitHub-Issues mit vollständigen Fehlerdetails und weist sie Code-Ownern zu.
Erforderlich
Axiom
Axiom
Zero fragt Axiom nach Fehler-Logs ab, um Querverweise zu erstellen und gegen Sentry-Befunde zu deduplizieren. Optional, aber empfohlen.
Optional

Best Practices für geplante Produktionsfehler-Triage

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.