Bildquelle: Pexels / Pixabay / https://www.pexels.com/photo/356056/
Kurz gesagt Automatisierung ist im IT-Betrieb nur dann ein Gewinn, wenn sie sich in kritischen Momenten gezielt bremsen, stoppen oder überstimmen lässt. Skripte, Workflows und KI-gestützte Helfer können Routinearbeit beschleunigen. Im Störfall dürfen sie aber nicht blind denselben Auftrag weiter ausführen, während Menschen noch prüfen, was gerade kaputtgeht.
Google beschreibt in seinem SRE-Buch Automatisierung als zentrales Werkzeug, warnt aber zugleich vor dem Irrtum, dass automatisierte Abläufe automatisch sicherer sind. AWS Systems Manager Automation zeigt, wie technische Abläufe als definierte Schritte ausgeführt werden können. Atlassian betont im Incident Management, dass Störungen klare Rollen, Prioritäten und Kommunikation brauchen. Für ITSM-Generalisten folgt daraus eine einfache Betriebsfrage: Wer stoppt die Maschine, wenn der Kontext nicht mehr stimmt?
Automatisierung meint hier wiederkehrende technische Abläufe, die ohne ständige manuelle Bedienung ausgeführt werden. Das können Deployments, Neustarts, Ticketaktionen, Standardänderungen, Prüfungen oder Wiederherstellungsaufgaben sein. Im Normalbetrieb spart das Zeit. Im Ausnahmefall kann derselbe Vorteil zum Risiko werden, wenn der Ablauf zu schnell, zu breit oder auf falscher Grundlage weiterarbeitet.
Geschwindigkeit ist kein Ersatz für Kontrolle
Automatisierung wird oft mit Effizienz verkauft. Ein Klick ersetzt zehn manuelle Schritte, ein Workflow verteilt Aufgaben, ein Skript setzt Konfigurationen, ein Assistent ergänzt Tickets oder startet Diagnosen. Das ist sinnvoll, solange die Lage bekannt ist und die Eingaben stimmen. Im Störfall ist die Lage aber gerade nicht stabil. Signale widersprechen sich, Abhängigkeiten sind unklar, Nutzer melden Symptome statt Ursachen und die wichtigste Frage lautet nicht mehr „Wie schnell geht es?“, sondern „Was darf jetzt noch automatisch passieren?“
Ein automatisierter Neustart kann einen Dienst wieder verfügbar machen. Er kann aber auch Spuren überschreiben, eine Fehlerkette verschleiern oder einen bereits überlasteten Bereich erneut belasten. Ein automatisches Ticket-Routing kann Zuständigkeiten beschleunigen. Es kann aber auch eine akute Störung in Routinekategorien zerlegen, die niemand als zusammenhängendes Problem erkennt. Deshalb braucht jede relevante Automatisierung eine sichtbare Grenze zwischen Normalbetrieb und Ausnahmebetrieb.
Der Stoppknopf muss vorher vereinbart sein
Im Ernstfall ist es zu spät, über Grundsatzfragen zu diskutieren. Wenn ein Workflow produktive Systeme verändert, Zugänge anlegt, Dienste neu startet, Konfigurationen verteilt oder Daten verschiebt, muss vorher klar sein, wie er angehalten wird. Das ist nicht nur eine technische Frage. Es geht auch um Berechtigung, Verantwortung und Kommunikation.
Ein guter Stoppmechanismus beantwortet vier Fragen. Wer darf den Ablauf stoppen? Welche Signale lösen eine Pause aus? Was passiert mit bereits begonnenen Schritten? Und wie sehen Betrieb, Service Desk und Fachbereich, dass die Automatisierung gerade nicht weiterarbeitet? Ohne diese Antworten entsteht ein gefährlicher Zwischenzustand: Menschen glauben, sie hätten die Lage übernommen, während im Hintergrund noch geplante oder regelbasierte Aktionen laufen.
Automatisierung braucht einen Betriebsmodus für Ausnahmen
Viele technische Abläufe kennen nur aktiv oder inaktiv. Für den Betrieb reicht das selten. Praktischer ist ein eigener Ausnahmebetrieb. In diesem Modus darf die Automatisierung beobachten, protokollieren und Vorschläge machen, aber keine riskanten Änderungen mehr selbst ausführen. Stattdessen braucht sie Freigaben, engere Grenzen oder eine Übergabe an eine Rolle mit Entscheidungsverantwortung.
Dieser Modus ist besonders wichtig bei wiederkehrenden Reparaturaktionen. Ein System, das bei einem Fehler automatisch neu startet, kann sehr hilfreich sein. Wenn der Fehler aber alle paar Minuten wiederkommt, wird aus Hilfe ein Taktgeber der Störung. Dann muss die Automatisierung erkennen, dass der Normalfall vorbei ist. Sie sollte eskalieren, Kontext sammeln und weitere Aktionen zurückhalten, bis ein Mensch die Lage bewertet hat.
Protokolle müssen erklären, was wirklich passiert ist
Ein häufiges Problem zeigt sich erst nach der Störung. Teams wissen, dass etwas automatisch gelaufen ist, können aber nicht sauber nachvollziehen, welcher Schritt wann, mit welcher Eingabe und mit welchem Ergebnis ausgeführt wurde. Für ITSM ist das ein Qualitätsmangel. Ohne belastbare Protokolle bleibt die Nachanalyse vage. Dann wird zwar ein Workflow verbessert, aber nicht unbedingt die Ursache verstanden.
Gute Automatisierung dokumentiert deshalb mehr als Erfolg oder Fehler. Sie hält den Auslöser fest, die betroffenen Systeme, die Entscheidungspunkte, ausgelassene Schritte, manuelle Freigaben und Abbruchgründe. Gerade bei Sicherheits- und Verfügbarkeitsvorfällen zählt diese Nachvollziehbarkeit. Sie hilft nicht nur der Technik, sondern auch Service Ownern, Datenschutz, Revision und Kommunikation.
KI-Helfer verschärfen die Frage nach Grenzen
Mit KI-gestützten Assistenten wird die Stoppfrage noch wichtiger. Ein klassisches Skript folgt einer festen Abfolge. Ein KI-Helfer kann dagegen Texte zusammenfassen, Vorschläge machen, Tickets interpretieren oder nächste Schritte empfehlen. Das kann den Service Desk entlasten. Es darf aber nicht dazu führen, dass unklare Lagebilder in scheinbar sichere Aktionen übersetzt werden.
Für den Betrieb ist deshalb entscheidend, welche Rechte ein solcher Helfer hat. Lesen, ordnen und erklären ist etwas anderes als ändern, schließen, neu starten oder informieren. Je näher die Automatisierung an produktive Wirkung kommt, desto klarer müssen Freigaben, Ausschlüsse und Protokolle sein. Ein Assistent, der im Normalbetrieb nützlich ist, sollte im Störfall eher zum Lagebild beitragen als selbst Entscheidungen vollziehen.
Prüffragen für den nächsten Automatisierungs-Review
- Welche produktiven Änderungen kann der Ablauf ohne erneute Freigabe auslösen?
- Welche Störungssignale schalten die Automatisierung in einen Pausen- oder Vorschlagsmodus?
- Wer sieht sofort, dass ein Ablauf gestoppt oder begrenzt wurde?
- Welche Protokolle zeigen später Auslöser, Schritte, Ergebnisse und Abbruchgründe?
- Welche Aktionen bleiben im Störfall ausdrücklich Menschen vorbehalten?
- Wie wird verhindert, dass wiederholte automatische Reparaturen die Ursache verdecken?
Fazit
Automatisierung macht den Betrieb nicht automatisch robuster. Sie wird erst dann belastbar, wenn sie Grenzen kennt, Ausnahmezustände erkennt und Entscheidungen nachvollziehbar an Menschen übergeben kann. Der wichtigste Teil eines Workflows ist deshalb manchmal nicht der schnellste Schritt, sondern die Stelle, an der er anhält.
