Zeitreise-Debugger

Das Problem

Produktionsfehler sind Geister — wenn man sie untersucht, ist der verursachende Zustand bereits verschwunden. Es gibt Logs, vielleicht einen Absturzbericht und einen Zeitstempel. Den Zustand der Anwendung zu diesem exakten Zeitpunkt ueber mehrere Services und Zustandsmutationen hinweg zu rekonstruieren, gleicht der Untersuchung eines bereinigten Tatorts. Die meisten Entwickler geben auf und warten, dass der Fehler erneut auftritt.

Der Prompt

Du bist ein temporaler Debugging-Analyst. Rekonstruiere den Programmzustand zum Zeitpunkt des Ausfalls anhand verfuegbarer Beweise:

ZEITPUNKT DES AUSFALLS: [z.B. 2026-04-10T14:32:17.892Z]
FEHLER/SYMPTOM: [was schiefging]
VERFUEGBARE BEWEISE:
- Logs: [relevante Log-Zeilen mit Zeitstempeln einfuegen]
- Fehlerbericht: [Absturzbericht, Sentry-Event, etc.]
- Letzte Aenderungen: [Deploys oder Konfigurationsaenderungen in der Naehe des Zeitstempels]
- Benutzeraktion: [was der Benutzer tat, falls bekannt]

Fuehre eine temporale Zustandsrekonstruktion durch:
1. **Zeitachse erstellen**: Baue eine praezise Zeitachse von 5 Minuten vor dem Ausfall bis zum Moment des Fehlers. Nutze Log-Zeitstempel zur Sequenzierung.
2. **Zustands-Snapshot**: Rekonstruiere den wahrscheinlichsten Zustand aller relevanten Variablen, Verbindungen und Ressourcen zum Zeitpunkt T-0.
3. **Kausalkette**: Verfolge rueckwaerts — welches Ereignis bei T-N loeste die Kette aus, die zum Ausfall fuehrte?
4. **Geistervariablen**: Welche Variablen oder Zustaende sind NICHT in den Logs sichtbar, muessen aber existiert haben? Leite ihre Werte aus den beobachtbaren Ausgaben ab.
5. **Der Wendepunkt**: Zu welchem exakten Zeitpunkt wechselte das System von gesund zu defekt? Was war der Ausloeser?
6. **Reproduktionsrezept**: Liefere die minimale Aktionssequenz und Zustandskonfiguration zur Reproduktion in einer Testumgebung.

Beispiel-Ausgabe

Zeitachse: T-4min: Deploy v2.3.1 → T-2min: Cache-TTL laeuft ab → T-1min: Erster Request trifft neuen Code mit veraltetem Cache-Format → T-0: JSON.parse scheitert an Legacy-Cache-Eintrag
Zustand bei T-0: Cache enthaelt v2.2-Format (String), neuer Code erwartet v2.3-Format (Objekt), keine Migration durchgefuehrt
Kausalkette: Deploy ohne Cache-Flush → veraltete Eintraege ueberleben → Formatkonflikt → Parse-Fehler → 500
Geistervariable: cache.userSession war ein serialisierter String statt eines Objekts — nicht geloggt, aber aus dem TypeError abgeleitet

Wann verwenden

Diesen Skill einsetzen bei der nachtraeglichen Analyse von Produktionsvorfaellen, wenn der Fehler nicht auf Abruf reproduziert werden kann, oder bei intermittierenden Ausfaellen, die von spezifischen Timing-Bedingungen abhaengen. Unverzichtbar fuer Post-Mortem-Analysen.

Profi-Tipps

• Ueber Services hinweg korrelieren — Request-IDs oder Trace-IDs verwenden, um Logs aus mehreren Services zu einer einzigen Zeitachse zusammenzufuegen.
• Pruefen, was NICHT geloggt wurde — fehlende Log-Eintraege sind oft aufschlussreicher als vorhandene. Ein fehlender “Request abgeschlossen”-Log bedeutet, der Prozess stuerzte waehrend der Ausfuehrung ab.
• Erfolgreiche Nachbar-Requests betrachten — den fehlgeschlagenen Request mit erfolgreichen Requests bei T-1min und T+1min vergleichen. Der Diff offenbart die einzigartigen Bedingungen.
• Deploy-Zeitstempel sind kritisch — die meisten mysterioesen Produktionsfehler korrelieren mit einem kuerzlichen Deploy, einer Konfigurationsaenderung oder einem Infrastruktur-Ereignis.