Debugging Production Issues at 2 AM: A Survival Guide [Deutsch]

# Fehlerbehebung von Produktionsproblemen um 2 Uhr morgens: Ein Überlebenshandbuch 2:17 Uhr. PagerDuty. Die Warnung besagt, dass die Fehlerrate des Zahlungsdienstes 95 % beträgt. 847 betroffene Transaktionen. Dein Magen zieht sich zusammen. Du bist sofort wach – diese spezielle Art von Adrenalin, die nur durch Produktionsvorfälle ausgelöst wird. Dein Telefon ist bereits entsperrt, Laptop bootet, die Kaffeemaschine erwacht nur durch Muskelgedächtnis zum Leben. Dies ist Seite Nummer 847 in deiner Karriere. Ja, du führst Buch darüber. Du hast nach Seite 200 angefangen zu zählen, als du erkannt hast, dass dies ein prägenden Teil deines Berufslebens sein würde, und wenn du um unchristliche Uhrzeiten geweckt wirst, solltest du wenigstens Daten darüber haben. Der Zahlungsdienst. Natürlich ist es der Zahlungsdienst. Es ist immer der Zahlungsdienst, oder die Authentifizierungsebene, oder dieser eine Mikroservice, von dem jemand vor drei Jahren schwor, dass es "nur ein einfacher Wrapper" sei und der sich seitdem zu einer kritischen Abhängigkeit für die Hälfte deiner Infrastruktur entwickelt hat. Du hast vielleicht 90 Sekunden, bevor die zweite Seite an deinen Manager ausgeht. Vielleicht drei Minuten, bevor Kunden anfangen, die Support-Kanäle zu überfluten. Vielleicht fünf Minuten, bevor jemand aus der C-Suite aufwacht und Fragen in Slack stellt. Die Uhr tickt, deine Hände bewegen sich und dein Gehirn läuft bereits durch die mentale Checkliste, die du dir über Hunderte von Vorfällen hinweg aufgebaut hast. Das ist nicht dein erstes Rodeo. Aber hier ist, was dir niemand über die Fehlerbehebung in der Produktion um 2 Uhr morgens sagt: Es wird nie einfacher. Du wirst einfach schneller. Du baust bessere Werkzeuge. Du machst weniger dumme Fehler. Du lernst, deinen Instinkten zu vertrauen und gleichzeitig alles zu hinterfragen. Du entwickelst ein Gespür dafür, was tatsächlich kaputt ist und was nur kaputt aussieht. Und am wichtigsten, du lernst, dass der Unterschied zwischen einem 10-minütigen Vorfall und einem 4-stündigen Vorfall oft auf die ersten 60 Sekunden deiner Reaktion zurückzuführen ist. Dieser Leitfaden ist alles, was ich mir gewünscht hätte, dass mir jemand vor Seite Nummer 1 gesagt hätte.

Die ersten 60 Sekunden: Triage wie dein Job davon abhängt

Die erste Minute eines jeden Produktionsvorfalls ist reines Chaosmanagement. Dein Gehirn bootet noch, du trägst wahrscheinlich keine Hose und du musst kritische Entscheidungen treffen, die darüber entscheiden, ob dieser Vorfall in Minuten oder Stunden gelöst wird. Hier ist, was ich in der Reihenfolge jedes Mal mache: Bestätige die Seite sofort. Warte nicht, um "zuerst zu untersuchen." Bestätige sie. Das stoppt die Eskalationskette und signalisiert deinem Team, dass jemand sich darum kümmert. Ich habe zu viele Vorfälle gesehen, bei denen mehrere Personen alarmiert wurden, weil der erste Reagierende "nur einen schnellen Blick darauf werfen" wollte, bevor er bestätigte. Diese 30 Sekunden der Untersuchung kosten dir Backup-Responder, die hätten schlafen können. Öffne dein Incident-Response-Dashboard. Nicht die Anwendung. Nicht die Protokolle. Dein Dashboard. Das, das dir die Systemgesundheit auf einen Blick zeigt. Für mich ist das ein benutzerdefiniertes Grafana-Dashboard, das Fehlerraten, Latenz-Percentiles, Datenbankverbindungspools, Warteschlangentiefe und CPU/Memory über alle kritischen Dienste hinweg anzeigt. Ich kann den Explosionsradius in unter 5 Sekunden sehen. Überprüfe, ob es noch passiert. Das klingt offensichtlich, aber ich wurde schon für Probleme alarmiert, die sich 30 Sekunden bevor der Alarm auslöste selbst behoben haben. Überwachungssysteme haben Verzögerungen. Alarmgrenzen haben Bewertungsfenster. Manchmal ist das Problem bereits verschwunden, und du musst das wissen, bevor du mit dem Zurücksetzen von Bereitstellungen oder dem Neustarten von Diensten beginnst. Bewerte den Einfluss auf die Kunden. Nicht theoretischen Einfluss – tatsächlichen Einfluss. Wie viele Benutzer sind gerade betroffen? Sind es 100 % des Traffics oder 5 %? Ist es auf eine Region, ein Kundensegment oder eine Funktion beschränkt? Das bestimmt die Dringlichkeit deiner Reaktion und ob du mehr Leute aufwecken musst. In diesem speziellen Vorfall – dem Zahlungsdienst um 2:17 Uhr – hat mir mein Dashboard in 8 Sekunden alles gesagt, was ich wissen musste. Fehlerrate: 94,7 %. Betroffene Anfragen: 847 in den letzten 5 Minuten. Geografische Verteilung: global. Kundensegment: alle. Latenz der Zahlungsanbieter-API: normal. Datenbankverbindungen: normal. Das Problem lag nicht weiter vorne oder hinten. Es war unser Problem. Das war der Moment, in dem ich wusste, dass ich eine lange Nacht vor mir hatte.

