Die unbequeme Diagnose

Irgendwann stellt man sich die ehrliche Frage: Läuft die eigene Infrastruktur eigentlich zuverlässig? Bei mir lautete die Antwort nach ein paar Wochen Beobachtung: nein. Im Schnitt gab es fast zwei nennenswerte Störungen pro Woche — mal ein Dienst, der nach einem Neustart nicht sauber hochkam, mal ein abgelaufenes Zertifikat, mal ein Dienst, dessen Speicher voll lief.

Noch aufschlussreicher als die Häufigkeit war ein Muster in den Aufzeichnungen: In der Spalte „Wie wurde es entdeckt?" stand fast nie „Alarm". Es stand da „durch Zufall bemerkt" oder „vom Nutzer gemeldet". Das ist die eigentliche Diagnose — und sie hat einen Namen:

Die Dokumentations- und Reaktionsdisziplin war also stark. Was fehlte, war die Vorbeugung: Ausfälle früh (idealerweise vor dem Schaden) erkennen — und die häufigsten Ursachen an der Wurzel abstellen, statt sie immer wieder von Hand zu reparieren.

Ein Monitoring kann seinen eigenen Ausfall nicht melden

Der Moment, der alles auf den Punkt brachte, kam beim Testen einer neuen Warnregel. Beim Nachverfolgen der Alarmkette stellte sich heraus: Die Kette war seit einem Neustart am selben Morgen komplett tot. Rund neun Stunden lang hätte kein einziger Alarm den Weg nach draußen gefunden. Das System, das mich vor Problemen warnen sollte, war selbst das ungemeldete Problem.

Die Ursache war banal und lehrreich zugleich: Nach dem Neustart war eine Komponente der Überwachung zwar „gesund" gestartet, aber von ihrem Netzwerk getrennt — für den Rest der Kette schlicht unerreichbar. Von außen sah alles grün aus (der Container lief!), tatsächlich lief nichts zusammen.

Daraus folgt die Leitidee für alles Weitere: Es braucht mehrere unabhängige Schichten, von denen mindestens eine außerhalb der überwachten Infrastruktur sitzt. Kein einzelner Mechanismus darf der alleinige Wissende sein.

Schicht 1: Ein Wächter außerhalb der Kette

Die erste neue Schicht ist ein kleiner Invarianten-Wächter: ein Skript, das alle paar Minuten die harten Grundwahrheiten prüft, die immer gelten müssen. Beispiele: Steht die Firewall-Grundregel an ihrer vorgeschriebenen Position — und genau einmal? Zeigt die Weiterleitung für den Web-Verkehr auf das richtige interne Netz? Ist die Alarm-Komponente von der Metrik-Komponente überhaupt erreichbar? Sind alle Messfühler online?

Der entscheidende Trick liegt nicht in den Checks selbst, sondern in ihrer Unabhängigkeit: Dieser Wächter benutzt für seinen Alarm bewusst nicht denselben Weg, den er überwacht. Er hängt nicht am zentralen Metrik-/Alarm-System und nicht am Web-Proxy. Wenn also genau diese Teile ausfallen, ist er der Einzige, der noch reden kann.

Schicht 2: Der Totmannschalter

