Prompt für die Fehler-Ursachenanalyse (Root-Cause-Analysis)

Wann dieser Prompt zum Einsatz kommt

Verwenden Sie diesen Prompt, wenn ein unerwarteter Ausfall in der Produktionsumgebung aufgetreten ist und Sie ein strukturiertes, schuldfreies (blameless) Post-Mortem-Dokument benötigen. Ersetzen Sie die Vorfallsdetails durch Ihre eigenen Stack-Traces, Logs und Telemetriedaten, bevor Sie das Dokument an die beteiligten Engineering-Stakeholder weitergeben.

Der Prompt

## Rolle
Agieren Sie als Staff Reliability Engineer. Wenden Sie ein fundiertes diagnostisches Urteilsvermögen an und stellen Sie sicher, dass technische Erklärungen sowohl für Engineers als auch für funktionsübergreifende Partner verständlich bleiben.

## Kontext
KitePay, eine digitale Checkout-Plattform, verzeichnete einen 27-minütigen Ausfall der Zahlungsabwicklung auf ihrem primären API-Cluster. Die Fehler-Telemetrie zeigte einen abrupten Anstieg von HTTP 504 Gateway Timeouts unmittelbar nach dem Deployment des Releases v2.14.0. Das Release führte einen nicht indizierten Fremdschlüssel-Lookup in der Tabelle `merchant_settlements` während der Token-Autorisierung ein, was zur Erschöpfung des PostgreSQL-Verbindungspools führte. Ein Rollback auf v2.13.9 behob die Timeouts.

## Ziel
Erstellen Sie eine vollständige Ursachenanalyse (Root-Cause Analysis, RCA), die erklärt, wie die Codeänderung die Erschöpfung der Datenbankverbindungen ausgelöst hat, wie der Ausfall eingedämmt wurde und wie ein erneutes Auftreten verhindert werden kann.

## Zielgruppe
Die primären Leser sind Backend-Engineers und Engineering Manager. Liefern Sie ausreichend architektonische Details, um die Behebungsmaßnahmen zu rechtfertigen, ohne sich in unnötigen theoretischen Ausführungen zu verlieren.

## Anforderungen
Ein 400–600 Wörter umfassendes RCA-Dokument, das Folgendes enthält: eine tabellarische Zusammenfassung des Vorfalls; eine chronologische Zeitleiste von Erkennung, Reaktion und Behebung; eine technische Ursachenanalyse nach dem „5 Whys“-Framework; die bereits durchgeführten Sofortmaßnahmen sowie langfristige Präventivmaßnahmen. Fügen Sie explizite Empfehlungen für Datenbankabfragen und Indizes bei.

## Einschränkungen
Erfinden Sie keine nicht aufgeführten Infrastrukturkomponenten, willkürlichen Latenzwerte, Kundenentschädigungssummen oder unbestätigten Service-Abhängigkeiten. Beschränken Sie die technischen Erkenntnisse auf die bereitgestellten Informationen zum Ausfall der Datenbank und des Verbindungspools. Kennzeichnen Sie spekulative Faktoren eindeutig als unbestätigte Annahmen.

## Tonalität & Stil
Bleiben Sie objektiv, schuldfrei (blameless) und analytisch präzise. Verwenden Sie eine klare Fachsprache, prägnante Stichpunkte und eine eindeutige strukturelle Hierarchie. Vermeiden Sie defensive Formulierungen, vage Vermutungen und unverbindliche Zusicherungen.

## Ausgabeformat
Geben Sie das RCA-Dokument zuerst mit eindeutigen Markdown-Überschriften aus. Stellen Sie die Zeitleiste und die Verantwortlichen für die Behebungsmaßnahmen in sauberen Markdown-Tabellen dar. Schließen Sie mit einer Verifizierungs-Checkliste ab, die Telemetrie-Warnungen und Code-Review-Richtlinien detailliert beschreibt, die auditiert werden müssen.

## Was zu vermeiden ist
Vermeiden Sie oberflächliche Schlussfolgerungen wie „menschliches Versagen“, unbelegte Behauptungen über Zero-Downtime sowie das Auslassen des spezifischen Mechanismus der Datenbankabfrage, der zum Ausfall des Connection-Poolings führte.

## Erfolgskriterien
Ein Engineering Lead kann das Dokument lesen und den exakten Fehlermechanismus erklären, nachvollziehen, warum das Rollback den Dienst wiederhergestellt hat, und konkrete präventive Arbeitspakete zuweisen.

## Klärende Fragen
Stellen Sie bis zu drei gezielte Fragen, falls kritische Architekturinformationen fehlen. Fahren Sie andernfalls auf Basis der Szenariodaten fort, benennen Sie Ihre Arbeitsannahmen und skizzieren Sie die Telemetrieprüfungen, die zur Bestätigung des Fixes erforderlich sind.

Warum er funktioniert

• Das Szenario gibt dem Modell einen konkreten technischen Fehlermechanismus vor, anstatt es in generische Muster über Serverabstürze verfallen zu lassen.
• Die Anforderungen verlangen Standard-Artefakte des Engineerings wie die 5-Whys-Analyse und eine präzise Zeitleiste der Behebung.
• Die Einschränkungen verhindern, dass das Modell nicht vorhandene Infrastrukturprobleme oder fehlende Metriken halluziniert.
• Die Erfolgskriterien stellen sicher, dass der resultierende Bericht für technische Leiter sofort überprüfbar und umsetzbar ist.

Passen Sie ihn an

Erstellen Sie eine maßgeschneiderte Version mit PromptDeck indem Sie das fiktive Szenario durch Ihre eigenen Vorfalls-Telemetriedaten, Zeitstempel und Ihren Technologie-Stack ersetzen. Behalten Sie die Verifizierungs-Checkliste bei, damit präventive Engineering-Aufgaben ordnungsgemäß auditiert werden.