Prompt-Vorlagen zum Debuggen von Produktionsproblemen

Belege -> Hypothesen -> Überprüfung -> kleinste Korrektur -> Validierung

Wir müssen ein Produktionsproblem untersuchen. Schlage noch keine Codeänderung vor.

Symptome: [Was Nutzer oder Monitoring zeigen.]
Erwartetes Verhalten: [Was passieren sollte.]
Beobachtetes Verhalten: [Was tatsächlich passiert.]
Auswirkung: [Wer betroffen ist, Häufigkeit, Schweregrad und, falls bekannt, sicherer Fallback.]
Umgebung: [Version, Bereitstellung, Browser/OS, Region, Feature Flags oder
Laufzeitdetails.]
Kürzliche Änderungen: [Relevante Deployments, Migrationen, Konfiguration oder Abhängigkeiten.]
Belege: [Bereinigte Logs, Fehler, Metriken, Trace IDs, Screenshots, Befehle.]
Reproduktion: [Zuverlässige Schritte oder der Hinweis, dass sie intermittierend ist.]

Gib zurück:
1. eine knappe Zeitleiste bestätigter Fakten;
2. die wichtigsten Hypothesen, nach Wahrscheinlichkeit und Auswirkung geordnet;
3. die nächste sichere Beobachtung oder den nächsten Reproduktionsschritt für jede Hypothese;
4. fehlende Informationen, die die Diagnose wesentlich blockieren.

Versuche, dieses Problem lokal oder in der genehmigten Nicht-Produktionsumgebung zu
reproduzieren.

Erwartet: [Erwartetes Ergebnis.]
Beobachtet: [Tatsächliches Ergebnis.]
Einrichtung: [Fixture, Kontozustand, Befehl, Konfiguration oder Testdaten.]
Zu untersuchende kürzliche Änderung: [Commit, Release oder Verhaltensänderung.]

Bearbeite keinen Produktionscode, bis der Fehler reproduziert ist oder wir eine
beleggestützte Erklärung haben, warum eine Reproduktion nicht möglich ist. Erfasse den
kleinsten fehlschlagenden Test, die kleinste Log-Sequenz oder Befehlsausgabe, die die
führenden Hypothesen unterscheidet.

Analysiere diese bereinigten Logs auf einen Produktionsfehler.

Kontext: [Service/Feature und erwarteter Request-Ablauf.]
Zeitfenster: [Start/Ende und Zeitzone.]
Erwartetes Verhalten: [Erwarteter Erfolgspfad.]
Beobachtetes Verhalten: [Fehler oder beeinträchtigtes Verhalten.]
Kürzliche Änderungen: [Änderungen an Deployment/Konfiguration/Abhängigkeiten.]
Logs: [Bereinigte Einträge in chronologischer Reihenfolge.]

Trenne Fakten von Schlussfolgerungen. Korreliere Ereignisse nur, wenn IDs, Zeitstempel oder
kausale Belege dies stützen. Liste plausible Hypothesen, das Log oder die Metrik, die jede
bestätigen würde, und die nächste Beobachtung mit dem geringsten Risiko auf.

Untersuche, warum dieser Produktionswartungsbefehl fehlgeschlagen ist.

Befehl: [Exakter Befehl mit entfernten Geheimnissen.]
Erwartete Ausgabe: [Erwartetes Erfolgssignal.]
Beobachtete Ausgabe: [Exaktes bereinigtes stderr/stdout und Exit-Code.]
Umgebung: [Shell, Arbeitsverzeichnis, OS/Laufzeitversion, relevante Dateien.]
Kürzliche Änderungen: [Skript- oder Bereitstellungsänderungen.]

Erkläre zuerst, was der Befehl tatsächlich tut, und identifiziere den frühesten
fehlgeschlagenen Schritt. Schlage sichere Diagnosebefehle vor, die keine Daten verändern.
Erst nachdem der Fehler verstanden ist, schlage die kleinste Korrektur und ihre Validierung
in einer Nicht-Produktionsumgebung vor.

Bewerte, ob diese Regression mit dem kürzlichen Rollout zusammenhängt.

Baseline: [Verhalten/Version vor dem Rollout.]
Änderung: [Release, Flag, Migration oder Konfigurationsunterschied.]
Beobachtete Regression: [Wer betroffen ist und wie.]
Belege: [Metriken, Logs, Traces, Screenshots oder eine Reproduktion.]
Einschränkungen: Ändere weder den Rollout noch migriere Daten, bis die Belege eine
Entscheidung stützen. Bewahre den Rollback-Pfad.

Vergleiche den Baseline- und den geänderten Pfad. Identifiziere das kleinste Experiment,
die kleinste Feature-Flag-Prüfung oder den Nicht-Produktions-Test, die Kausalität bestätigen
könnten. Empfiehl Rollback, Abmilderung oder Codeuntersuchung mit dem Vertrauen und den
Abwägungen für jede Option.

Bestätigte Ursache: [Durch Belege gestützte Grundursache.]
Umfang: [Zu ändernde Dateien, Modul oder Konfiguration.]
Zu bewahrendes Verhalten: [Bestehender Erfolgspfad, öffentlicher Vertrag, Berechtigungen,
Daten, Locale, Performance oder Rollback-Verhalten.]

Schlage die kleinste Korrektur vor. Gib an:
- warum sie die bestätigte Ursache behebt;
- den Regressionstest oder die reproduzierbare Prüfung;
- die Validierung in einer genehmigten Nicht-Produktionsumgebung;
- Überlegungen zu Rollout, Monitoring und Rollback;
- Verhalten, das unsicher bleibt.

Nimm kein nicht zusammenhängendes Refactoring in diese Änderung auf.

Validiere die Korrektur anhand des ursprünglichen Vorfalls.

Prüfe:
1. Die ursprüngliche Reproduktion oder der fehlschlagende Test besteht jetzt;
2. der normale Erfolgspfad bleibt unverändert;
3. relevante Fehler- und Randpfade verhalten sich weiterhin sicher;
4. Bereitstellungs- oder Monitoring-Signale zeigen die erwartete Wiederherstellung;
5. die Rollback-Bedingung bleibt verfügbar.

Melde die Belege für jede Prüfung und nenne explizit alles, was nicht überprüft wurde.