Nachtvorfall: Monolith-Stabilisierung in Prod

Nachtschicht-Ausfall: Monolith stabilisieren und Team koordinieren

Der Pager-Alarm „PROD: alles rot“ hat mich aus dem Bett gerissen. Hastig ins Incident-Room: SRE-Playbook – stabilisieren, analysieren, Post-Mortem. Team teilt Rollen auf: Koordination, Kommunikation, Datenbank, Überwachung von Metriken und Logs. Ziel: Ursache aus dem Erbe-Code-Gestrüpp buddeln.

Stakeholder kriegen ersten Update: „Service ausgefallen. Team dran. Nächstes Update in 15 Minuten.“ Monitoring zeigt alles rot außer einem grünen Blip. Logs überschwemmt mit Timeout-Fehlern am Monolithen, liebevoll „der Drache“ genannt.

Diagnose: Von Message Queues zu Datenbank-Engpässen

Message-Queue-Metriken schießen exponentiell hoch, Consumer krachen mit Timeouts ab. Schuldige: träge Datenbankabfragen. Hier ein Paradebeispiel:

SELECT * FROM users WHERE some_condition ORDER BY created_at LIMIT 1000;
-- Kein Index auf some_condition oder created_at, scannt 10M+ Zeilen – Katastrophe.

DBA entdeckt fehlende Indizes und N+1-Probleme im neuen Service. Legacy-Architekt bestätigt: Monolith hortet globalen Zustand, nicht für Skalierung gebaut ohne Refactoring.

Dringender Kubernetes-Migrationsvorschlag? Abgelehnt. Würde Komplexität in der Krise aufhäufen, ohne das echte Problem zu lösen.

Security-Gatekeeping und harte Kompromisse

Anfrage nach temporärem Zugriff für Traffic-Throttling und Feature-Rollback? Security blockt ab. Threat-Model verlangt Risiko-Freigabe. Kompromiss: Ein-Stunden-Zugriff mit vollem Logging und Audit-Report.

Maßnahmen:

• Traffic mit Rate Limiting drosseln.
• Neues Feature via Feature Flag zurückrollen.
• Erholung überwachen: rot → pink → grau → stabiles grün.

Stakeholder-Update: „Stabilisiert. Analyse läuft. Nächstes Update in 30 Minuten.“

Ursache und zentrale Learnings

Incident eingedämmt: Queues verstopft, DB von unoptimierten Abfragen des neuen Services malträtiert. Monolith an der Leine und stabil, aber er brüllt nach systematischer Überholung.

OKR-Manager mischt mit: Doppel-Releases, „alles umschreiben“, Kubernetes überall. Risiko: Big-Bang-Projekte jagen statt inkrementeller Erfolge.

Zentrale Learnings:

• Ursache waren schlampige Abfragen und Queues, nicht der Monolith selbst.
• Klare Incident-Rollen sind entscheidend: Koordination, Kommunikation, tiefe Expertise.
• Security kann flexibel sein mit zeitlich begrenztem Zugriff und Audits.
• In der Krise keine hastigen Migrationen; Stabilisierung priorisieren.
• Post-Mortem formt Roadmap: Indizes, Feature Flags, schrittweises Refactoring.

Team stabilisiert in 2 Stunden. Nächstes: Post-Mortem und Aktionsplan.

— Editorial Team