Ein Kunde meldet, die App sei kaputt, aber du kannst es nicht reproduzieren. Was schaust du dir an?

Starte mit Details: welches Konto, welche Uhrzeit, welche Aktion, was sie gesehen haben. Verfolg diesen Request dann über Logs, Traces und Fehlerberichte anhand einer gemeinsamen Request- oder Trace-Id, damit du den ganzen Pfad siehst und nicht einen Service. Vergleich Fehlerrate und Latenz mit demselben Zeitfenster gestern, um eine echte Regression von Hintergrundrauschen zu trennen. Taucht nichts auf, ist die Lücke die Instrumentierung, ergänz also strukturiertes Logging auf diesem Pfad.

Das Erste, was ich tue, ist die Meldung in etwas Durchsuchbares zu verwandeln: Konto-Id, ungefährer Zeitstempel mit Zeitzone, welcher Button, was auf dem Bildschirm erschien. Vage Meldungen bleiben unlösbar, dieses Gespräch sind also fünf Minuten wert. Dann gehe ich zum Trace eines Requests in diesem Fenster und folge ihm über die Services, denn eine einzelne Service-Logzeile sagt selten, ob der Fehler bei uns, der Datenbank oder einem Fremdsystem lag. Parallel schaue ich auf Fehlerrate und Latenz im Vergleich zur gleichen Zeit am Vortag, denn ein Anstieg, der zu einer bekannten Deploy-Zeit passt, ist meist schon die ganze Antwort. Was ich früh prüfe, ist, ob es umgebungsbedingt ist: eine Region, ein Browser, ein alter Service Worker, der alte Assets ausliefert, oder ein Firmenproxy, der einen Header entfernt. Ist nirgends etwas sichtbar, höre ich mit der Jagd auf und behandle das als Befund, ergänze dann strukturierte Logs mit Request-Id, Nutzer-Id und den Entscheidungszweigen auf diesem Pfad, damit die nächste Meldung Minuten dauert. Logs bekommen Identifikatoren, nie Tokens oder personenbezogene Daten.