Bereitschaftsdienst braucht mehr als eine Telefonnummer

Ein Bereitschaftsdienst wirkt auf dem Papier oft beruhigend. Es gibt eine Nummer, einen Dienstplan und die Zusage, dass im Ernstfall jemand reagiert. Im echten IT-Betrieb reicht das nicht. Wenn Rollen, Eskalationswege und Übergaben unklar sind, wird die Rufbereitschaft zum Zufallssystem. Dann hängt der Service nicht an einem belastbaren Prozess, sondern an persönlicher Erfahrung, gutem Willen und der Frage, wer nachts gerade erreichbar ist.

Für ITSM-Generalisten ist Bereitschaft deshalb kein reines Technikthema. Sie verbindet Incident Management, Servicekatalog, Providersteuerung, Dokumentation, Kommunikation und Fürsorge für Mitarbeitende. Der wichtigste Punkt lautet. Eine Telefonnummer löst keine Störung. Sie öffnet nur die Tür zu einem Ablauf, der vorher geübt, beschrieben und verantwortet sein muss.

Der erste Fehler entsteht vor dem Alarm

Schwache Bereitschaftsmodelle fallen selten erst an der Technik auseinander. Der erste Fehler entsteht früher. Es ist nicht eindeutig, welche Services überhaupt Bereitschaft brauchen. Es fehlt eine Priorisierung nach Geschäftsauswirkung. Alarme werden aus Systemen erzeugt, ohne dass klar ist, ob sie nachts wirklich eine menschliche Reaktion verlangen. Die Folge sind unnötige Weckrufe, verspätete Reaktionen auf echte Ausfälle und eine sinkende Aufmerksamkeit bei denen, die erreichbar sein sollen.

Ein belastbarer Bereitschaftsdienst beginnt deshalb mit Serviceklarheit. Welche Funktionen sind kritisch. Welche Ausfälle können bis zum nächsten Arbeitstag warten. Welche Kunden, Standorte oder Geschäftsprozesse sind betroffen. Welche Schwellenwerte lösen eine Alarmierung aus. Diese Fragen gehören nicht in den Moment, in dem das Telefon klingelt. Sie gehören in den Servicekatalog, in Betriebsvereinbarungen, in Lieferantenverträge und in die Incident-Regeln.

Alarmierung ohne Kontext kostet Minuten

Ein Alarm ist nur hilfreich, wenn er genug Kontext liefert. Ein kurzer technischer Hinweis wie CPU hoch, Login fehlerhaft oder Datenbank langsam zwingt die Person im Bereitschaftsdienst erst zur Detektivarbeit. Besonders nachts ist das gefährlich. Müdigkeit, Zeitdruck und fehlende Rückfragen erhöhen das Risiko, dass Symptome falsch bewertet werden. Gute Alarmierung sagt deshalb nicht nur, was ein System meldet, sondern welcher Service betroffen sein könnte, welche Auswirkung sichtbar ist und welcher erste Prüfpfad sinnvoll ist.

Dazu gehören Links auf Dashboards, letzte Änderungen, betroffene Komponenten, bekannte Abhängigkeiten und ein klarer Hinweis, wann eskaliert werden muss. Wenn der Bereitschaftsdienst jedes Mal zuerst Logdateien, Kontakte und Runbooks zusammensuchen muss, ist der Prozess nicht reif. Ein guter Alarm verkürzt die Zeit bis zur richtigen Entscheidung. Ein schlechter Alarm verlagert Arbeit in die unpassendste Minute.

Eskalation muss erlaubt und erwartet sein

In manchen Organisationen gilt Eskalation noch immer als persönliches Scheitern. Das ist für Bereitschaft gefährlich. Niemand kann nachts jedes System, jede Anwendung und jeden Provider allein beherrschen. Ein sauberer Bereitschaftsprozess legt fest, wann die zweite Stufe dazukommt, wann ein Incident Manager übernehmen soll, wann Management informiert wird und wann externe Dienstleister eingebunden werden. Eskalation ist dann kein Drama, sondern ein normaler Steuerungsschritt.

Wichtig ist auch die Reihenfolge. Wenn eine zentrale Identitätsplattform ausfällt, hilft der Datenbankexperte allein wenig. Wenn ein externer Netzwerkprovider betroffen ist, muss jemand den Vertrags- und Eskalationspfad kennen. Wenn Kundendaten oder regulatorische Meldepflichten berührt sein könnten, braucht es definierte Schnittstellen zu Security, Datenschutz und Kommunikation. Bereitschaft wird erst dann stabil, wenn diese Wege nicht improvisiert werden.

