Der größte Teil des Werts von "KI für den Betrieb" kommt nicht von Chatbots, sondern von kleinen, sauber abgegrenzten Automatisierungen: einem Workflow, der einen lauten Alert-Sturm in eine dreizeilige Zusammenfassung verwandelt, einem Postmortem-Entwurf, der aus der Incident-Timeline zusammengestellt wird, einer internen Suche, die tatsächlich das richtige Runbook findet. Dieser Artikel beschreibt die Architektur, mit der wir solche Systeme 2026 bauen — n8n für die Orchestrierung, ein Large Language Model für die Sprachaufgaben, Retrieval-Augmented Generation (RAG) über die interne Dokumentation und Guardrails, die das Ganze ehrlich halten.

Beginnen Sie mit dem Workflow, nicht mit dem Modell

Der häufigste Fehler ist, beim Modell anzufangen. Beginnen Sie stattdessen mit der Workflow-Engine. n8n ist eine Source-available-Plattform für Workflow-Automatisierung, die Sie selbst hosten können — das zählt, wenn Ihre Workflows Alert-Payloads, Ticket-Inhalte und interne Dokumentation transportieren. Ein typischer Betriebs-Workflow wird durch einen Webhook vom Alertmanager, eine Nachricht auf einer Queue oder einen Cron-Zeitplan ausgelöst; anschließend reichert er das Ereignis mit deterministischen Schritten an — zuständiges Team nachschlagen, jüngste Deployments abrufen, den passenden Dashboard-Link holen — bevor überhaupt ein Modell ins Spiel kommt.

Halten Sie den LLM-Node als einen Schritt unter vielen, nicht als Zentrum des Designs. Alles, was sich mit einem Lookup, einem Filter oder einem Template erledigen lässt, sollte auch so erledigt werden. Die Error-Workflows und Retry-Einstellungen von n8n fangen transiente Fehler ab; der Credential-Store hält API-Keys aus den Workflow-Definitionen heraus. Das Ergebnis ist eine Pipeline, in der das Modell nur das tut, was nur ein Modell kann: unordentlichen Text lesen und nützlichen Text produzieren.

Wo LLMs im Betrieb wirklich helfen

Alert-Stürme zusammenfassen

Wenn eine gemeinsam genutzte Abhängigkeit ausfällt, erhalten die Bereitschaftsingenieure vierzig Alerts, die ein einziges Problem beschreiben. Gruppieren und deduplizieren Sie die Alerts zuerst deterministisch — nach Cluster, Service und Label — und übergeben Sie den gruppierten Payload dann mit einem eng gefassten Prompt an das Modell. Ein Prompt, der sich bei uns als System-Message-Schritt in n8n bewährt hat:

# System-Prompt für den Alert-Summary-Node in n8n
You are an SRE assistant. Summarize the following Alertmanager
payload in three lines: what is failing, the probable blast
radius, and the first diagnostic step from the linked runbook.
Do not invent metrics or services. If information is missing,
say so explicitly.

{{ $json.alerts }}

Die Einschränkungen zählen mehr als die Anweisungen. "Do not invent metrics" und "say so explicitly" sind es, die die Zusammenfassung um 3 Uhr morgens vertrauenswürdig halten.

Runbooks und Postmortems entwerfen

Modelle sind gut in Erstentwürfen von Dokumenten, die niemand schreiben möchte. Geben Sie die Incident-Timeline, das Chat-Transkript und die relevanten Dashboards in einen Entwurfs-Workflow, und Sie erhalten in Minuten ein Postmortem-Gerüst statt nach einer Woche ein leeres Blatt. Dasselbe gilt für Runbooks: Erzeugen Sie einen Entwurf aus Shell-History und Monitoring-Queries und lassen Sie ihn dann von dem Ingenieur korrigieren, der den Vorfall tatsächlich bearbeitet hat. Menschliche Prüfung ist hier nicht optional — der Entwurf ist ein Ausgangspunkt, niemals das veröffentlichte Artefakt. Wenn Sie noch abwägen, welche Modellfamilie zu welcher dieser Aufgaben passt, behandelt unser Vergleich welche KI wofür besser ist die Trade-offs.

RAG über interne Dokumentation

