Produktion brennt in der Entwicklung — was es ist, Ursachen und Aktionsplan

Was „Produktion brennt“ bedeutet und Arten von Ausfällen

Der Ausdruck „Produktion brennt“ (alles ist down) beschreibt eine Situation, in der die Produktionsumgebung nicht korrekt funktioniert und Benutzer betroffen sind. Der Ausfall kann sich als vollständige Nichtverfügbarkeit der Anwendung (leerer Bildschirm, 502-Fehler), teilweise Nichtverfügbarkeit (das Zahlungsmodul funktioniert nicht, aber andere Funktionen sind verfügbar) oder Leistungsverschlechterung (äußerst langsames Laden) äußern. Der Schweregrad des Vorfalls wird durch den Prozentsatz der betroffenen Benutzer und die Dauer des Ausfalls bestimmt.

Laut Atlassian Statuspage (2025) betrug die durchschnittliche Ausfallzeit für mobile Anwendungen im Jahr 2024 27 Minuten pro Vorfall. Die häufigsten Ursachen: Code-Regression nach Bereitstellung (34%), Ausfall des Cloud-Anbieters (22%), Datenbankprobleme (18%), Konfigurationsfehler (15%) und DDoS-Angriffe (11%). Wichtigste Erkenntnis: Die meisten Ausfälle werden durch Änderungen verursacht, die das Team selbst vorgenommen hat, nicht durch externe Faktoren.

Es ist wichtig, zwischen einem Crash (Anwendungsabsturz auf der Client-Seite) und einem Backend-Ausfall (Server nicht verfügbar) zu unterscheiden. Ein Crash wird normalerweise durch einen Hotfix des Client-Codes behoben, während ein Backend-Ausfall Infrastrukturänderungen oder eine erneute Bereitstellung des Dienstes erfordert. Überwachungsmetriken: für den Client — Crash-freie Rate, für den Server — 5xx-Fehlerrate und p95-Latenz. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — hilft, die Art des Ausfalls schnell zu bestimmen.

Schweregrad von Vorfällen: P0, P1, P2 und Klassifizierungskriterien

Eine einheitliche Klassifizierung des Schweregrads ist die Grundlage für eine schnelle Reaktion. Ohne sie verschwendet das Team Zeit mit der Diskussion „wie dringend das ist“, anstatt zu handeln. Die klassische Skala: P0 (kritisch) — die Anwendung ist vollständig nicht verfügbar oder Benutzerdaten werden preisgegeben, Reaktionszeit — sofort; P1 (hoch) — kritische Funktionalität ist für 50%+ der Benutzer gestört, Reaktionszeit — 15 Minuten; P2 (mittel) — nicht kritische Funktionalität ist für einige Benutzer nicht verfügbar, Reaktionszeit — 1 Stunde.

P0 erfordert sofortige Eskalation: der Bereitschaftsingenieur unterbricht jegliche laufende Arbeit und konzentriert sich auf den Vorfall. Wenn das Problem nicht innerhalb von 10 Minuten gelöst ist — wird der Tech Lead hinzugezogen. Wenn nach 30 Minuten — Eskalation an den Engineering Manager. Für P0-Vorfälle ist es zulässig, alle Prozesse zu brechen: einen Hotfix ohne vollständige Code-Überprüfung durchführen, direkt in der Produktion bereitstellen, Branch-Protection-Regeln ignorieren. Notfall-Override muss auf Teamebene vorher vereinbart sein.

Schweregrad-Tabelle

Es ist äußerst wichtig, den Schweregrad nicht nach unten zu verfehlen. Als P2 klassifizierte P0- und P1-Vorfälle führen zu verzögerter Reaktion und erhöhter Ausfallzeit. Regel: Im Zweifelsfall P0 setzen. Überklassifizierung ist besser als Unterklassifizierung: Es ist besser, ein zusätzliches Meeting abzuhalten, als eine Stunde Wiederherstellungszeit zu verlieren.

Erste 10 Minuten: Aktionsalgorithmus bei einem Ausfall

Der Timer startet: ab dem Moment, in dem ein Alarm oder eine Benutzernachricht eingeht. Die ersten 10 Minuten sind die wichtigsten. Algorithmus: 1) Problem bestätigen — sicherstellen, dass das Problem real ist (kein Fehlalarm); 2) Blutung stoppen — die Auswirkung sofort reduzieren (Rollback, Feature Toggle, Endpunkt-Sperrung); 3) Kommunizieren — im allgemeinen #incident-Kanal den Status posten: was passiert ist, Schweregrad, was getan wird. Die ersten 10 Minuten werden nicht für die Ursachenanalyse aufgewendet.

Parallel zum Stoppen der Blutung beginnt ein Ingenieur mit der Diagnose, während ein anderer die Kommunikation übernimmt. Kommunikationskanäle: Slack #incident-Kanal (für das Team), Statusseite (für Benutzer), E-Mail/SMS-Eskalation (für das Management). Alle 15 Minuten — ein Status-Update mit Informationen: was bekannt ist, was getan wird, voraussichtliche Wiederherstellungszeit. Statusseite (StatusPage, Statuspal) zeigt Betriebszeit und Vorfallsgeschichte für externe Benutzer an.

Wie man die Blutung stoppt: Rollback, Feature Toggle und Hotfix

Die erste und wichtigste Regel: Versuchen Sie nicht, das Problem in der Produktion zu beheben. Wenn ein neues Release den Ausfall verursacht hat — rollen Sie auf die vorherige stabile Version zurück. Wenn der Ausfall durch eine bestimmte Funktion verursacht wird, die hinter einem Feature Toggle steckt — schalten Sie den Toggle einfach aus. Wenn weder Rollback noch Toggle verfügbar sind — wenden Sie einen Hotfix mit minimalem Diff an. Rollback ist die sicherste Option, da es zu einem Zustand zurückkehrt, der bereits funktioniert hat.

