Produktionsprobleme vom Telefon aus debuggen

Es ist Freitag, 19 Uhr. Du bist beim Abendessen mit Freunden, als dein Telefon mit einer PagerDuty-Warnung vibriert: Die Fehlerrate deines Zahlungsdienstes ist auf 15% gestiegen. Dein Laptop ist zu Hause. Deine Teammitglieder sind offline. Der Vorfall liegt bei dir.

Dieses Szenario ist der Grund, warum Tactic Remote existiert. Dieses Tutorial führt durch einen realistischen Produktions-Debugging-Workflow nur mit deinem iPhone und zeigt, wie man Produktionsprobleme remote untersucht, diagnostiziert und behebt.

Szenario-Aufbau

Für dieses Tutorial arbeiten wir mit einem realistischen Szenario:

• Dienst: Node.js Zahlungsverarbeitungs-API
• Symptom: 500-Fehler auf dem /api/payments/process-Endpoint
• Auswirkung: 15% der Zahlungsversuche schlagen fehl
• Umgebung: Produktionslogs über SSH verfügbar, Codebase auf deinem Mac

Dein Mac läuft zu Hause mit der TacticRemote-Begleit-App. Du verbindest dich von deinem iPhone und beginnst die Untersuchung.

Phase 1: Triage (5 Minuten)

Das erste Ziel ist das Verständnis von Umfang und Dringlichkeit. Starte eine Claude Code-Sitzung, die auf dein Projektverzeichnis zeigt:

We have a production incident. The /api/payments/process endpoint
is returning 500 errors for ~15% of requests. This started approximately
30 minutes ago.

Help me investigate:
1. Check the git log for any recent deployments (last 24 hours)
2. Look at the payment processing code in src/api/payments/
3. Check if there were any dependency updates recently

Claude Code untersucht den Code und die letzten Änderungen. Währenddessen öffne dein Monitoring-Dashboard im Telefon-Browser:

• Ist die Fehlerrate stabil, steigend oder fallend?
• Sind alle Instanzen betroffen oder nur einige?
• Gibt es ein Muster bei den fehlgeschlagenen Anfragen?

Was Claude Code finden könnte: Ein Commit von vor 3 Stunden hat die Stripe SDK-Abhängigkeit von v12.1.0 auf v13.0.0 aktualisiert, was inkompatible API-Änderungen enthielt.

Phase 2: Diagnose (10 Minuten)

Mit einer Hypothese (das Stripe SDK-Update), tiefer graben:

Compare the Stripe SDK v12 and v13 changelog.
Check our payment processing code for any API calls that changed
between versions. Focus on the payment intent creation and
confirmation flow in src/api/payments/processor.ts.

Claude Code analysiert den Code und identifiziert spezifische Inkompatibilitäten. Ein typischer Befund:

Found the issue. In Stripe SDK v13, the `payment_intents.create()` method
changed its error handling behavior:

- v12: Returns { error: { type, message } } for card declines
- v13: Throws StripeCardError exception for card declines

Our code in processor.ts:45-52 checks for `result.error` but doesn't
catch the new exception type. When a card is declined, the uncaught
exception propagates as a 500 error.

This explains the 15% error rate — approximately 15% of payment
attempts involve card declines (expired cards, insufficient funds, etc.)
that now throw uncaught exceptions.

Diese Diagnose ist spezifisch, überprüfbar und erklärt das beobachtete Verhalten. Von deinem Telefon kannst du verifizieren, dass sie Sinn ergibt, bevor du fortfährst.

Phase 3: Korrektur (10 Minuten)

Jetzt die Korrektur implementieren. Du hast zwei Optionen:

Option A: Schneller Rollback

Wenn die Situation dringend ist und die vorherige Version stabil war:

Revert the Stripe SDK update. Change package.json to pin
stripe at v12.1.0. Create a commit with message:
"hotfix: revert Stripe SDK to v12 (fixes payment 500 errors)"

Genehmigungsschritt: Claude Code fordert eine Genehmigung zur Änderung von package.json und zum Ausführen von npm install an. Überprüfe die Änderungen und genehmige.

Option B: Vorwärtskorrektur

Wenn du den Code für v13 anpassen möchtest (um einen Revert zu vermeiden, der andere Verbesserungen verliert):

Fix the payment processing code to handle both the legacy error
response format and the new exception-based error handling in
Stripe SDK v13.

Specifically:
1. Wrap the payment_intents.create() call in a try/catch
2. Catch StripeCardError and convert it to our standard error format
3. Keep the existing result.error check as a fallback
4. Add a test case for the card decline scenario

