Wenn der Docker-Container kollabiert: Ein interner Fail mit Lerneffekt

Es gehört zur ungeschriebenen Ironie der Tech-Branche, dass ausgerechnet diejenigen, die täglich über die IT-Infrastrukturen globaler Konzerne urteilen, vor den eigenen Server-Racks nicht gefeit sind.

Gestern Nachmittag hat es uns bei VZC System selbst erwischt. Unsere internen Entwicklungs- und Produktivsysteme verabschiedeten sich um exakt 14:22 Uhr in eine kollektive, 45-minütige Kaffeepause. 

Der Grund war kein ausgeklügelter Cyberangriff und kein Hardware-Defekt, sondern die klassische menschliche Selbstüberschätzung im Umgang mit automatisierten Deployment-Skripten.

Die Schleife des Grauens

Der Vorfall lässt sich auf eine vermeintlich banale Optimierung unseres internen Cache-Managements zurückführen. Im Zuge der Vorbereitungen für kommende Plattform-Features sollte ein modifiziertes Bash-Skript veraltete temporäre Dateien im Redis-Cache isolieren und automatisiert bereinigen.

Durch eine fehlerhaft gesetzte Variable innerhalb einer while-Schleife ignorierte das Skript jedoch die definierten Pfadgrenzen. Anstatt nur die temporären Cache-Inhalte zu löschen, begann die Routine in einer Endlosschleife, die System-Ressourcen des Host-Systems zu fluten.

Innerhalb von weniger als drei Minuten stieg die CPU-Auslastung auf allen Kernen auf Anschlag, was die RAM-Belegung des Docker-Daemons an das absolute Limit trieb.

Die Folge: Ein klassischer Out-of-Memory (OOM) Killer-Einsatz des Linux-Kernels, der nacheinander die wichtigsten Container-Dienste rigoros abschoss.

Das Schweigen im Backend

Für uns als Redaktion bedeutete das konkret: Kein Zugriff auf das Content-Management-System, stillstehende interne APIs und eine Entwicklungsdatenbank, die auf keine Anfragen mehr reagierte. Das Problem bei modernen, containerisierten Umgebungen ist in solchen Momenten oft die Kaskade.

Wenn der zentrale Reverse-Proxy den Kontakt zur Datenbank verliert und gleichzeitig die Ressourcen erschöpft sind, schlagen auch die automatisierten Recovery-Mechanismen fehl.

Besonders bitter war die Tatsache, dass das Überwachungstool brav Alarm schlug – die Benachrichtigungen jedoch auf demselben Server verarbeitet werden sollten. Es war das digitale Äquivalent zu einem Feuermelder, der versucht, eine E-Mail zu schreiben, während die Telefonleitung brennt. 

Erst der manuelle Blick auf die Server-Konsole über das externe Management-Interface brachte die Gewissheit, dass sich das System im Zustand der totalen Starre befand.

Was wir daraus mitnehmen

Nach einem harten Power-Cycle über die Server-Infrastruktur und dem anschließenden manuellen Bereinigen der fehlerhaften Skript-Fragmente liefen alle Systeme um kurz nach 15:00 Uhr wieder stabil. 

Datenverluste gab es glücklicherweise keine, da unsere produktiven Backups streng isoliert auf externen Systemen liegen und von solchen lokalen Schleifen unberührt bleiben.

Der gestrige Nachmittag zeigt vor allem eines: Automatisierung ist ein mächtiges Werkzeug, verzeiht aber keine Schlamperei im Code.

Für die Zukunft haben wir die Skript-Validierung verschärft und die Ressourcen-Limits für einzelne Docker-Container restriktiver gestaltet. Ein interner Server-Ausfall ist stressig, aber er zwingt uns auch dazu, die eigenen Prozesse kritisch zu hinterfragen und die Infrastruktur noch robuster aufzustellen.

Fazit des Tages: Wer den Schaden hat, braucht für den Spott nicht zu sorgen. Der Vorfall ist gelöst, die Fehlerquellen sind analysiert und isoliert – und unser Entwickler-Team trinkt den Kaffee heute mit einer Extraportion Demut.