Bereitschaft braucht klare Entscheidungen vor dem Alarm

Ein Alarm um drei Uhr morgens ist nie nur eine technische Meldung. Er ist eine Entscheidungssituation: Muss jemand sofort aufstehen, reicht ein Workaround bis zum Morgen oder braucht der Vorfall direkt Führung, Kommunikation und Fachbereichsbeteiligung? Wer diese Fragen erst im Moment des Alarms klärt, macht Bereitschaft unnötig hektisch.

Bereitschaft im IT-Betrieb bedeutet, dass außerhalb normaler Arbeitszeiten handlungsfähige Personen erreichbar sind. Für ITSM-Generalisten ist dabei nicht die Rufnummernliste der Kern, sondern das Betriebsmodell dahinter. Es muss festlegen, welche Services kritisch sind, welche Ausfälle sofortiges Handeln brauchen, wer entscheiden darf und wie Nutzer informiert werden.

Erreichbarkeit ist noch keine Verantwortung

Viele Organisationen behandeln Bereitschaft zunächst als Besetzungsfrage. Es gibt einen Plan, eine Telefonnummer, ein Alarmwerkzeug und vielleicht eine Eskalationskette. Das ist notwendig, aber nicht ausreichend. Wenn die angerufene Person zwar erreichbar ist, aber keine Entscheidungskompetenz hat, entsteht nur eine schnellere Warteschleife.

Atlassian beschreibt Incident Management als koordinierten Umgang mit Störungen, bei dem Rollen, Kommunikation und Wiederherstellung zusammenkommen. PagerDuty betont in seinen Incident-Response-Materialien ebenfalls klare Rollen und Eskalationswege. Der gemeinsame Punkt ist einfach: Ein Alarm braucht nicht nur jemanden, der ihn sieht. Er braucht jemanden, der einschätzen kann, was jetzt zählt.

Dringlichkeit muss vor dem Ernstfall übersetzt werden

Technische Überwachung meldet Schwellenwerte, Fehlercodes, Antwortzeiten oder fehlgeschlagene Jobs. Der Betrieb muss daraus Servicebedeutung machen. Ein voller Speicher auf einem Testsystem ist anders zu bewerten als derselbe Zustand auf einer Plattform, über die Kunden Aufträge auslösen. Eine Schnittstelle kann technisch rot sein, aber fachlich gerade keine unmittelbare Wirkung haben. Umgekehrt kann ein scheinbar kleiner Fehler eine kritische Kette blockieren.

Deshalb braucht Bereitschaft klare Entscheidungskriterien. Welche Services haben echte Nachtkritikalität? Welche Störung darf bis zum nächsten Werktag warten? Ab wann muss ein Service Owner informiert werden? Wann braucht es eine Nutzerkommunikation statt stiller Reparatur? Solche Fragen gehören nicht in improvisierte Chatverläufe, sondern in verständliche Betriebsregeln.

Alarmketten brauchen Grenzen

Eine Eskalationskette soll helfen, wenn die erste Person nicht reagieren kann oder wenn der Vorfall größer ist als erwartet. Sie wird aber problematisch, wenn sie jeden unklaren Alarm automatisch nach oben schiebt. Dann werden Führungskräfte, Spezialisten und Lieferanten nachts beteiligt, ohne dass jemand zuvor die Wirkung geprüft hat.

Gute Bereitschaft trennt deshalb technische Erstreaktion, fachliche Bewertung und Führungseskalation. Die erste Reaktion prüft, ob der Alarm echt ist und ob ein bekannter Ablauf hilft. Die fachliche Bewertung klärt, welche Nutzer, Prozesse oder Zusagen betroffen sind. Die Führungseskalation beginnt, wenn Risiko, Außenwirkung, Kosten oder längere Unterbrechung eine Entscheidung außerhalb des Technikteams verlangen.

Workarounds brauchen dieselbe Disziplin wie Reparaturen

Nachts ist die vollständige Ursachenbehebung nicht immer der beste erste Schritt. Manchmal ist ein sicherer Workaround sinnvoller: Dienst neu starten, Traffic umleiten, fehlerhafte Funktion deaktivieren oder betroffene Nutzer auf einen Ersatzprozess hinweisen. Damit das nicht beliebig wird, müssen Workarounds vorab bewertet sein.

Ein Workaround ist nur dann gut, wenn er den Service stabilisiert, keine größeren Folgeschäden erzeugt und sauber dokumentiert wird. Wer nachts schnell etwas umstellt, muss am nächsten Tag erklären können, was geändert wurde, warum es nötig war und welche Nacharbeit offen ist. Sonst verlagert sich das Problem nur in den nächsten Morgen.

Der nächste Arbeitstag entscheidet über die Qualität

Bereitschaft endet nicht mit dem Schließen des Alarms. Der nächste Arbeitstag zeigt, ob der Betrieb gelernt hat. War der Alarm berechtigt? Hat die richtige Person reagiert? Waren Informationen auffindbar? Musste jemand entscheiden, der dafür nicht vorbereitet war? Gab es unnötige Eskalationen oder zu späte Kommunikation?

Diese Nacharbeit muss leichtgewichtig bleiben, aber verbindlich sein. Wiederkehrende Nachtalarme gehören in Problem Management, nicht nur in den Bereitschaftsplan. Unklare Entscheidungsfälle gehören in die Servicekritikalität zurück. Fehlende Anleitungen gehören in die Wissensbasis. So wird Bereitschaft nicht zur dauerhaften Belastungsverwaltung, sondern zu einem Sensor für Schwächen im Betriebsmodell.

Prüffragen für einen belastbaren Bereitschaftsdienst

• Ist für jeden kritischen Service klar, ob nachts sofort reagiert werden muss?
• Weiß die erste Bereitschaftsperson, welche Entscheidungen sie selbst treffen darf?
• Gibt es verständliche Kriterien für technische, fachliche und Führungseskalation?
• Sind Workarounds dokumentiert, begrenzt und am nächsten Arbeitstag nachvollziehbar?
• Wird jeder unnötige oder unklare Alarm später überprüft?
• Ist geregelt, wann Nutzer oder Fachbereiche informiert werden müssen?

Bereitschaft ist keine Notlösung für schlechte Vorbereitung. Sie ist ein Betriebsversprechen für kritische Situationen. Dieses Versprechen hält nur, wenn vor dem Alarm geklärt ist, wer handelt, wer entscheidet, wer informiert und was danach verbessert wird. Die wichtigste Frage lautet deshalb nicht, ob jemand erreichbar ist. Sie lautet, ob die erreichbare Person im entscheidenden Moment wirklich handlungsfähig ist.

Quellen und Einordnung: Atlassian zu Incident Management, PagerDuty Incident Response Guide, ITIL-nahe Praxis zur Incident- und Problem-Management-Trennung sowie Microsoft Learn zur Rolle von Incident Response und Nachbereitung. Stand der Quellenprüfung: 26.06.2026.