Die Architektur-Folie war makellos. Lahmgelegt hat die Plattform am Ende ein hängendes Storage-Mount.
Resilienz entscheidet sich selten an der grossen Architektur. Sie entscheidet sich an den langweiligen Failure-Modes, die in keinem Slide vorkommen.
Vor einiger Zeit fiel eine produktive Anwendung aus. Verdächtig war zuerst alles Mögliche — die Applikation, die Datenbank, das Netz. Die Ursache lag tiefer: ein Mount, das nicht mehr antwortete, dazu verwaiste Locks in der Datenbank. Threads liefen voll, alles staute sich zurück.
Die Lektion ist nicht „Technologie X ist böse". Sie ist: Abhängigkeiten, die man als „immer verfügbar" annimmt, sind die gefährlichsten. Eine blockierende Ressource ohne Timeout reisst alles mit, was auf sie wartet.
Was bleibt: aggressive Timeouts statt unendlichem Warten, Health-Checks, die echte Abhängigkeiten prüfen statt nur „Prozess lebt", und ein Runbook, das die unspektakulären Ursachen zuerst abklopft.
Gute Post-Mortems sind unbequem, weil die Wahrheit selten elegant ist. Aber sie sind das ehrlichste Lerndokument, das ein Team hat. (Details bewusst anonymisiert.)
Was war euer „langweiligster", teuerster Incident?