Retrieval-Augmented Generation ist das, was einen Betriebsassistenten für Ihre Umgebung nützlich macht statt für den Durchschnitt des Internets. Die Pipeline ist unspektakulär: Runbooks, ADRs und Wiki-Seiten in Chunks aufteilen, einbetten, die Vektoren speichern und zur Abfragezeit die relevantesten Chunks abrufen und zusammen mit der Frage in den Kontext des Modells legen.

Drei Regeln halten RAG in der Produktion ehrlich. Erstens: Zitate verpflichtend machen — jede Antwort muss auf das Quelldokument verweisen, damit ein Ingenieur vor dem Handeln verifizieren kann. Zweitens: bei Änderungen neu indexieren. Ein RAG-System, das das Runbook vom letzten Quartal ausliefert, ist schlimmer als gar kein System, weil es selbstbewusst und falsch antwortet. Verdrahten Sie die Neuindexierung mit derselben Pipeline, die die Dokumentation veröffentlicht. Drittens: Zugriffskontrolle auf der Retrieval-Ebene durchsetzen, nicht im Prompt — wenn ein Nutzer ein Dokument nicht lesen darf, darf der Retriever keine Chunks daraus zurückgeben.

Guardrails und Evaluation

Ein LLM in einem Ops-Workflow sollte standardmäßig read-only sein. Zusammenfassungen, Entwürfe und Vorschläge sind sichere Fehlermodi; das Neustarten von Services ist es nicht. Wo ein Workflow doch Aktionen ausführt, setzen Sie ein menschliches Freigabe-Gate davor — n8n unterstützt Wait-for-Approval-Schritte nativ — und beschränken Sie den Aktionsraum auf eine explizite Allowlist.

Die Evaluation ist der Teil, den die meisten Teams überspringen. Bauen Sie ein kleines Test-Set aus echten vergangenen Vorfällen: Alert-Payloads mit bekannt guten Zusammenfassungen, Fragen mit bekannt korrekten Runbook-Antworten. Führen Sie es immer dann aus, wenn Sie einen Prompt, ein Modell oder die Retrieval-Konfiguration ändern. Behandeln Sie Prompts wie Code — versioniert, reviewt und per Rollback zurückgenommen, wenn eine Änderung das Eval-Set verschlechtert. Loggen Sie jeden Prompt und jede Antwort; wenn jemand fragt, warum der Assistent gesagt hat, was er gesagt hat, ist "wir wissen es nicht" im Betrieb keine akzeptable Antwort.

Kosten im Griff behalten

Token-Kosten summieren sich in Always-on-Workflows leise. Die Hebel, geordnet nach Wirkung: Rufen Sie kein Modell auf, wenn ein Skript genügt — Klassifikation und Routing sind oft ein Regex oder eine Lookup-Tabelle; nutzen Sie ein kleines, günstiges Modell für die Triage und reservieren Sie das große Modell für die Schritte, deren Qualität für Menschen sichtbar ist; begrenzen Sie die Output-Tokens pro Aufruf und cachen Sie wiederholten Kontext wie System-Prompts; und verarbeiten Sie nicht dringende Arbeit im Batch statt Ereignis für Ereignis. Messen Sie die Kosten pro Workflow, nicht pro API-Key — eine einzige außer Kontrolle geratene Summarization-Schleife kann die Rechnung dominieren, und Sie wollen sie als eigene Position sehen. Ihr Observability-Stack sollte Modellausgaben wie jedes andere Signal behandeln; unsere Übersicht der besten Monitoring-Tools behandelt die Prometheus- und Grafana-Grundlagen, an die das andockt.

Nichts davon ist spekulativ — es ist dieselbe Disziplin wie bei jedem anderen Produktionssystem, angewendet auf eine neue Komponente, die zufällig Englisch spricht. Wenn Sie Unterstützung beim Design von Alert-Zusammenfassungen, RAG über Ihre Dokumentation oder LLM-Guardrails für Ihre Umgebung wünschen: Unser AIOps-Solutions-Team baut genau diese Pipelines.

Sie wollen das in Produktion betreiben? Unser AWS-Managed-Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab 3.000 €/Monat.

Tags: #AIOps #n8n #LLM #RAG #Automatisierung