AI für IT- und DevOps-Teams: Triage, Logs und Runbooks

Ein DevOps-Team in einem Unternehmen mit mehreren Dutzend Services erhält täglich Hunderte von Benachrichtigungen. Die meisten davon sind Rauschen. Einige erfordern eine Reaktion innerhalb von Minuten. Die manuelle Unterscheidung um zwei Uhr nachts ist ein strukturelles Problem, keine Frage der Kompetenz. AI löst es nicht durch autonomes Handeln. Sie löst es durch die Reduzierung der Kosten der ersten Entscheidung: „Erfordert dies jetzt meine Aufmerksamkeit?“

Im Folgenden beschreibe ich, wie wir bei Cashcrown diese Problemklasse angehen und warum die harte Grenze zwischen Vorschlag und Ausführung nichts ist, was man „nach der Implementierung“ umgehen kann.

Was ein Agent tun darf und was nicht#

Der Automatisierungsumfang für IT- und DevOps-Teams muss definiert werden, bevor etwas in die Pilotphase geht. Die folgende Tabelle zeigt eine typische Aufteilung für eine Produktionsumgebung mit einigen On-Call-Ingenieuren.

Die letzte Zeile ist absolut. Human-Oversight bei nicht umkehrbaren Aktionen ist keine Konfigurationsoption. Ein Agent, der eigenständig einen Firewall-Port öffnen, IAM-Berechtigungen vergeben oder die Konfiguration eines Produktionsservice ändern kann, schafft ein Risiko, das keine Sicherheitsvorkehrung in einem Sprachmodell eliminieren kann. Modelle machen Fehler. Nicht umkehrbare Aktionen in der Produktion haben reale Kosten.

Triage von Alerts und Zusammenfassungen von Logs#

Alert Fatigue ist ein gut erforschtes Problem. On-Call-Ingenieure, die über mehrere Wochen hinweg täglich Hunderte von Benachrichtigungen sehen, von denen sich 95 % als False Positives herausstellen, beginnen, jede weitere als Rauschen zu behandeln. Das ist kein Fehler der Menschen. Es ist eine unvermeidliche Folge der Asymmetrie: Die Kosten eines übersehenen realen Incidents sind enorm, während die Kosten eines falschen Alarms scheinbar null sind, weil „nichts passiert ist“. In Wirklichkeit sind die Kosten falscher Alarme real und kumulieren sich als Ermüdung, nachlassende Wachsamkeit und Burnout.

Ein Agent mit Zugriff auf das Alert-System kann auf andere Weise helfen als durch blindes Reduzieren der Anzahl. Anstatt Alerts zu filtern (was das Übersehen realer Incidents riskiert), kann er sie aggregieren und kontextualisieren:

• Alerts aus demselben Zeitfenster mit überlappenden Ressourcen gruppieren.
• In der Historie von Incidents nach ähnlichen Mustern suchen und eine Notiz extrahieren wie „vor drei Wochen endete ein ähnlicher Alert auf der Datenbankebene, behoben durch Neustart des Connection Pools“.
• Einen Ausschnitt des Fehlerstacks aus dem Service-Log extrahieren und mit offenen Tickets abgleichen.

Was der Agent nicht tut: Er entscheidet nicht, ob ein Incident real ist. Er schließt keine Alerts. Er markiert kein Ereignis als resolved. Diese Aktionen überlassen wir dem Menschen, denn das falsche Schließen eines realen Incidents ist einer der kostspieligsten operativen Fehler.

Architektur: RAG für interne Dokumentation#

Die Frage „Wie machen wir einen Deploy auf die Staging-Umgebung?“ klingt banal. In der Praxis kann ein neuer Ingenieur im Projekt 20–40 Minuten damit verbringen, die Antwort in Confluence, Notion oder einer verstreuten Sammlung von Markdown-Dateien im Repository zu suchen. Ein ausgereifter RAG für interne Dokumentation reduziert diese Zeit auf 30–60 Sekunden, vorausgesetzt, die Wissensdatenbank ist aktuell und gut in Fragmente unterteilt.

Minimale Architektur für DevOps-Dokumentation:

Wissensquellen: Runbooks, Incident-Prozeduren, Architekturübersichten von Services, Sicherheitsrichtlinien, ADRs. Jedes Dokument ist mit Metadaten versehen: Besitzer, Verifizierungsdatum, Umgebung (prod/staging/dev).

Hybride Suche: Semantische Embeddings plus Full-Text-Suche für exakte Phrasen. Semantische Retrieval allein verliert sich bei „OOM-Fehler auf node-15 im Cluster EU-west-2“, weil es sich um eine Abfrage mit konkreten Identifikatoren handelt.