Die Fehlersuchemethodik, die tatsächlich unter Druck funktioniert

Jeder hat eine Fehlersuchemethodik, wenn er ruhig, koffeiniert und um 14 Uhr in einer Entwicklungsumgebung arbeitet. Sehr wenige Leute haben eine Methodik, die hält, wenn du halb schlafend bist, der CEO im Vorfallskanal ist und jede Sekunde Ausfallzeit echtes Geld kostet. Ich verwende das, was ich den "Explosionsradius zur Ursachenermittlung" Ansatz nenne. Es ist nicht ausgeklügelt, aber es funktioniert, wenn dein Gehirn bei 60 % Kapazität läuft. Beginne mit dem Explosionsradius, nicht der Ursachenermittlung. Das ist kontraintuitiv. Jedes Instinkt sagt dir, gleich die Ursache zu finden. Widerstehe diesem Instinkt. Zuerst verstehe genau, was kaputt ist und was nicht. Kartiere die Grenzen des Fehlers. Dies dient zwei Zwecken: es verhindert, dass du roten Heringen in gesunden Systemen folgst, und es zeigt oft direkt auf die Ursache durch einen Eliminationsprozess. Für den Vorfall des Zahlungsdienstes verbrachte ich 90 Sekunden damit, den Explosionsradius zu kartieren: - Zahlungsinitiierung: fehlgeschlagen - Zahlungsstatusüberprüfungen: fehlgeschlagen - Zahlungswebhooks: fehlgeschlagen - Rückerstattungsverarbeitung: funktioniert einwandfrei - Admin-Zahlungsabfragen: funktionieren einwandfrei Dieses Muster sagte mir etwas Wichtiges: Leseoperationen waren in Ordnung, Schreiboperationen schlugen fehl. Das ist ein Datenbankproblem, ein Warteschlangenproblem oder ein Berechtigungsproblem. Drei Möglichkeiten statt dreißig. Folge dem Datenfluss, nicht dem Codefluss. Wenn du um 2 Uhr morgens debuggierst, hast du keine Zeit, den Code zu verfolgen. Verfolge die Daten. Wo tritt eine Zahlungsanforderung in das System ein? Wohin geht sie als nächstes? Wo schlägt sie fehl? Ich habe unser verteiltes Tracing aufgerufen (Gott sei Dank hatten wir es) und einen einzelnen Request beobachtet, der durch das System floss. Er kam durch die Authentifizierung, durch die Ratenbegrenzung, durch die Validierung und starb im Moment, als er versuchte, in die Datenbank zu schreiben. Datenbank. Da war es. Überprüfe zuerst die langweiligen Dinge. Speicherplatz. Arbeitsspeicher. Verbindungspools. Dateideskriptoren. Ablauf von Zertifikaten. DNS. Die langweiligen Dinge bringen mehr Produktionssysteme nieder als schlaue Bugs jemals tun werden. Ich wurde um 2 Uhr morgens gerufen, weil jemandes Cron-Job den Speicherplatz gefüllt hatte. Ich wurde gerufen, weil ein Zertifikat abgelaufen war. Ich wurde gerufen, weil jemand die DNS-TTL geändert hatte und nicht auf die Propagation gewartet hatte. In diesem Fall war der Datenbankverbindungspool bei 100 %. Jede einzelne Verbindung war in Nutzung. Aber warum? Der Traffic war nicht angestiegen. Die Abfrage-Muster hatten sich nicht verändert. Irgendetwas hielt die Verbindungen offen. Vertraue deiner Überwachung, aber verifiziere alles. Überwachungssysteme lügen. Nicht böswillig – sie sind einfach Software und Software hat Bugs. Ich habe Überwachungssysteme gesehen, die gesunde Dienste meldeten, die komplett ausgefallen waren. Ich habe gesehen, dass sie Fehler meldeten, die nicht existierten. Überprüfe immer den kritischen Pfad manuell. Für Zahlungssysteme habe ich eine Test-Kreditkarte und einen Curl-Befehl bereit. Ich kann den gesamten Zahlungsfluss in 10 Sekunden validieren. Ich habe meine Testzahlung durchgeführt. Sie hing 30 Sekunden und zeitigte aus. Die Überwachung loggte nicht falsch. Wir waren tatsächlich down.

