Bildquelle: Pexels / https://www.pexels.com/photo/236705/
Kurz gesagt Ein Notfallplan wirkt erst zuverlässig, wenn er unter echten Bedingungen geübt wurde. Ein Ausfalltest prüft, ob Teams, Technik, Kommunikation und Entscheidungen zusammen funktionieren, während Druck entsteht. Für ITSM und IT-Management ist das kein Spezialthema für Rechenzentren, sondern eine Führungsfrage: Welche Services müssen weiterlaufen, wer entscheidet im Ernstfall und wie schnell erkennt der Betrieb, dass der Plan an einer Stelle nur auf Papier funktioniert?
In vielen IT-Organisationen gibt es Dokumente für Wiederanlauf, Eskalation und Kommunikation. Sie beschreiben Systeme, Kontakte, Reihenfolgen und Rollen. Solche Pläne sind wichtig, aber sie beantworten nicht automatisch die wichtigste Frage im Ernstfall: Funktioniert das Ganze, während Menschen müde sind, Informationen fehlen und Nutzer Antworten erwarten? Genau hier trennt ein Ausfalltest saubere Vorbereitung von Wunschdenken.
Warum ein grüner Plan noch keinen sicheren Betrieb beweist
Ein Notfallplan kann formal vollständig sein und trotzdem im Alltag scheitern. Telefonnummern sind veraltet, Fachbereiche haben neue Abhängigkeiten aufgebaut, ein Cloud-Dienst wurde anders integriert als dokumentiert oder eine Entscheidung hängt an einer Person, die im Test gerade nicht verfügbar ist. Der Plan sieht dann gut aus, aber der Betrieb entdeckt seine Lücken erst bei der Störung.
Das AWS Well-Architected Framework betont im Zuverlässigkeitsbereich, dass Wiederherstellungsverfahren getestet werden müssen. Der Kern ist einfach: Systeme und Abläufe werden nicht dadurch belastbar, dass man sie beschreibt. Belastbarkeit entsteht, wenn der Betrieb Störungen erwartet, Übungen durchführt, Ergebnisse misst und die nächste Verbesserung daraus ableitet.
Ausfalltests gehören in den Serviceprozess
Für ITSM ist der Ausfalltest mehr als ein technisches Experiment. Er berührt Incident Management, Change Management, Servicekatalog, Kommunikation, Lieferantensteuerung und Business Continuity. Wenn ein kritischer Service ausfällt, reicht es nicht, dass ein einzelnes Infrastrukturteam weiß, welchen Server es neu starten muss. Der Betrieb muss auch wissen, wer Nutzer informiert, welche Fachbereiche betroffen sind, welche Alternativen erlaubt sind und wann eine Eskalation zur Managemententscheidung wird.
Darum sollte jeder größere Test mit einer klaren Servicefrage beginnen. Es geht nicht nur um die Wiederherstellung einer Datenbank oder einer Anwendung. Es geht um den Geschäftsprozess dahinter. Welche Arbeit steht still? Welche Nutzergruppen merken den Ausfall zuerst? Welche Zusagen wurden im Service Level vereinbart? Welche Kommunikation ist nach 15, 30 oder 60 Minuten notwendig?
Der erste Test sollte klein genug für echte Durchführung sein
Der größte Fehler ist ein zu großes Übungsdesign. Ein vollständiger Ausfall aller zentralen Systeme klingt professionell, wird aber schnell so riskant und aufwendig, dass er nie stattfindet. Besser ist ein begrenzter erster Test mit einem klaren Szenario. Ein einzelner Service, eine definierte Abhängigkeit, ein überschaubares Zeitfenster und ein klares Abbruchkriterium reichen aus, um viel zu lernen.
Ein guter Einstieg kann ein Tabletop-Test sein. Dabei wird eine Störung gemeinsam durchgespielt, ohne produktive Systeme wirklich abzuschalten. Das Team prüft, wer welche Information braucht, welche Entscheidung ansteht und welche Dokumente genutzt werden. Danach folgt ein technischer Teiltest, etwa die Wiederherstellung aus einem Backup, das Umschalten auf eine Ersatzkomponente oder die Überprüfung eines Kommunikationswegs.
Was ein Ausfalltest sichtbar machen muss
Ein Test ist nur dann wertvoll, wenn er mehr prüft als den technischen Neustart. Die wichtigste Erkenntnis liegt oft in Schnittstellen zwischen Rollen. Wer erkennt den Ausfall? Wer bewertet die Auswirkung? Wer darf eine Umleitung freigeben? Wer informiert den Service Desk? Wer spricht mit dem Fachbereich? Wer entscheidet, dass eine kurzfristige Umgehung mehr Risiko erzeugt als der Ausfall selbst?
- Der Test braucht ein konkretes Szenario mit betroffenem Service und erwarteter Auswirkung.
- Rollen und Entscheidungswege werden während der Übung geprüft, nicht erst im Nachgang erklärt.
- Kommunikation an Nutzer, Fachbereiche und Management wird als eigener Prüfpunkt behandelt.
- Wiederherstellungszeit und Datenverlust werden gemessen und mit den Servicezielen verglichen.
- Abhängigkeiten zu Lieferanten, Cloud-Diensten und internen Plattformen werden ausdrücklich notiert.
- Jede Lücke bekommt einen Besitzer, einen Termin und einen sichtbaren Nachtest.
Incident Response liefert wichtige Lehren
Das Site Reliability Workbook von Google beschreibt Incident Response als Zusammenspiel aus klaren Rollen, Kommunikation und Lernen aus Störungen. Auch wenn viele ITSM-Teams nicht nach dem SRE-Modell arbeiten, ist die Grundidee gut übertragbar. Im Ernstfall darf nicht unklar bleiben, wer führt, wer kommuniziert, wer technische Arbeit koordiniert und wer Entscheidungen dokumentiert.
NIST SP 800-34 zur Notfallplanung für Informationssysteme betont ebenfalls, dass Notfallpläne entwickelt, getestet, gepflegt und aktualisiert werden müssen. Für Generalisten ist daran besonders wichtig: Kontinuität ist kein einmaliges Dokument, sondern ein Zyklus. Planen, üben, messen, verbessern und erneut prüfen gehören zusammen.
Die Nacharbeit entscheidet über den Nutzen
Nach dem Test beginnt der wichtigste Teil. Ein Protokoll voller Beobachtungen hilft wenig, wenn daraus keine Änderungen im Betrieb entstehen. Jede Erkenntnis muss in konkrete Arbeit übersetzt werden. Ein veralteter Kontakt wird korrigiert, eine unklare Entscheidung bekommt eine Regel, ein fehlendes Monitoring wird ergänzt, ein Wiederherstellungsschritt wird vereinfacht und ein Kommunikationsbaustein wird vorbereitet.
Auch der Service Desk sollte in diese Nacharbeit einbezogen werden. Er erlebt bei echten Ausfällen früh, welche Fragen Nutzer stellen und welche Antworten fehlen. Wenn der Ausfalltest nur in Technikrunden bleibt, entstehen später wieder Lücken in der Kommunikation. Ein guter Test prüft deshalb auch Antwortbausteine, Statusseiten, interne Lageupdates und Übergaben zwischen Schichten.
Ein realistischer Test schützt vor falscher Sicherheit
Der erste Ausfalltest muss nicht spektakulär sein. Er muss ehrlich sein. Er zeigt, ob ein Plan gelesen, verstanden und unter Druck angewendet werden kann. Er zeigt, ob technische Wiederherstellung und betriebliche Kommunikation zusammenpassen. Und er zeigt, ob Serviceziele wirklich erreichbar sind oder nur als optimistische Zahl im Dokument stehen.
Für ITSM-Verantwortliche ist die Leitfrage deshalb einfach: Welche Annahme im Notfallplan wäre am teuersten, wenn sie nicht stimmt? Genau dort sollte der nächste Test beginnen. Nicht die schönste Dokumentation schützt den Betrieb, sondern die früh entdeckte Lücke, die vor dem echten Ausfall geschlossen wird.