Feature Toggle (auch Feature Flag genannt) ist ein leistungsstarkes Werkzeug zum Stoppen der Blutung ohne Bereitstellung. Wenn das Zahlungsmodul ausfällt, aber über einen Toggle deaktiviert ist — sehen die Benutzer einfach keinen Zahlungsbutton, anstatt eine Fehlerseite zu erhalten. Ein Toggle erfordert keinen Build, keine Store-Überprüfung und wird in Sekunden wirksam. Jede kritische Funktion sollte hinter einem Feature Toggle mit der Möglichkeit zur Deaktivierung auf Serverebene (Remote-Konfiguration) stehen. Feature Flag — die erste Verteidigungslinie.

Wenn ein Rollback unmöglich ist (z. B. aufgrund einer irreversiblen Datenbankmigration) und kein Toggle vorhanden ist — bleibt als letztes Mittel ein Hotfix mit minimalen Änderungen. Der Hotfix wird vom letzten Release-Tag erstellt, enthält nur die zur Behebung des Ausfalls erforderlichen Zeilen und durchläuft eine schnelle Bereitstellung (siehe Artikel „Hotfix — dringende Korrekturen“). Goldene Regel: Führen Sie nach der Stabilisierung immer eine Ursachenanalyse durch, auch wenn die Ursache offensichtlich erscheint.

Ursachendiagnose: Logs, Metriken und Alarme

Nach dem Stoppen der Blutung (oder parallel, wenn die Anzahl der Ingenieure es erlaubt) beginnt die Diagnose. Die erste Quelle sind Logs. Zentralisiertes Logging (ELK, Grafana Loki, Datadog Logs) ermöglicht das Auffinden von Fehlern nach Zeitstempel, Benutzer-ID oder Anfrage-ID. Wichtig: Logs müssen strukturiert sein (JSON), damit grep schnell funktioniert. Strukturiertes Logging ist eine zwingende Anforderung für alle Dienste.

Die zweite Quelle sind Metriken. Grafana, Datadog, New Relic zeigen, wann der Fehleranstieg auftrat, an welchen Endpunkten und mit welchen Statuscodes. Der Vergleich von Metriken vor und nach der Bereitstellung hilft, das Problem auf einen bestimmten Dienst oder Endpunkt einzugrenzen. RED-Metriken (Rate, Errors, Duration) — der Standard für die Überwachung von Microservices.

Die dritte Quelle ist die verteilte Ablaufverfolgung (Distributed Tracing). Jaeger, Zipkin, Datadog APM zeigen den Pfad der Anfrage durch die Microservices und identifizieren, wo genau die Verzögerung oder der Fehler aufgetreten ist. Die Ablaufverfolgung ist besonders nützlich bei kaskadierenden Ausfällen, wenn ein Ausfall in einem Dienst Fehler in allen abhängigen Diensten verursacht. Trace-ID muss vom Client an alle Backend-Dienste übergeben werden.

# Schnelles Diagnosebeispiel mit kubectl und Logs
# Pods mit Fehlern auflisten
kubectl get pods --field-selector=status.phase!=Running

# Logs des abgestürzten Pods prüfen
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Fehler im Dienst der letzten 30 Minuten suchen
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Wichtig: Versuchen Sie nicht, die Ursache vor dem Stoppen der Blutung zu diagnostizieren. Wenn 50% der Benutzer einen Crash sehen — rollen Sie zuerst zurück, dann untersuchen Sie. Ausnahme: wenn ein Rollback länger dauern würde als ein direkter Hotfix (z. B. aufgrund von Dateninkompatibilität). In diesem Fall wenden Sie den Hotfix sofort an und führen Sie die Post-Mortem-Analyse nach der Stabilisierung durch. Diagnose vor der Behebung ist ein gefährliches Muster, das die Ausfallzeit verlängert.

Post-Mortem: Wie man Vorfälle ohne Schuldzuweisungen analysiert

Post-Mortem (auch Vorfallsüberprüfung genannt) ist eine strukturierte Vorfallsanalyse, die 24–72 Stunden nach der Behebung durchgeführt wird. Ihr Zweck: zu verstehen, warum der Ausfall aufgetreten ist, warum die Überwachung und Tests ihn nicht vor der Produktion erkannt haben, und was in den Prozessen geändert werden muss, um eine Wiederholung zu verhindern. Schuldfreie Kultur ist ein grundlegendes Prinzip: Die Post-Mortem-Analyse diskutiert Prozesse, Werkzeuge und Kommunikation, nicht die Fehler bestimmter Personen.

Aufbau des Post-Mortem-Dokuments: Zeitplan (Ereignisablauf mit Zeitstempeln), Auswirkung (betroffene Benutzer, Dauer, finanzielle Verluste), Ursache (technische Hauptursache), Erkennung (wie wurde es entdeckt, warum wurde es nicht früher erkannt), Reaktion (was wurde getan, was hätte schneller getan werden können), Maßnahmen (konkrete Aufgaben mit Verantwortlichen und Fristen). Maßnahmen müssen S.M.A.R.T. sein: spezifisch, messbar, zuweisbar, realistisch, terminiert.

Typische Maßnahmen nach einem Produktionsausfall: Überwachung und Alarmierung für die Metrik hinzufügen, die still war; die Testabdeckung für den übersehenen Fall erweitern; eine Seite mit Schritt-für-Schritt-Algorithmus für eine ähnliche Situation zum Runbook hinzufügen; ein Teamtraining für das Werkzeug durchführen, das falsch verwendet wurde. Jede Maßnahme ist eine konkrete Änderung, die die Wahrscheinlichkeit einer Wiederholung des Vorfalls verringert.