Der Wächter aus Schicht 1 läuft immer noch auf demselben Server. Was, wenn der ganze Server steht — Strom weg, Netz weg, Kernel eingefroren? Dann schweigt auch er. Für diesen Fall gibt es die klassische Lösung aus der Bahntechnik: den Totmannschalter (englisch „dead man's switch").

Das Prinzip ist umgekehrt zu einem normalen Alarm: Nicht das Auftreten eines Fehlers löst aus, sondern das Ausbleiben eines Lebenszeichens. Der Server sendet in kurzen Abständen ein „Ich lebe" an einen externen Dienst. Bleibt dieses Signal aus, schlägt der externe Dienst Alarm — über einen Kanal, der mit der eigenen Infrastruktur nichts zu tun hat.

Damit ist die peinlichste Lücke geschlossen: „Alles tot, inklusive der Alarmierung" wird jetzt von außen bemerkt — spätestens nach der eingestellten Karenzzeit.

Schicht 3: Der Blick von außen

Es gibt noch einen tückischen Fall dazwischen: Der Server läuft, aber von außen ist nichts mehr über HTTPS erreichbar — etwa weil die Weiterleitung des Web-Verkehrs nach einem Update auf das falsche Netz zeigt. Das Gemeine daran: Ein Test vom Server selbst auf die eigene öffentliche Adresse kann trügerisch grün sein, weil er intern eine Abkürzung nimmt und gar nicht denselben Weg geht wie ein echter Besucher.

Die einzige verlässliche Antwort ist ein Blick von außen: ein kleiner Prüfer, der von einem anderen Standort aus regelmäßig die öffentlichen Adressen aufruft — so, wie es ein Besucher täte. Antwortet der Rand nicht mehr, weiß man sofort Bescheid, obwohl der Server selbst putzmunter ist. Ob man dafür einen gehosteten Uptime-Dienst nimmt oder einen eigenen Mini-Prüfer auf einem Rechner an einem zweiten Standort laufen lässt, ist Geschmackssache — Hauptsache, der Blick kommt wirklich von draußen.

Alarmieren, bevor es kracht

Ein Teil der Störungen war gar kein plötzlicher Defekt, sondern langsames Volllaufen: Der Speicher eines datenintensiven Dienstes wuchs mit der Zeit über eine kritische Schwelle, ab der er jede Anfrage abwies. Bemerkt wurde das — natürlich — erst, als nichts mehr ging.

Die Lehre: Kapazitäts-Alarme müssen Vorlauf geben. Nicht „die Platte ist voll", sondern „die Platte ist zu 80 % voll" und, noch besser, „bei diesem Trend ist sie in vier Tagen voll". Nicht „der Speicher ist erschöpft", sondern „der Speicher nähert sich der Grenze, ab der es kritisch wird". Wachstum soll auffallen, bevor es zum Ausfall wird.

Die häufigste Ausfallklasse: der Neustart

Als ich die Störungen nach Ursachen sortierte, sprang eine Klasse heraus: der Neustart. Ein Reboot löste immer wieder gleich mehrere Probleme gleichzeitig aus. Der Grund ist ein klassisches Start-Rennen: Dienste starten in einer Reihenfolge, in der ihre Abhängigkeiten noch nicht bereit sind. Ein Dienst, der eine bestimmte Netzwerkadresse braucht, startet, bevor diese existiert — und scheitert. Der übliche „starte einfach neu"-Automatismus hilft hier nicht, weil der Fehler bei jedem Versuch sofort wieder auftritt.

Zwei Gegenmittel haben sich bewährt. Erstens: Selbstheilung beim Boot. Ein kleiner Start-Helfer wartet, bis die Abhängigkeiten wirklich da sind, fährt die betroffenen Dienste dann geordnet hoch und prüft anschließend, ob sie auch tatsächlich verbunden sind — und stellt die Verbindung nötigenfalls her.

Zweitens, und wichtiger: die Ursache abstellen. Ein wiederkehrender Crash nach jedem Reboot ließ sich auf gespeicherte Firewall-Regeln zurückführen, die beim Booten wiederhergestellt wurden — und sich dann mit den Regeln bissen, die eine andere Komponente ohnehin frisch anlegt. Zwei Köche, eine Regel doppelt, Dauerschleife. Die dauerhafte Lösung war nicht, die Schleife hinterher aufzuräumen, sondern die doppelte Quelle zu entfernen, sodass beim Boot gar kein Konflikt mehr entsteht.

Testen, bevor es produktiv geht

Der vielleicht wichtigste Kulturwandel war eine simple Regel: nicht mehr „ändern und schauen, was passiert". Jede Änderung an kritischen Grundpfeilern wird vorher gegen klare Abnahmekriterien getestet und nachher live verifiziert. Klingt selbstverständlich — ist es in der Praxis aber selten.

Wie wertvoll das ist, zeigte ausgerechnet der Test der Neustart-Selbstheilung. Um sie wirklich zu beweisen, habe ich einen kontrollierten Neustart durchgeführt (statt auf den nächsten unbeaufsichtigten zu warten) und direkt danach alles geprüft. Das Ergebnis war gemischt — und genau deshalb Gold wert: Die Selbstheilung reparierte einen Teil korrekt, aber nicht alles. In der frisch geschriebenen Reparatur steckte ein feiner Fehler: Eine Namensprüfung verwechselte zwei ähnlich benannte Komponenten und übersprang deshalb eine davon.

Dazu gehört ein zweiter Baustein: jeder Vorfall wird erfasst — Symptom, Ursache (nicht nur Symptom!), wie er entdeckt wurde, und welche Konsequenz gezogen wird. Taucht dieselbe Ursachenklasse erneut auf, war die vorige Konsequenz zu schwach. So wird aus einer Sammlung von Einzelärgernissen ein Lernsystem.

Was man mitnimmt

Aus einer Umgebung, die „keine Woche ohne Störung" durchhielt, ist eine geworden, die sich nach einem Neustart selbst heilt und die eigenen blinden Flecken laut meldet. Die übertragbaren Lektionen:

• Ein Monitoring kann seinen eigenen Ausfall nicht melden. Es braucht mindestens eine Schicht außerhalb — ein Totmannschalter über einen fremden Kanal ist die einfachste.
• Unabhängigkeit der Alarmwege. Der wichtigste Alarm darf nicht über genau die Komponente laufen, die gerade ausgefallen sein könnte.
• Erkennung ist eine Qualitätskennzahl. Ziel: „entdeckt durch Alarm", nicht „durch Zufall". Jeder zufällig entdeckte Ausfall erzeugt eine Aufgabe für den fehlenden Alarm.
• Fail-closed statt fail-open. Wenn ein Wächter ausfällt, ist „Tür zu" (Verfügbarkeitsproblem) tausendmal besser als „Tür offen" (Sicherheitsproblem).
• Vorbeugen schlägt Aufräumen, und Testen schlägt Hoffen. Ursachen abstellen statt Symptome; vor der Produktivnahme prüfen statt danach staunen.

Nichts davon ist exotisch oder teuer. Es sind ein paar kleine Skripte, ein kostenloser externer Dienst und vor allem eine Haltung: Qualität, Stabilität und Sicherheit stehen über Tempo. Wer selbst hostet, kennt den Reiz des schnellen Bastelns. Der eigentliche Fortschritt beginnt an dem Tag, an dem die Infrastruktur langweilig wird — weil sie einfach läuft.