Überwachung meldet, dass etwas kaputt ist. Sie sagt nicht, wer jetzt handelt, in welcher Reihenfolge, mit welchen Rechten und wann eskaliert wird. Genau diese Lücke kostet in einer Störung die meiste Zeit: nicht die Reparatur selbst, sondern die Minuten davor, in denen unklar ist, wer zuständig ist und wo die Zugangsdaten liegen.
Die erste Frage ist nicht die Ursache
Der häufigste Fehler bei einer Störung ist, sofort mit der Ursachensuche zu beginnen. Ursachenanalyse ist unbegrenzt lang, Wiederherstellung ist es nicht. Die erste Frage lautet deshalb: Gibt es einen Weg, den Zustand von vorhin wiederherzustellen, ohne zu verstehen, was passiert ist? Ein Rücksprung auf die vorherige Version, das Abschalten einer neuen Funktion, das Umleiten auf ein Ausweichsystem.
Erst wenn der Betrieb wieder läuft, beginnt die Analyse. Das ist keine Bequemlichkeit, sondern Risikomanagement: Wer unter Zeitdruck in einem laufenden Ausfall Hypothesen testet, produziert regelmäßig einen zweiten Ausfall. Die Trennung von Wiederherstellung und Ursachenklärung ist die wichtigste Regel im ganzen Ablauf.
Rollen, damit niemand alles gleichzeitig macht
Sobald mehr als zwei Personen beteiligt sind, braucht eine Störung eine Aufgabenteilung. Sie muss nicht formell sein, aber sie muss ausgesprochen werden. Bewährt haben sich drei Rollen, die auch eine einzelne Person nacheinander einnehmen kann, solange sie weiß, in welcher sie gerade ist.
- Leitung: entscheidet, koordiniert, hält den Überblick und fasst den Stand fest. Fasst selbst nichts an.
- Technik: führt Eingriffe aus und meldet jeden Eingriff zurück, bevor er gemacht wird.
- Kommunikation: informiert Betroffene, Kunden und Kollegen in festen Abständen, auch wenn es nichts Neues gibt.
Der Punkt hinter der dritten Rolle wird oft unterschätzt. Ein Kunde erträgt eine Störung deutlich besser als das Gefühl, nicht informiert zu werden. Eine kurze Meldung alle 30 Minuten, auch mit dem Inhalt "wir arbeiten daran, nächster Stand um X", verhindert den größten Teil der Nachfragen, die sonst die Technik blockieren.
Runbooks: Wissen, das nicht im Kopf hängt
Ein Runbook ist die schriftliche Antwort auf einen bekannten Alarm. Es enthält keine Erklärungen, sondern Handgriffe: Wo liegt der Dienst, wie prüfe ich seinen Zustand, wie starte ich ihn neu, woran erkenne ich, dass es funktioniert hat, wann eskaliere ich. Jeder Alarm, der ohne Runbook auslöst, ist entweder unnötig oder unfertig.
Die Prüfgröße für Qualität ist einfach: Kann jemand, der das System nicht gebaut hat, damit nachts allein handeln? Wenn nicht, fehlen Pfade, Namen oder Voraussetzungen. Runbooks veralten schneller als Code, deshalb gehört zu jedem Eintrag ein Datum und der Hinweis, wann er zuletzt tatsächlich benutzt wurde.
Ein Automatismus, der einen Ausfall selbst behebt, ist nur dann sinnvoll, wenn die Ursache bekannt und harmlos ist. Ein Dienst, der abgestürzt ist und sich neu starten lässt, darf neu gestartet werden. Ein Dienst, der aus unklarem Grund abstürzt, darf nicht in einer Schleife neu gestartet werden: Der Automat verdeckt dann den Fehler so lange, bis er in einer schlechteren Situation groß herauskommt.
Eskalation als Zeitregel, nicht als Bauchgefühl
Eskalation scheitert fast immer daran, dass niemand sie auslösen will. Die Lösung ist, sie an die Uhr zu binden statt an eine Einschätzung. Beispiel für eine Staffel: nach 15 Minuten ohne Fortschritt zweite Person hinzuziehen, nach 45 Minuten Verantwortliche informieren, nach 90 Minuten externe Unterstützung oder Ausweichlösung. Die Zahlen sind Verhandlungssache, die Existenz der Regel nicht.
Zur Eskalation gehört ein aktueller Ruf- und Bereitschaftsplan mit erreichbaren Kontakten und einer zweiten Ebene. Ein Plan, in dem eine einzelne Person die einzige Antwort auf drei verschiedene Systeme ist, ist kein Plan, sondern ein dokumentiertes Risiko.
Der Nachgang entscheidet, ob es sich wiederholt
Nach der Wiederherstellung folgt die Aufarbeitung, und zwar zeitnah, solange die Erinnerung frisch ist. Sie beantwortet vier Fragen: Was ist passiert, wann wurde es bemerkt, was hat die Behebung verzögert, was ändern wir konkret. Die dritte Frage ist die wertvollste, weil sie meist auf fehlende Zugänge, unklare Zuständigkeiten oder ein fehlendes Runbook zeigt und nicht auf den technischen Defekt.
Entscheidend ist der Ton: Es geht um das System, nicht um Personen. Sobald Schuld verteilt wird, hören Menschen auf, Fehler früh zu melden, und die Zeit bis zur Entdeckung steigt bei jedem weiteren Vorfall. Jede Maßnahme aus der Aufarbeitung bekommt einen Verantwortlichen und ein Datum, sonst ist sie eine Absichtserklärung.
Diese Kette hängt vollständig davon ab, dass eine Störung überhaupt auffällt, bevor ein Kunde anruft. Welche Signale dafür taugen und warum zu viele Alarme genauso schädlich sind wie zu wenige, steht in Monitoring und Alerting: Fehler sehen, bevor der Kunde sie meldet. Erkennung und Reaktion sind zwei Hälften derselben Sache: Die eine ohne die andere erzeugt nur Lärm oder nur Stille.