KI-gestützte Störungsbehebung: So triagieren DevOps-Teams Vorfälle schneller

Ein lauter Pager um 2:14 Uhr. Die Checkout-Latenz steigt, die Fehlerquote klettert in die Höhe – und vor Ihnen türmen sich drei Dashboards, endlose Logs und ein müdes Gehirn. Die eigentliche Lösung ist oft schnell gefunden, sobald klar ist, was wirklich schiefgeht. Doch die kostbarste Ressource ist die Zeit: die ersten 15 Minuten der Störungsanalyse.

Genau hier setzt KI an – aber nur, wenn sie gezielt und sicher eingesetzt wird. Denn während KI Muster schneller erkennt als jeder Mensch, darf sie niemals eigenständig kritische Befehle ausführen. Der Schlüssel liegt in einer klaren Trennung: KI analysiert, vorschlägt und fasst zusammen. Die Ausführung bleibt immer in menschlicher Hand.

Warum KI während eines Vorfalls sicher sein muss

KI ist ein Werkzeug – kein Entscheider. In stressigen Situationen, etwa mitten in einem Produktionsvorfall, ist die Versuchung groß, automatisierte Lösungen zu nutzen. Doch genau dann ist größte Vorsicht geboten. Die Faustregel lautet: KI darf lesen, analysieren und Vorschläge machen. Sie darf niemals Befehle ausführen, die die Produktion beeinflussen.

Stellen Sie sich vor, ein übermüdeter Kollege würde neben Ihnen sitzen: Die KI agiert wie ein extrem schneller, gut informierter Junior-SRE, der Daten zusammenfasst, Hypothesen aufstellt und Befehle vorbereitet – aber Sie behalten die Kontrolle. Jeder von der KI vorgeschlagene Befehl wird von Ihnen geprüft, bevor er ausgeführt wird. Diese Regel ist nicht verhandelbar.

Schritt 1: Vom Datenstrom zur klaren Übersicht

KI ist besonders stark darin, große Mengen an Texten zu verarbeiten – selbst um 2 Uhr nachts. Geben Sie ihr die Rohdaten und bitten Sie um eine strukturierte Zusammenfassung, statt sofort nach Lösungen zu fragen:

• Aktive Warnmeldungen (Name, Schweregrad, Labels, Dauer)
• Eine repräsentative Auswahl von Fehlermeldungen
• Die letzten Deployments und Änderungen
• Wichtige Dashboard-Werte (z. B. p99-Latenz, Fehlerquote, Auslastung)

Nutzen Sie eine präzise Eingabeaufforderung wie diese:

Hier sind die Warnmeldungen, Logs und letzten Änderungen für einen aktiven Produktionsvorfall. 
Fasse zusammen, was passiert – in 5 Stichpunkten. Liste die drei wahrscheinlichsten Ursachen 
auf, geordnet nach Wahrscheinlichkeit. Gib zu jeder Ursache einen einzigen lesenden Befehl an, 
der diese bestätigt oder ausschließt. Schlage KEINE Befehle vor, die den Zustand ändern.

Der letzte Satz ist entscheidend: Unkontrollierte KI-Modelle neigen dazu, sofortige Lösungen wie kubectl rollout restart vorzuschlagen. Doch zunächst geht es nur um die Diagnose.

Schritt 2: Befehle nach Risiko klassifizieren und ordnen

Eine gut gestaltete Eingabeaufforderung für KI sollte jede vorgeschlagene Aktion nach Risiko bewerten:

• Sicher: Reine Lesebefehle wie kubectl get, journalctl, ss, ip, cat, grep oder promtool query
• Vorsicht: Befehle mit geringem Einfluss, z. B. kubectl exec, docker exec oder Änderungen an Nicht-Produktionskonfigurationen
• Destruktiv: Befehle, die Neustarts, Löschungen, Skalierung auf null, Firewall-Änderungen oder Migrationen auslösen

Die KI sollte die Befehle in dieser Reihenfolge anordnen – vom sichersten zum riskantesten. So arbeiten Sie strukturiert von oben nach unten und stoppen, sobald die Ursache gefunden ist. Die Zahl der Vorfälle, die sich verschlimmern, weil jemand vorschnell einen destruktiven "Fix" ausprobiert, ist erschreckend hoch. Eine erzwungene Sicherheitsreihenfolge verhindert genau das.

Tipp: Speichern Sie Ihre Standard-Eingabeaufforderung für Vorfälle in einem Snippet-Manager oder einer Prompt-Bibliothek. So müssen Sie sie nicht um 2 Uhr nachts neu formulieren.

Schritt 3: Automatische Korrelation von Änderungen