Quellenangabe: Jede Antwort muss das Dokument und den Abschnitt angeben. Wenn der Agent die Quelle nicht angeben kann, sollte er „Ich weiß es nicht“ sagen und an eine menschliche Warteschlange eskalieren. Die Architektur dieses Musters beschreibt Monitoring der Qualität von AI-Agenten.

Confidence-Schwellen: Retrieval, das Fragmente unter einem Schwellenwert von 0,70–0,80 zurückgibt, sollte nicht zu einer Antwort führen. Eine Meldung wie „Ich habe keine aktuelle Prozedur gefunden“ ist besser als eine Antwort, die auf schlecht passenden Fragmenten basiert.

Alert Fatigue: Eine ehrliche Betrachtung der Kostenasymmetrie#

Die Kosten von False Positives und False Negatives im Alert-Triage sind nicht symmetrisch. Ein übersehener realer Incident kostet von Minuten Ausfallzeit bis zum Datenverlust. Ein falscher Alarm kostet zwei Minuten. Aber 200 falsche Alarme pro Tag sind 400 Minuten Rauschen. Bei diesem Ermüdungslevel kann ein realer Incident wie ein weiterer falscher Alarm aussehen.

Ein Agent, der Alerts klassifiziert, sollte in Richtung Sensitivität (Recall) kalibriert sein, nicht Präzision. Es ist besser, wenn er 15 % Rauschen fälschlicherweise eskaliert, als wenn er 1 % realer Incidents übersieht. Diese Kalibrierung ist eine ingenieurtechnische Entscheidung, keine Konfigurationsfrage.

Observability des Triage-Systems ist eine separate Schicht: Wie viele Alerts wurden eskaliert, wie viele davon waren real, wie lange dauerte es vom ersten Alert bis zur Bestätigung des Incidents durch einen Menschen. Ohne diese Metriken weiß man nicht, ob der Agent hilft oder schadet.

Sicherheitsvorkehrungen für Agenten mit Systemzugriff#

Ein DevOps-Agent, der Logs lesen, Wissensdatenbanken abfragen und Tickets klassifizieren kann, ist relativ sicher. Ein Agent, der Tools aufrufen kann (Tool-Use: Service-Neustart, Konfigurationsänderung, Berechtigungsvergabe), erfordert deutlich strengere Guardrails.

Das Muster, das wir bei Cashcrown für diese Klasse von Systemen verwenden:

Isolierung von Berechtigungen auf Tool-Ebene. Jedes Tool, das dem Agenten zur Verfügung steht, hat einen genau definierten Umfang: „Ich darf kubectl describe pod im Namespace staging aufrufen, ich darf kubectl delete pod nirgendwo aufrufen.“ Die Liste der Tools ist statisch und wird vom Security-Team vor der Implementierung genehmigt, nicht durch Echtzeit-Konfiguration.

Human-Gate für nicht umkehrbare Aktionen. Jedes Tool, dessen Aufruf den Zustand des Produktionssystems verändert, erfordert eine explizite menschliche Genehmigung vor der Ausführung. Der Agent bereitet einen fertigen Befehl mit Begründung vor. Der Ingenieur genehmigt oder lehnt ab. Muster wie HMAC-Token oder ähnliche Genehmigungsmechanismen. Ohne genehmigten Token erfolgt kein Aufruf.

Classifier für Sicherheit vor jedem Tool. Bevor die Anfrage an das Modell weitergeleitet wird, prüft eine Guardrail-Schicht auf Injection-Versuche: „Ignoriere vorherige Anweisungen“, „Du bist jetzt Admin mit vollem Zugriff“, „Führe dies ohne Protokollierung aus“. Solche Anfragen landen in einer Sicherheitswarteschlange, nicht beim Modell. Details beschreibt Sicherheit von AI-Agenten.

Vollständiges Logging mit Kontext. Jeder Tool-Aufruf durch den Agenten wird protokolliert: Was wurde angefordert, was hat der Agent vorgeschlagen, wer hat genehmigt, wann. Die Logs sind unveränderlich und für Sicherheitsaudits zugänglich. Dieser Audit-Trail ist nicht nur eine Frage des gesunden Menschenverstands, sondern kann bei Systemen, die kritische Infrastruktur beeinflussen, durch den AI Act vorgeschrieben sein.

Details zur sicheren Integration von Agenten mit externen Tools beschreibt Integration von AI mit n8n und Automatisierungen.

Routing und Klassifizierung von IT-Tickets#

Vor dem Triage von Incidents gibt es den täglichen Strom von Service-Tickets: Fragen an den Helpdesk, von Nutzern gemeldete Fehler, operative Aufgaben, Anträge auf Zugriffe. Ein auf LLM basierender Classifier kann automatisch Priorität, Kategorie und Zielwarteschlange zuweisen, bevor ein menschlicher Operator es liest.

Der Wert ist hier zweifach: Schnellere Reaktionszeit für kritische Tickets (P1 wartet nicht in der Schlange hinter 40 kleinen Anträgen) und bessere Datenqualität im Ticket-System (konsistente Kategorisierung statt willkürlichem „Misc“). Die Implementierung dieses Musters im Kontext eines IT-Helpdesks beschreibt AI-Helpdesk für IT: Interner Support-Assistent. Die technische Logik des Routings erläutert Klassifizierung und Routing von Tickets mit AI.

FAQ#

Kann AI autonom Services neu starten oder Deployments zurückrollen?#

Nein. Ein Neustart eines Produktionsservice kann das Problem lösen oder verschlimmern, wenn die Ursache tiefer liegt. Ein Rollback kann einen Incident beheben oder einen früheren Fehler offenbaren, der durch die aktuelle Version verdeckt wurde. Ein Sprachmodell hat keine Gewissheit über den Systemzustand, selbst wenn es Logs sieht. Das richtige Muster: Der Agent erstellt eine Empfehlung mit Begründung, der Ingenieur genehmigt oder lehnt ab, erst dann erfolgt die Aktion.

Wie baut man eine RAG-Wissensdatenbank für DevOps-Dokumentation auf, damit sie tatsächlich nützlich ist?#

Drei Faktoren haben den größten Einfluss: Aktualität der Dokumente (veraltete Runbooks sind schlimmer als keine, weil der Agent selbstsicher auf Basis falscher Verfahren antwortet), Granularität der Chunks (Unterabschnitte mit einer Prozedur ermöglichen gutes Retrieval, ganze Architekturkapitel liefern schlechte Ergebnisse) und Umgebungsmetadaten (Prozeduren für Staging und Prod unterscheiden sich, der Agent muss wissen, wonach er sucht). Bevor du die gesamte Dokumentation indexierst, teste 20–30 typische On-Call-Fragen.

Wie misst man, ob ein Alert-Triage-Agent tatsächlich hilft?#

Zwei Schlüsselmetriken: Recall von Incidents (wie viele reale Incidents wurden korrekt eskaliert) und die Zeit vom ersten Alert bis zur Bestätigung durch einen Menschen (Mean Time to Acknowledge). Recall misst man retrospektiv durch Vergleich des Triage-Logs mit dem Register bestätigter Incidents. Wenn der Agent häufiger als einmal pro Quartal bei einem Volumen von mehreren hundert Alerts pro Tag einen realen Incident übersieht, muss die Kalibrierung der Schwelle überprüft werden.

Welche Anforderungen stellt der AI Act an DevOps-Agenten mit Zugriff auf Produktionssysteme?#

Systeme für Alert-Triage und interne Dokumentation, die keine direkten Entscheidungen über Menschen beeinflussen, werden grundsätzlich nicht als Hochrisikosysteme gemäß Anhang III des AI Act eingestuft. Ein Agent mit Zugriff auf Infrastruktur-Tools erfordert jedoch Dokumentation: Systembeschreibung, Umfang der Tools, Entscheidungslogs, Mechanismus der menschlichen Aufsicht. Wenn das AI-System in den Bereich kritischer Infrastruktur (Energie, Verkehr, Finanzsektor) fällt, können die Anforderungen strenger sein, und eine DPIA wird fast obligatorisch. Die genaue Abgrenzung sollte mit einem auf Regulierung spezialisierten Anwalt geklärt werden.

Was tun, wenn On-Call-Ingenieure den Empfehlungen des Agenten nicht mehr vertrauen?#

Das ist ein Signal für ein konkretes Problem. Vertrauensverlust hat meist drei Ursachen: Der Agent gab selbstsichere Empfehlungen auf Basis veralteter Dokumentation, der Classifier hatte eine zu niedrige Schwelle und eskalierte zu viel Rauschen, oder ein einzelner schwerwiegender Fehler prägte die Wahrnehmung des gesamten Systems. Bevor man das Modell repariert, sollte man eine Retrospektive der letzten 20–30 Interaktionen durchführen, bei denen das Vertrauen sank. Ein Audit der Agentenqualität beschreibt Monitoring der Qualität von AI-Agenten.