Commit with: "hotfix: handle Stripe v13 exception-based card decline errors"

Claude Code nimmt die Änderungen vor und führt die Tests aus. Beobachte die Terminal-Ansicht für die Ergebnisse.

Genehmigungsfluss: Du wirst wahrscheinlich mehrere Genehmigungsanfragen sehen:

1. src/api/payments/processor.ts ändern — Genehmigen (das ist die Korrektur)
2. src/api/payments/__tests__/processor.test.ts ändern — Genehmigen (Test hinzufügen)
3. npm test ausführen — Genehmigen (Korrektur verifizieren)

Phase 4: Deployment (5 Minuten)

Mit der committeten und getesteten Korrektur:

Push this commit to the main branch.
Then trigger the deployment pipeline by running our deploy script:
./scripts/deploy.sh production

Kritische Genehmigung: Claude Code fordert eine Genehmigung für den Deploy-Befehl an. Dies ist die riskanteste Aktion im Workflow. Prüfe sorgfältig:

• Verifiziere, dass die Commit-Nachricht zu deiner Korrektur passt
• Bestätige, dass das Deploy-Ziel korrekt ist (production)
• Stelle sicher, dass die Tests im vorherigen Schritt bestanden haben

Nach der Genehmigung führt Claude Code das Deployment aus. Überwache die Terminal-Ausgabe.

Phase 5: Verifizierung (5 Minuten)

Nach Abschluss des Deployments:

Check the deployment status. Then help me verify:
1. Run a test request against the production payment endpoint
2. Check if the error rate has started decreasing
3. Look for any new error patterns in the last 5 minutes

Überprüfe gleichzeitig dein Monitoring-Dashboard. Die Fehlerrate sollte innerhalb von Minuten nach Abschluss des Deploys zu sinken beginnen.

Nach dem Vorfall: Bericht schreiben

Solange der Vorfall frisch in Erinnerung ist (immer noch beim Abendessen, zwischen den Gängen):

Write a post-incident report based on our investigation:

Include:
- Timeline of events
- Root cause (Stripe SDK v13 breaking change)
- Impact (15% payment failure rate for ~1 hour)
- Resolution (code fix to handle new exception type)
- Action items to prevent recurrence

Format as a markdown document in docs/incidents/

Dies gibt deinem Team einen vollständigen Vorfallsbericht vor Montagmorgen. Deine Tischgenossen haben die Unterbrechung kaum bemerkt.

Tipps für effektives Remote-Debugging

Starte breit, dann einengen. Springe nicht sofort zu Hypothesen. Lass Claude Code die Landschaft überblicken (letzte Änderungen, Fehlermuster, Systemzustand), bevor du dich auf eine spezifische Ursache fokussierst.

Nutze Genehmigungsschranken als Kontrollpunkte. Jede Genehmigungsanfrage ist ein natürlicher Kontrollpunkt, an dem du überprüfst, was Claude Code tut.

Trenne Diagnose von Korrektur. Erhalte eine klare Diagnose und bestätige, dass sie Sinn ergibt, bevor du Änderungen implementierst. Das verhindert „Fix-Jagd", bei der du Änderungen ohne Verständnis der Ursache vornimmst.

Kommuniziere während des Debuggings. Wenn dein Team einen Incident-Kanal hat, poste Updates von deinem Telefon:

• „Untersuche Zahlungs-500-Fehler. Verdacht auf Stripe SDK-Update."
• „Bestätigt: SDK v13 hat Fehlerbehandlung für Kartenablehnungen geändert. Deploye Fix."
• „Fix deployed. Fehlerrate normalisiert sich."

Kenne deine Grenzen. Manche Produktionsprobleme erfordern Infrastrukturzugang, Datenbankabfragen oder System-Level-Debugging, das über Claude Code nicht möglich ist. Wenn du nicht weiterkommst, eskaliere.

Dein Incident-Toolkit aufbauen

Bereite dich auf Vorfälle vor:

1. Richte vorab eine Produktions-Debugging-Sitzung ein mit Zugang zu Deployment-Scripts und Monitoring-Tools.
2. Erstelle Incident-Response-Prompts in deiner Prompt-Bibliothek.
3. Teste den Workflow in einer unkritischen Situation.
4. Stelle Cloudflare Tunnel-Zugang sicher, damit du von überall debuggen kannst.

Produktionsvorfälle warten nicht auf günstige Zeitpunkte. Tactic Remote stellt sicher, dass du überall die Werkzeuge hast, um effektiv zu reagieren.