Der Vorfall, der mir alles über Datenbankverbindungen beigebracht hat

Lass mich dir von Seite Nummer 312 erzählen. Es war 3:47 Uhr an einem Dienstag im März, und es hat für immer verändert, wie ich über das Management von Datenbankverbindungen nachdenke. Wir hatten einen Flash-Verkauf. Der Traffic war hoch, aber nicht beispiellos – wir hatten größere Spitzen bewältigt. Dann begannen plötzlich alle Dienste, die mit der Datenbank verbunden waren, timeouts zu erzeugen. Verbindungspool erschöpft. Klassische Symptome. Die naheliegende Antwort: Erhöhe die Größe des Verbindungspools. Also taten wir es. Wir verdoppelten ihn. Dann verdreifachten wir ihn. Das Problem wurde schlimmer. Das war der Moment, als ich lernte, dass manchmal die Lösung das Problem verschärft. Jede Verbindung, die wir dem Pool hinzufügten, war eine weitere Verbindung, die versuchte, eine Abfrage auf einer bereits überlasteten Datenbank auszuführen. Wir DDoS'en uns selbst. Das eigentliche Problem? Ein Entwickler hatte eine neue Funktion hinzugefügt, die einen vollständigen Tabellen-Scan auf einer Tabelle mit 50 Millionen Zeilen durchführte. Kein Index. Die Abfrage dauerte 45 Sekunden, um abgeschlossen zu werden. Jede Anfrage, die diesen Codepfad traf, hielt eine Datenbankverbindung für 45 Sekunden. Bei genügend Traffic erschöpften wir den Verbindungspool nicht, weil wir nicht genügend Verbindungen hatten, sondern weil jede Verbindung festsaß und auf den Abschluss dieser schrecklichen Abfrage wartete. Die Lösung bestand nicht darin, mehr Verbindungen hinzuzufügen. Es war das Abbrechen dieser Abfrage, das Hinzufügen eines Index und die Implementierung von Abfrage-Timeouts auf Anwendungsebene. Dieser Vorfall brachte mir drei Dinge bei: Die Erschöpfung des Verbindungspools ist ein Symptom, keine Krankheit. Wenn du es siehst, skalier den Pool nicht sofort nach oben. Frage, warum Verbindungen nicht freigegeben werden. Sind Abfragen langsam? Gibt es Deadlocks? Hält etwas Transaktionen offen? Der Verbindungspool zeigt dir an, dass es woanders ein Problem gibt. Abfrage-Timeouts sollten überall vorhanden sein. Jede Datenbankabfrage sollte ein Timeout haben. Jedes HTTP-Anfrage sollte ein Timeout haben. Jede Warteschlangenoperation sollte ein Timeout haben. Timeouts sind nicht optional. Sie sind der Unterschied zwischen einem degradierenden Dienst und einem völlig ausgefallenen Dienst. Wenn etwas schiefgeht, lassen dich Timeouts schnell scheitern, anstatt blockierte Verbindungen zu akkumulieren, bis das gesamte System zusammenbricht. Die Überwachung der Nutzung des Verbindungspools ist nicht genug. Du musst die Lebensdauer von Verbindungen überwachen. Wie lange wird die durchschnittliche Verbindung gehalten? Was ist das P99? Wenn die durchschnittliche Lebensdauer deiner Verbindung plötzlich von 50 ms auf 5 Sekunden springt, hast du ein Problem, selbst wenn dein Pool noch nicht erschöpft ist. Das ist dein Frühwarnsystem. Zurück zum Vorfall des Zahlungsdienstes um 2:17 Uhr. Ich habe die Lebensdauer der Verbindungen überprüft. Durchschnitt: 8 Sekunden. P99: