Wie aus Monitoring Schritt für Schritt ein lernender Betriebsprozess werden kann:

Wenn ich über AIOps spreche, denke ich nicht zuerst an eine AI, die den IT-Betrieb vollständig autonom übernimmt. Aus meiner Erfahrung liegt der größere Hebel viel früher: Wir müssen die Informationen, die im Betrieb ohnehin entstehen, besser zusammenbringen. Monitoringdaten, Alarme, Tickets, Runbooks und das Wissen der Administratoren existieren oft bereits – nur verteilt auf verschiedene Werkzeuge und Köpfe.

Mein Blick auf AIOps

Für mich ist AIOps deshalb vor allem ein Entwicklungsweg. Am Anfang steht ein solides Monitoring. Danach geht es darum, Alarmfluten zu reduzieren, Tickets automatisch mit dem richtigen Kontext zu versorgen und aus gelösten Störungen verwertbares Wissen aufzubauen. Erst wenn diese Basis funktioniert, wird AI wirklich hilfreich – zunächst als Assistent und später, bei klar definierten Standardfällen, auch für eine automatisierte Lösung.

Warum ich den Use Case für KMU interessant finde

Gerade in kleineren IT-Organisationen sehe ich einen sehr praktischen Nutzen. Häufig gibt es wenige Spezialisten, die sehr viel Wissen über die Umgebung besitzen. Wenn eine Störung auftritt, wissen diese Personen oft schnell, wo sie nachsehen müssen. Das funktioniert – solange die richtigen Menschen verfügbar sind. Schwieriger wird es bei Urlaub, Bereitschaft, Personalwechsel oder wenn die Umgebung wächst.

Genau hier kann AIOps unterstützen: nicht indem Erfahrungswissen ersetzt wird, sondern indem dieses Wissen systematisch nutzbar gemacht wird. Mein Ziel wäre, dass ein Mitarbeiter bei einem Incident nicht bei null startet, sondern bereits eine verständliche Zusammenfassung, ähnliche Fälle und mögliche nächste Schritte vorfindet.

Der Weg dorthin: bewusst in kleinen Schritten

1. Erst die Basics sauber bekommen

Ich würde nicht mit einem AI-Projekt starten, sondern mit einer einfachen Frage: Wissen wir bei unseren wichtigsten Services, was wir überwachen, wem der Service gehört und welche Systeme voneinander abhängen? Für einen ersten Use Case reicht es, sich auf wenige geschäftskritische Anwendungen zu konzentrieren. Perfektion ist hier aus meiner Sicht weniger wichtig als ein klarer, beherrschbarer Scope.

2. Vom technischen Monitoring zum Service-Blick

Ein Server kann technisch erreichbar sein und der Anwender trotzdem ein Problem haben. Deshalb würde ich das Monitoring schrittweise um Service-Kriterien ergänzen: Antwortzeiten, Fehlerraten, erfolgreiche Transaktionen oder andere Werte, die tatsächlich etwas über die Nutzbarkeit aussagen. Das macht spätere AI-Auswertungen deutlich wertvoller.

3. Weniger Alarme, dafür bessere Alarme

Eine typische Herausforderung ist für mich nicht zu wenig Monitoring, sondern zu viel Rauschen. Wenn ein Ausfall zwanzig technische Meldungen erzeugt, sollte der Operator nicht zwanzig Einzelprobleme untersuchen müssen. Der nächste Reifegrad besteht deshalb darin, Meldungen zu gruppieren, Duplikate zu entfernen und den möglichen Zusammenhang sichtbar zu machen.

4. Das Ticket wird zum Informationspaket

Hier entsteht für mich bereits ein sehr konkreter Nutzen – auch ganz ohne autonome AI. Wird ein Incident erkannt, kann automatisch ein Ticket entstehen, das nicht nur den Alarmtext enthält. Es sollte die betroffenen Services, relevante Messwerte, Logs, letzte Änderungen und gegebenenfalls ähnliche Incidents mitbringen. Damit entfällt ein Teil der manuellen Recherche.

5. AI unterstützt bei Diagnose und Lösung

Erst an diesem Punkt würde ich AI stärker ins Spiel bringen. Sie kann den aktuellen Incident mit historischen Tickets, Runbooks und Dokumentationen vergleichen und beispielsweise sagen: Dieses Fehlerbild hatten wir schon einmal; damals lag die Ursache hier und diese Maßnahme hat geholfen. Wichtig ist mir, dass der Vorschlag nachvollziehbar bleibt und der Mitarbeiter zunächst entscheidet.

6. Automatisieren, wenn wir dem Prozess vertrauen

Wenn bestimmte Fehlerbilder häufig auftreten, eindeutig erkannt werden können und eine bekannte, risikoarme Lösung besitzen, lässt sich der nächste Schritt gehen. Eine Maßnahme kann automatisiert ausgeführt werden. Dazu gehört für mich zwingend eine anschließende Prüfung: Ist der Service tatsächlich wieder gesund? Nur dann ist aus Automation echtes Self-Healing geworden.

Ein Beispiel aus dem Betriebsalltag

Nehmen wir einen Webshop, der plötzlich deutlich langsamer wird. Heute könnte der Ablauf so aussehen: Das Monitoring erzeugt mehrere Alarme, ein Administrator öffnet verschiedene Dashboards, prüft Logs, erstellt ein Ticket und erinnert sich vielleicht daran, dass ein ähnlicher Fehler schon einmal aufgetreten ist.

In meinem AIOps-Zielbild erkennt das System die zusammengehörigen Signale und erstellt daraus einen Incident. Das Ticket wird automatisch mit den relevanten Informationen angereichert. Die AI findet einen vergleichbaren früheren Fall und schlägt beispielsweise vor, einen bestimmten Dienst kontrolliert neu zu starten. Anfangs bestätigt ein Administrator diesen Schritt. Wenn sich der Ablauf über viele Fälle als zuverlässig erwiesen hat, kann genau dieser Standardfall später automatisiert werden.

Der entscheidende Punkt: Wissen entsteht im Prozess

Für mich ist die Knowledge Base der wichtigste langfristige Baustein. Viele Unternehmen besitzen bereits sehr viel Wissen – in Tickets, Wiki-Seiten, Runbooks, E-Mails oder schlicht in der Erfahrung einzelner Kollegen. Für AI ist dieses Wissen aber nur dann wirklich wertvoll, wenn der Zusammenhang zwischen Problem, Ursache, Maßnahme und Ergebnis erkennbar wird.

Ich würde dabei bewusst pragmatisch anfangen. Es muss nicht zuerst eine perfekte zentrale Wissensplattform entstehen. Ein guter Startpunkt sind die zehn oder zwanzig häufigsten Incident-Typen: Welche Symptome sehen wir? Wie diagnostizieren wir sie? Was ist eine bestätigte Lösung? Und woran erkennen wir anschließend, dass die Lösung funktioniert hat?

Was ich nicht automatisieren würde

Nicht jeder Incident eignet sich für Self-Healing. Kritische Änderungen, unklare Fehlerbilder oder Maßnahmen mit hohem Risiko würde ich weiterhin unter menschlicher Kontrolle lassen. Automatisierung sollte dort beginnen, wo ein Fehlerbild eindeutig, die Maßnahme bekannt, reversibel und ihr Erfolg messbar ist. Freigaben, Berechtigungen, Logging und Rollback gehören für mich von Anfang an zum Konzept und nicht erst in eine spätere Projektphase.

Wie ich mit einem KMU starten würde

• Einen relevanten, aber überschaubaren Service als Pilot auswählen.
• Die häufigsten Alarme und Incidents dieses Services analysieren.
• Alarmrauschen reduzieren und relevante Informationen automatisch zusammenführen.
• Tickets automatisch mit Monitoring- und Service-Kontext anreichern.
• Für wiederkehrende Incidents vorhandene Lösungen und Runbooks strukturiert erfassen.
• AI zunächst Empfehlungen erzeugen lassen und die Qualität messen.
• Nur bewährte, risikoarme Standardfälle schrittweise automatisieren.

Woran ich Erfolg messen würde

Ich würde den Erfolg nicht daran messen, wie viel AI eingesetzt wird. Entscheidend ist, ob der Betrieb besser wird: Gibt es weniger unnötige Alarme? Brauchen Mitarbeiter weniger Zeit für die Informationssuche? Werden Tickets vollständiger? Sinkt die Lösungszeit? Werden gute Lösungen wiederverwendet? Und wächst der Anteil der Standardfälle, die zuverlässig mit weniger manueller Arbeit bearbeitet werden können?

Mein Leitgedanke: Erst Transparenz schaffen. Dann Wissen nutzbar machen. Danach AI einsetzen. Und nur dort automatisieren, wo wir dem Prozess vertrauen.

Kurz zusammengefasst

AIOps ist für mich weniger ein einzelnes Tool als eine Weiterentwicklung des IT-Betriebs. Monitoring liefert die Signale, ITSM strukturiert die Bearbeitung, die Knowledge Base bewahrt die Erfahrungen und AI verbindet diese Informationen. Der eigentliche Mehrwert entsteht dann, wenn aus jedem gelösten Problem Wissen für den nächsten Fall entsteht.