Die meisten Vorfälle haben eine klare Ursache: eine vorgenommene Änderung. KI ist besonders gut darin, Zeitverläufe abzugleichen – wenn Sie ihr die richtigen Daten geben. Geben Sie ihr folgende Informationen:

• Den genauen Zeitpunkt des Vorfallsbeginns (z. B. 2:09 Uhr UTC)
• Die letzten Deployments
• Änderungen an Konfigurationen
• Infrastruktur-Ereignisse

Fragen Sie die KI dann:

Der Latenz-Anstieg begann um 2:09 UTC. Hier sind die Deployments und Konfigurationsänderungen der letzten 6 Stunden. 
Welche Änderung erfolgte am nächsten zu 2:09, und über welchen Mechanismus könnte sie diese Symptome verursachen?

Hier zeigt sich der wahre Vorteil von KI: Sie bleibt nicht an der offensichtlichen Service-Störung hängen. Stattdessen erkennt sie mögliche Ursachen wie eine geänderte VIP-Konfiguration, eine Anpassung des Connection-Pools oder ein abgelaufenes Zertifikat – also Änderungen, die drei Ebenen tiefer liegen und die ein müder Mensch erst nach 20 Minuten bemerken würde.

Schritt 4: Automatisierte Kommunikationsentwürfe während der Analyse

Kommunikation während eines Vorfalls ist eine zusätzliche Belastung, die Sie in stressigen Momenten nicht brauchen. Überlassen Sie der KI die Erstellung von Entwürfen:

Verfasse eine Statusmeldung für die Kundenseite zum Vorfall mit Checkout-Problemen – ohne Fachjargon, ohne Spekulationen zum Ursprung, in etwa drei Sätzen. 
Dann verfasse eine kurze interne Update für den Incident-Channel mit der aktuellen Schwere und dem, was wir gerade prüfen.

Innerhalb von Sekunden erhalten Sie einen kundengerechten Entwurf und eine kurze interne Meldung – beides in der richtigen Tonlage. Sie müssen nur noch Korrekturen vornehmen und die Texte veröffentlichen. Die eigentliche Analyse läuft weiter.

Schritt 5: Postmortem-Entwürfe aus der Vorfallschronologie

Sobald der Vorfall behoben ist, sind die Erinnerungen noch frisch – und die Motivation, ein Postmortem zu verfassen, am höchsten. Geben Sie der KI die Chronologie aus dem Incident-Channel und die Befehlshistorie und bitten Sie um einen Entwurf für das Postmortem:

• Zusammenfassung
• Zeitachse
• Ursache
• Auswirkungen
• Was gut lief
• Verbesserungspotenziale
• Maßnahmen

Sie editieren einen Entwurf statt vor einem leeren Blatt zu sitzen – der Unterschied zwischen einem geschriebenen und einem nicht geschriebenen Postmortem.

Was Sie unbedingt vermeiden sollten

Einige Fehler sind besonders gefährlich, wenn KI in Vorfallsituationen eingesetzt wird:

• Keine Geheimnisse preisgeben: Scrubben Sie alle Tokens, Passwörter, internen Hostnamen und Kundendaten, bevor Sie Inhalte in ein Modell eingeben. Behandeln Sie den Prompt wie einen versehentlich öffentlich geteilten Screenshot.

• Keine erfundenen Metriken akzeptieren: Wenn Sie PromQL abfragen und Ihre Metriknamen nicht preisgeben, wird die KI sie erfinden. Geben Sie entweder die echten Metriknamen an oder nutzen Sie klar markierte Platzhalter.

• Keiner sicheren Eingabe vertrauen: „Selbstsicher“ und „richtig“ sind bei Sprachmodellen zwei verschiedene Dinge. Die Sicherheitsreihenfolge der Befehle dient genau dazu, falsche, aber selbstsichere Vorschläge zu erkennen und nur lesende Befehle auszuführen.

• Keine „offensichtlichen“ Fixes überspringen: Der vermeintlich offensichtliche Fix um 2 Uhr nachts ist oft der Grund, warum sich ein Vorfall wiederholt.

Integration in Ihren Workflow

Sie benötigen keine spezialisierte Plattform, um heute Nacht loszulegen. Ein gespeicherter Prompt und ein einfacher Textpuffer reichen aus, um den größten Teil des Nutzens zu erzielen. Entscheidend ist die Struktur: Daten zusammenfassen, Hypothesen mit lesenden Befehlen überprüfen, Zeitverläufe korrelieren und Kommunikationen automatisieren.

Denken Sie daran: KI ist ein Werkzeug – kein Ersatz für menschliche Expertise. Sie beschleunigt die Analyse, reduziert Fehlerrisiken und gibt Ihnen mehr Zeit für die eigentliche Lösung. Doch die letzte Entscheidung und die Ausführung bleiben immer bei Ihnen.