Debugging um 2 Uhr nachts: Was wirklich hilft
Wenn die Produktion down ist und dein Hirn im Nebel steckt — diese Tools und Gewohnheiten retten dich.
Es ist 2 Uhr nachts. Dein Handy vibriert mit einem PagerDuty-Alert. Irgendwas in der Produktion ist kaputt. Dein Gehirn läuft auf vielleicht 40% Kapazität.
Das ist nicht der Zeitpunkt für cleveres Debugging. Das ist der Zeitpunkt für systematische, langweilige, zuverlässige Techniken, die auch funktionieren, wenn du halb schläfst.
Hier ist, was ich aus zu vielen nächtlichen Incidents gelernt habe.
Schritt 1: Was hat sich geändert?
90% der Produktions-Bugs werden durch etwas verursacht, das sich kürzlich geändert hat. Ein Deployment. Ein Config-Update. Eine Datenbank-Migration. Ein abgelaufenes Zertifikat.
Bevor du anfängst, Code zu lesen, finde heraus, was anders ist als beim letzten Mal, wo alles funktioniert hat.
Vergleiche die aktuelle Config mit der letzten bekannt funktionierenden Version. Ein Text-Diff-Tool macht das zu einer 10-Sekunden-Operation, statt zwei Dateien nebeneinander anzustarren.
Im Ernst. Ich habe mal 45 Minuten damit verbracht, einen „mysteriösen" API-Fehler zu debuggen, der sich als falsch gesetztes Komma in einer JSON-Config herausstellte. Ein Diff hätte das in Sekunden gefunden.
Schritt 2: Lies den tatsächlichen Fehler
Klingt offensichtlich. Ist es nicht.
Wenn du müde bist, siehst du eine Fehlermeldung und fängst sofort an, Hypothesen aufzustellen. „Oh, das ist wahrscheinlich die Datenbankverbindung." Du verbringst 20 Minuten damit, die Datenbank zu prüfen. Die Fehlermeldung sagte TypeError: Cannot read property 'name' of undefined. Hat nichts mit der Datenbank zu tun.
Lies den Fehler. Lies ihn nochmal. Lies den Stack Trace. Folge ihm bis zur genauen Codezeile.
Schritt 3: Mach den Fehler lesbar
Produktions-Logs sind chaotisch. Alles steht in einer Zeile, JSON-Objekte sind unformatiert, Zeitstempel sind im Unix-Epoch-Format.
Kopiere den JSON-Blob, füge ihn in einen JSON-Formatierer ein, und plötzlich kannst du die Fehlerantwort tatsächlich lesen.
Ich habe permanent einen Formatierer-Tab offen. Während Incidents nutze ich ihn alle paar Minuten, um API-Antworten, Log-Einträge und Config-Dateien zu entziffern.
Schritt 4: Isolieren, nicht raten
Müde Gehirne lieben es zu raten. „Vielleicht ist es das. Lass mich mal das hier ändern."
Widersteh dem. Jede zufällige Änderung, die du machst, fügt Unsicherheit hinzu. Jetzt weißt du nicht, ob das ursprüngliche Problem behoben ist oder ob dein Fix ein neues Problem eingeführt hat.
Stattdessen: Reproduziere den Fehler mit dem kleinstmöglichen Input. Streiche alles weg, was nicht nötig ist. Finde die eine Variable, die zählt.
Schritt 5: Prüfe die langweiligen Sachen
Bevor du in den Code eintauchst, prüfe:
- DNS: Wird es richtig aufgelöst?
- Zertifikate: Ist eins abgelaufen?
- Speicherplatz: Ist der Server voll?
- Arbeitsspeicher: Leckt irgendwas?
- Abhängigkeiten: Ist eine externe API down?
Ich habe einen Klebezettel an meinem Monitor mit diesen fünf Punkten. Während eines Incidents prüfe ich sie zuerst. Sie waren öfter die Ursache als tatsächliche Code-Bugs.
Das 2-Uhr-nachts-Debugging-Toolkit
Das sind die Browser-Tabs, die ich öffne, wenn mich ein Alert aufweckt:
- Text-Diff — zum Vergleichen von Configs, Umgebungsvariablen, Deployment-Dateien
- JSON-Formatierer — zum Lesen von API-Antworten und Log-Einträgen
- Regex-Tester — zum Durchsuchen von Logs mit Mustern
- Ein einfacher Texteditor — um Notizen zu machen, was ich schon probiert habe
Der letzte Punkt ist wichtiger, als du denkst. Um 2 Uhr nachts ist dein Kurzzeitgedächtnis Müll. Schreib auf, was du probiert hast und was passiert ist. Dein zukünftiges Ich wird deinem vergangenen Ich danken.
Nach dem Incident
Wenn das Feuer gelöscht ist, leg dich nicht einfach wieder schlafen. Verbringe fünf Minuten damit aufzuschreiben:
- Was kaputt war
- Warum es kaputt war
- Was es behoben hat
- Wie man es nächstes Mal verhindert
Du wirst dich morgen nicht daran erinnern. Schreib es jetzt auf.
Das beste Debugging um 2 Uhr nachts ist nicht, schlau zu sein. Es geht darum, systematisch zu sein. Vergleiche die Config. Lies den Fehler. Formatiere die Logs. Prüfe die langweiligen Sachen. Schreib es auf. Das ist das ganze Playbook.