Übergaben entscheiden über den nächsten Morgen

Der Bereitschaftsdienst endet nicht, wenn der akute Alarm verstummt. Am nächsten Morgen muss der Regelbetrieb verstehen, was passiert ist. Welche Symptome wurden gesehen. Welche Maßnahmen wurden ergriffen. Welche Workarounds laufen noch. Welche Risiken bleiben offen. Welche Tickets, Changes oder Provideranfragen wurden erzeugt. Ohne diese Übergabe entstehen Folgestörungen. Der Service Desk erklärt veraltete Informationen, Fachbereiche melden bekannte Nachwirkungen neu und Betriebsteams wiederholen Analysen, die nachts schon erledigt wurden.

Eine einfache Übergabevorlage reicht oft aus. Zeitpunkt, betroffener Service, sichtbare Auswirkung, getroffene Maßnahmen, aktueller Zustand, offene Punkte und empfohlener nächster Schritt. Diese Informationen sollten nicht in Chatverläufen verschwinden, sondern im Incident-Datensatz landen. So wird Bereitschaft Teil des ITSM-Prozesses und nicht eine parallele Schattenarbeit außerhalb der normalen Steuerung.

Gute Bereitschaft schützt auch die Menschen

On-Call-Arbeit ist belastend. Wer regelmäßig nachts geweckt wird, entscheidet am nächsten Tag schlechter, arbeitet langsamer und verliert langfristig Motivation. Deshalb ist Fürsorge kein weiches Zusatzthema, sondern ein Betriebsrisiko. Google beschreibt in seinen SRE-Praktiken ausdrücklich, dass Bereitschaft nur tragfähig bleibt, wenn Alarmqualität, Rotationen, Belastung und Erholung ernst genommen werden. Für ITSM heißt das. Ein Dienstplan ist erst dann gut, wenn er sowohl die Services als auch die Menschen schützt.

Dazu gehören klare Ruhezeiten, realistische Rotationen, Vertretungen, Nachbereitung auffälliger Alarmserien und die Bereitschaft, unnötige Alarme abzustellen. Jede wiederholte Nachtalarmierung sollte eine Verbesserungsfrage auslösen. War der Alarm nötig. War er verständlich. Hätte Automatisierung geholfen. Fehlt ein Runbook. Muss ein Service anders überwacht werden. So wird Bereitschaft nicht nur reaktiver Schutz, sondern ein Sensor für strukturelle Schwächen im Betrieb.

Die praktische Prüffrage für ITSM-Verantwortliche

Ein einfacher Test zeigt, ob die eigene Rufbereitschaft belastbar ist. Nehmen Sie einen kritischen Service und stellen Sie sich einen Ausfall am Samstag um 2 Uhr vor. Wer wird alarmiert. Welche Information bekommt diese Person. Welche ersten Schritte sind dokumentiert. Wann wird eskaliert. Wer informiert den Service Desk. Welche Providerkontakte sind aktuell. Wo landet die Übergabe am Morgen. Wenn eine dieser Antworten nur mit persönlichem Wissen funktioniert, ist die Bereitschaft noch nicht prozessfest.

Der nächste Schritt muss nicht ein großes Programm sein. Oft genügt ein kleiner, konsequenter Anfang. Kritische Services priorisieren, Alarmtexte verbessern, Eskalationsstufen prüfen, Übergabevorlage einführen und die letzten Nachtalarme gemeinsam auswerten. So entsteht ein Bereitschaftsdienst, der nicht von Helden lebt, sondern von klaren Entscheidungen.

Bereitschaft ist damit kein Anhängsel des Monitorings. Sie ist ein sichtbarer Reifegrad des Betriebs. Wo sie gut funktioniert, reagieren Teams schneller, eskalieren früher richtig und übergeben sauberer an den Regelbetrieb. Wo sie nur aus einer Telefonnummer besteht, wirkt sie bis zum ersten echten Ausfall stabil. Danach zeigt sich, ob dahinter ein Prozess steht oder nur Hoffnung.

Quellen. Google Site Reliability Engineering Book, Being On-Call. Atlassian, On-Call Management. Atlassian, Incident Roles and Responsibilities. NIST Special Publication 800-61 Revision 2, Computer Security Incident Handling Guide. AXELOS, ITIL 4 Incident Management Practice.