Incident-Prozess im Serverbetrieb: Von der Alarmierung bis zum Postmortem

Monitoring, zentrales Logging und Backups sind in vielen Unternehmen vorhanden. Was häufig fehlt, ist der Teil danach: Was passiert konkret, wenn um 23 Uhr eine Datenbank nicht mehr antwortet? Wer entscheidet, wer informiert, wer darf einen Dienst neu starten? Ohne festgelegten Ablauf entscheidet die Zufälligkeit, wer gerade erreichbar ist und wie gut diese Person die Umgebung kennt.

Ein Incident-Prozess ist kein Bürokratieprojekt. Er beantwortet vier Fragen im Voraus: Wie merken wir es, wer übernimmt, was tun wir zuerst, und was lernen wir daraus.

Was als Incident gilt

Nicht jede Auffälligkeit ist eine Störung. Ein voller Log-Partition-Alarm um 10 Uhr morgens ist ein Ticket, ein nicht erreichbarer Shop ist ein Incident. Die Unterscheidung ist deshalb wichtig, weil sie bestimmt, ob jemand aus dem Feierabend geholt wird.

Bewährt haben sich drei bis vier Schweregrade. Mehr Stufen führen dazu, dass im Ernstfall über die Einstufung diskutiert wird statt über die Lösung. Eine mögliche Einteilung:

• Sev1: Geschäftskritischer Dienst komplett nicht verfügbar oder Datenverlust droht. Sofortige Alarmierung, auch nachts.
• Sev2: Starke Beeinträchtigung, Teilausfall oder Workaround vorhanden. Bearbeitung innerhalb der Servicezeiten mit Priorität.
• Sev3: Einzelne Funktion gestört, kein unmittelbarer Geschäftsschaden. Regulärer Ticketlauf.

Entscheidend ist, dass die Einstufung an der Auswirkung hängt und nicht an der technischen Ursache. Eine ausgelastete CPU ist für sich genommen harmlos, wenn niemand sie bemerkt. Derselbe Wert ist Sev1, wenn deswegen keine Bestellung mehr durchläuft.

Alarmierung: vom Monitoring zum Menschen

Zwischen einem Monitoring-Check und einer handelnden Person liegen mehrere Schritte, die oft ungeplant sind. Eine Mail in ein Sammelpostfach ist keine Alarmierung. Für Sev1 braucht es einen Kanal, der jemanden aufweckt, und eine Eskalation, falls diese Person nicht reagiert.

Praktisch heißt das: ein definierter Bereitschaftsdienst mit Vertretung, eine zweite Eskalationsstufe nach einer festgelegten Zeitspanne, und eine dokumentierte Erreichbarkeit außerhalb der üblichen Systeme. Wenn der Mailserver betroffen ist, hilft eine Alarmierung per Mail nicht weiter.

Der häufigste Fehler ist nicht zu wenig, sondern zu viel Alarmierung. Ein Alarm, der regelmäßig ohne Handlungsbedarf auslöst, trainiert dem Team das Ignorieren an und ist gefährlicher als gar kein Alarm. Jeder Alarm sollte eine Handlung auslösen. Alles andere gehört in ein Dashboard oder in einen Tagesbericht.

Rollen während einer Störung

Bei kleineren Störungen übernimmt eine Person alles. Bei größeren Vorfällen entsteht schnell ein typisches Muster: drei Leute arbeiten parallel am selben System, niemand hält den Überblick, und die Geschäftsführung ruft im Minutentakt an.

Deshalb lohnt sich eine simple Rollentrennung, sobald mehr als zwei Personen beteiligt sind:

• Incident Lead: koordiniert, entscheidet, hält die Zeitleiste fest. Arbeitet idealerweise nicht selbst an der Technik.
• Technische Bearbeitung: analysiert und behebt, meldet Erkenntnisse an den Lead.
• Kommunikation: informiert interne Stakeholder und gegebenenfalls Kunden, damit die Technik nicht unterbrochen wird.

Die Rollen sind temporär und hierarchiefrei. Der Incident Lead ist nicht automatisch die ranghöchste Person, sondern diejenige mit dem besten Überblick über die betroffene Umgebung.

Die ersten dreißig Minuten

In der Anfangsphase gilt eine Reihenfolge, die in der Hektik gern verdreht wird: erst Auswirkung begrenzen, dann Dienst wiederherstellen, erst danach Ursache suchen. Die vollständige Ursachenanalyse während des laufenden Ausfalls ist meist der teuerste Weg.

Konkret bedeutet das, einen fehlerhaften Deploy zurückzurollen, statt den Bug im Produktivsystem zu suchen. Oder auf ein Standby-System umzuschalten, statt den Primärknoten zu reparieren. Wichtig ist dabei, Beweise zu sichern, bevor etwas überschrieben wird: Logs wegsichern, Metriken festhalten, einen Snapshot anlegen.

Ebenso wichtig ist die laufende Dokumentation. Ein einfacher Chatkanal pro Vorfall, in dem jede Aktion mit Uhrzeit notiert wird, reicht aus. Diese Zeitleiste ist später die Grundlage für das Postmortem und oft auch für Nachweise gegenüber Kunden oder Prüfern.

Runbooks statt Heldentum

Für wiederkehrende Fehlerbilder gehören vorbereitete Abläufe in die Dokumentation. Ein Runbook beschreibt für einen konkreten Fall, welche Checks in welcher Reihenfolge durchzuführen sind und welche Befehle zulässig sind. Typische Kandidaten sind voll gelaufene Dateisysteme, abgelaufene Zertifikate, Replikationsabbruch in der Datenbank, hängende Queues oder ein Failover-Schwenk.

Runbooks sind kein Ersatz für Fachwissen, aber sie senken die Fehlerquote unter Zeitdruck und machen die Bereitschaft unabhängiger von einzelnen Köpfen. Sie veralten schnell, wenn sie nicht benutzt werden, deshalb gehören sie in die reguläre Dokumentationspflege und sollten nach jedem Einsatz kurz überprüft werden.

Kommunikation während des Ausfalls

Technisch saubere Arbeit und schlechte Kommunikation führen trotzdem zu unzufriedenen Kunden. Umgekehrt akzeptieren die meisten Kunden einen Ausfall, wenn sie wissen, dass daran gearbeitet wird und wann die nächste Information kommt.

Drei Punkte reichen für eine brauchbare Statusmeldung: was betroffen ist, was gerade getan wird, wann die nächste Aktualisierung folgt. Spekulationen über die Ursache gehören nicht hinein, solange sie nicht belegt sind. Eine zurückgenommene Ursachenvermutung kostet mehr Vertrauen als eine zurückhaltende Formulierung.

Für Vorfälle mit möglichem Bezug zu personenbezogenen Daten gilt zusätzlich: Die Meldepflichten der DSGVO laufen unabhängig von der technischen Behebung. Diese Bewertung sollte früh und nicht erst nach der Entstörung angestoßen werden.

Postmortem ohne Schuldzuweisung

Nach einem Sev1 gehört eine Nachbetrachtung dazu, am besten innerhalb weniger Tage, solange die Details präsent sind. Das Ziel ist nicht die Frage, wer den falschen Befehl abgesetzt hat, sondern warum das System diesen Befehl ohne Rückfrage zugelassen hat.

Ein brauchbares Postmortem enthält die Zeitleiste, die Auswirkung in Worten statt in Bauchgefühl, die auslösenden und die begünstigenden Faktoren sowie konkrete Maßnahmen mit Verantwortlichen und Terminen. Maßnahmen ohne Namen und Datum werden nicht umgesetzt.

Eine wiederkehrende Erkenntnis aus solchen Runden ist, dass die eigentliche Ursache selten der auslösende Fehler war, sondern eine fehlende Überwachung, ein nicht getesteter Wiederherstellungspfad oder eine Dokumentationslücke. Genau dort entsteht der Mehrwert des Prozesses.

Der pragmatische Einstieg

Wer bei null beginnt, braucht kein Werkzeug, sondern drei Dokumente: eine Severity-Definition, eine Alarmierungs- und Eskalationskette mit Namen und Nummern, eine Postmortem-Vorlage. Danach folgen Runbooks für die drei wahrscheinlichsten Ausfallszenarien.

Der Rest ergibt sich aus der Praxis. Jeder Vorfall, der sauber dokumentiert und nachbereitet wird, verbessert den Prozess stärker als jedes Konzeptpapier. Und wer den Betrieb an einen Dienstleister ausgelagert hat, sollte genau diese Punkte vertraglich klären: Wer alarmiert wen, in welchem Zeitraum, mit welcher Eskalation und mit welcher Nachbereitung.