Agentische KI: So entwickeln Sie produktionsfähige AIOps mit Open Source-Modellen

In vielen Fällen bedeutet der Einsatz agentischer KI zur Automatisierung von Reaktionen auf Vorfälle, dass Infrastrukturprotokolle an Frontier-KI-Modelle gesendet werden. Jedes Fehlerprotokoll eines Jobs (einschließlich Hostnamen, IP-Adressen und Systemtopologie) würde die Infrastruktur verlassen, sobald es einen Large Language Model (LLM)-Endpunkt erreicht. Dies würde bei Compliance-Teams in stark regulierten Branchen wie dem Finanz- und Gesundheitswesen erhebliche Bedenken hervorrufen.

Alternativ könnten diese Unternehmen Open Source-Modelle nutzen, die auf der eigenen Infrastruktur gehostet werden, um Probleme bei Datenresidenz und Compliance zu lösen. Aber sind Open Source-KI-Modelle gut genug, um massive Frontier-Modelle bei strukturierten operativen Aufgaben zu ersetzen? Wir sind davon überzeugt. Kombiniert man Open Source-Modelle mit den passenden Architekturmustern (agentische Harnesses, fokussierte Skills, Kontextisolierung), liefern sie Analysen in Frontier-Qualität zu einem Bruchteil der Kosten.

Hier starten wir Teil 1 unserer 3-teiligen Reihe, in der Sie erfahren, wie Sie produktionsfähige agentische AIOps mit Open Source-Modellen erstellen und skalieren. Wir zeigen auf, warum Open Source für diese Herausforderung bereit ist, wie Red Hat OpenShift AI die täglichen Abläufe vereinfacht und wie eine kompetenzbasierte Architektur das mühsame Nachtrainieren von Modellen überflüssig macht.

Die Herausforderung: Wenn Abläufe schneller skalieren als Teams

Bevor wir über Lösungen sprechen, betrachten wir die operative Realität, die Unternehmen zu einer KI-gestützten Reaktion auf Sicherheitsvorfälle bewegt.

Das geschäftliche Problem

Für unseren beispielhaften Use-Case betrachten wir ein Finanzdienstleistungsunternehmen mit Sitz im Vereinigten Königreich, das eine hybride Infrastruktur betreibt: 140 lokale virtuelle Maschinen (VMs) mit Red Hat Enterprise Linux (RHEL) und 3 Red Hat OpenShift-Cluster. Das Unternehmen führt pro Woche mehr als 600 Jobs auf Red Hat Ansible Automation Platform für Provisionierung, Patching, Compliance-Scans und die Korrektur von Konfigurationsdrift aus.

Schlagen Jobs fehl, geht ein Ticket im Ticketing-System ein und eine Benachrichtigung wird im ChatOps-Channel ausgelöst. Das klingt überschaubar – abgesehen davon, dass pro Woche etwa 40 Fehlertickets anfallen. Jedes Ticket erfordert manuelle Triage, Untersuchung und anschließende Problembehebung oder Eskalation.

Zeitaufwand: 45 – 90 Minuten Arbeitszeit von Site Reliability Engineers (SREs) pro Ticket, je nach Komplexität.

Herausforderung bei der Skalierung: Rechnen Sie dies auf das gesamte Team hoch und beziehen Sie Ausfälle über Nacht sowie Rufbereitschaften ein, ergibt sich ein systemisches Problem. Das Unternehmen möchte das Zehnfache der aktuellen Infrastruktur bewältigen, ohne die Mitarbeiterzahl zu verzehnfachen.

Regulatorischer Druck: Als Finanzdienstleister unterliegt das Unternehmen strengen Vorgaben für Change Management und Incident Response. Jeder ungeplante Ausfall und jeder Konfigurationsdrift muss innerhalb definierter SLA-Zeitfenster dokumentiert werden (Ursache, Maßnahmen zur Problembehebung, verantwortliche Partei). Das Verpassen dieser Fristen zieht behördliche Strafen nach sich.

Die Aufsichtsbehörde beanstandete im ersten Quartal 3 SLA-Verletzungen. Jede davon ging auf einen fehlgeschlagenen Job in Ansible Automation Platform zurück, der zu lange unbearbeitet blieb. Die Anweisung war eindeutig: „Wir müssen den Kreislauf schneller schließen und benötigen Prüfnachweise dafür.“

Aktuelle Problembereiche:

• Alarmmüdigkeit: 40 Fehlertickets pro Woche, von denen viele bekannten Mustern folgen. Rufbereitschaftsteams sind überlastet, die Reaktionszeiten lang.
• Wissensfragmentierung: Runbooks und Fachwissen sind über Confluence und einzelne Mitarbeitende verstreut. Die Lösungsqualität ist uneinheitlich.
• Audit-Overhead: Manuelle Vorfallsberichte für die Compliance nehmen 2 bis 3 Stunden pro schwerem Vorfall in Anspruch. Häufig werden sie nachträglich aus dem Gedächtnis und aus Chat-Protokollen erstellt.
• Eskalationslücke: binäre Entscheidung zwischen „selbst reparieren“ und „jemanden aufwecken“ ohne abgestufte, proportionale Reaktionsmechanismen.
• Skalierungsgrenze: Das aktuelle Team kann das prognostizierte Wachstum nicht bewältigen. Die Einstellung weiterer SREs ist wirtschaftlich nicht tragfähig und löst die Fragmentierung des Wissens nicht.

Die Chance: Agentische KI kann die Triage, Untersuchung und Maßnahmen übernehmen (mit vollständigem Audit-Trail) und gleichzeitig Menschen bei risikoreichen Änderungen einbinden.

Prognostizierte Ergebnisse bei Erfolg:

• Reduzierung der Mean Time to Resolution (MTTR): von durchschnittlich 45 Minuten auf angestrebte 12 Minuten bei bekannten Fehlermustern.
• Audit-Effizienz: Automatisch generierte Vorfallsberichte: Das Compliance-Team prüft diese, anstatt sie von Grund auf neu zu erstellen.
• Skalierbarkeit: Bewältigung des 10-fachen Ticketvolumens ohne proportionalen Personalaufbau.
• Wissenserfassung: Agentenmuster bündeln Runbook-Wissen in einer sich selbst optimierenden Wissensdatenbank für den operativen Betrieb.
• Kostenkontrolle: Open Source-Modelle auf eigener Infrastruktur im Vergleich zur Abrechnung pro Token bei externen Anbietern.

Die technische Herausforderung für SREs

Aus Sicht der SREs steht die operative Geschwindigkeit im Konflikt mit der operativen Sicherheit.

Volumen und Vielfalt: Fehler erstrecken sich über mehrere Domänen. Fehler in Ansible Playbooks, Probleme bei der Linux-Paketverwaltung, Probleme im Lifecycle von OpenShift-Pods sowie Netzwerk- und DNS-/SSH-Fehler. Ein einzelner Agent kann nicht in allen Bereichen Fachwissen besitzen.

Kontextanforderungen: Eine fundierte Vorfallsanalyse erfordert institutionelles Wissen. Wenn eine Paketinstallation mit „No package python3.14 available“ fehlschlägt, lautet die Standardantwort: „Prüfen Sie Ihre Repository-Konfiguration.“ Die unternehmensspezifische Antwort berücksichtigt dagegen:

• Ihre Satellite-Server-Topologie (primär, Disaster Recovery, Synchronisierungszeitplan)
• Ihr Content View-Modell pro Team (welche Teams welche Repositories erhalten)
• Ihren Eskalationsprozess (Referenz auf Standard Operating Procedures (SOP), Fast-Track-Channel in Slack)
• Ob das Paket für Ihre Version des Betriebssystems überhaupt existiert

Allgemeine Fehlerbehebung kostet unnötig Zeit. Kontextbezogene Analysen führen schneller zur Lösung.

Compliance-Vorgaben: In regulierten Umgebungen muss jede Maßnahme nachvollziehbar sein. Ein KI-Agent, der ohne Protokollierung agiert, stellt ein Compliance-Risiko dar. Ein Agent, der sämtliche Vorgänge protokolliert (Klassifizierungsbegründung, Expertenanalyse, Konfidenzwerte, Urteile von Prüfenden), wird zu einem Compliance-Vorteil.

Prüfende der Finanzaufsichtsbehörde kontrollieren regelmäßig Aufzeichnungen zu Change Management und Incident Response. Das Versäumen eines SLA-Zeitfensters bedeutet nicht nur eine verzögerte Problembehebung – es zieht behördliche Strafen und verpflichtende Berichte zur Fehlerbehebung nach sich. Heute werden diese Berichte manuell verfasst (2 bis 3 Stunden pro schwerem Vorfall, oft nachträglich rekonstruiert).

Anforderungen an die Datensouveränität: Jeder API-Aufruf an ein Frontier-Modell übermittelt Ihre Daten an externe Stellen:

{
  "job_id": "3847",
  "host": "rhel-node-01.meridian.internal",
  "error": "fatal: [rhel-node-01]: FAILED! => {\"msg\": \"No package python3.14 available\"}",
  "playbook": "/var/lib/awx/projects/ansible-plays/install-python.yml",
  "credential": "meridian-satellite-sync"
}

Diese Payload legt Folgendes offen:

• Interne DNS-Topologie (meridian.internal)
• Namenskonventionen der Infrastruktur
• Credential-IDs (meridian-satellite-sync)
• Details zur Systemkonfiguration

In regulierten Umgebungen unterliegt dies der DSGVO (Artikel 44 bis 49 über internationale Datenübermittlungen) und dem DORA (Digital Operational Resilience Act), wodurch ein reales Risiko für die Datenresidenz entsteht.

Operative Anforderungen: Das System muss:

• Fehler präzise einstufen und klassifizieren (Weiterleitung an die passenden Fachleute)
• Bereichsspezifische Ursachenanalysen durchführen (keine allgemeine Fehlerbehebung)
• Auditfähige Vorfallsberichte generieren (compliance-konforme Ausgabe)
• Abgestufte Autonomie unterstützen (Human-in-the-Loop bei hohem Risiko, autonom bei Routineaufgaben)
• Das 10-fache Volumen ohne Leistungseinbußen bewältigen
• Schnelle Wissensaktualisierungen ermöglichen (neue SOPs, Infrastrukturänderungen) ohne erneutes Modelltraining

Das Problem der Datensouveränität

63 % der Großunternehmen in der EMEA-Region nennen Bedenken hinsichtlich der Souveränität als größte Hürde für die Cloud-Einführung. Für KI-Workloads, die Betriebsdaten verarbeiten, steht noch mehr auf dem Spiel.

Red Hat ist davon überzeugt, dass Open Source das Fundament souveräner KI ist. Offene Modelle auf Red Hat OpenShift AI geben Ihnen die Kontrolle. Sie bestimmen, wo die Inferenz ausgeführt wird, Ihre Daten verlassen die Plattform nie, und Sie behalten die vollständige Auditierbarkeit der KI-Lieferkette.

Das ist kein Nischenthema. Mehr als zwei Drittel der Unternehmen in EMEA haben Datensouveränität als Top-Priorität für die IT in den nächsten 18 Monaten eingestuft. Für Finanzdienstleistungsunternehmen birgt das Senden von Job-Ausgaben an externe LLM-Anbieter regulatorische Risiken, die Compliance-Teams nicht mittragen können.

Die Leistungslücke schließt sich

Vor 2 Jahren bedeutete die Entscheidung für ein Open Source-Modell noch, eine erhebliche Leistungslücke in Kauf zu nehmen. Ein offenes Modell mit 7B Parametern neigte zu Halluzinationen. Ein Modell mit 70B Parametern tat sich bei komplexem Reasoning schwer. Frontier-Modelle waren die einzige praxistaugliche Wahl für den Produktiveinsatz.

Das gilt nicht mehr, da mittlerweile deutlich größere Open Source-Modelle (230B und mehr) zur Verfügung stehen.

Die agentische Revolution hat das Blatt gewendet

Der Aufstieg der agentischen KI (Frameworks wie Deep Agents von LangChain, das Claude Agent SDK von Anthropic und maßgeschneiderte Harnesses) hat unsere Sicht auf Modellfähigkeiten grundlegend verändert. Ein agentischer Harness sendet nicht bloß einen Prompt und hofft auf Ergebnisse. Stattdessen erfüllt er folgende Aufgaben:

• Verwaltet Kontextfenster und behält nur relevante Informationen im Fokus.
• Delegiert an Spezialisten und erzeugt fokussierte Sub-Agenten für spezifische Domänen.
• Stellt strukturierte Skills bereit und lädt Referenzwissen im Markdown-Format.
• Analysiert und validiert Ausgaben und liefert strukturierte, handlungsrelevante Ergebnisse.

Dieser strukturierte Ansatz kann helfen, die Leistungslücke zwischen Open Source- und Frontier-Modellen zu schließen. Ein gut konzipierter Harness ermöglicht es mittelgroßen Open Source-Modellen, bei einer konkreten Aufgabe hervorragende Ergebnisse zu erzielen.

Beispiel: Fehleranalyse bei der Paketverwaltung

Hier ist ein direkter Vergleich aus unserer produktiven AIOps-Pipeline. Derselbe Fehler, 2 verschiedene Modelle:

Frontier-Modell (claude-sonnet-4-6):

Ursache: DNF-Paketmanager meldet "No package python3.14 available" 
Empfohlene Maßnahme:  
1. Überprüfen, ob der Paketname korrekt ist 
2. Repository-Konfiguration überprüfen 
3. Verwendung von EPEL oder Aktivierung zusätzlicher Repositories in Betracht ziehen 
Konfidenz: 85%

Open Source-Modell (qwen3-235b auf MaaS):

Ursache: DNF-Paketmanager meldet "No package python3.14 available"  
Analyse: Python 3.14 erfordert CRB- (CodeReady Builder) und EPEL-Repositories. 
Ziel-Hostgruppe deutet auf Workload des KI/ML-Teams hin. 
Empfohlene Maßnahme: 
1. Content View Request gemäß SOP v2.3 einreichen 
2. CRB- + EPEL-Aktivierung für Content View "aiml-workloads" anfordern 
3. Eskalation über Fast-Track #platform-satellite (2-hour SLA) 
Konfidenz: 92%

Das Open Source-Modell erzielte ein besseres Ergebnis durch die Nutzung eines KI-Skills (bereitgestellt als Markdown-Dokument, das internes Wissen über unsere Satellite-Infrastruktur, das Content View-Modell und Eskalationspfade enthält). Das Modell musste dies nicht erst aus Trainingsdaten lernen. Wir haben ihm die Antwort direkt als Kontext mitgegeben.

Skills übernehmen die Hauptarbeit

So sah dieser Skill aus:

---

name: analyze-package-management-failure

description: Package management failure analysis with institutional knowledge

--- 
# Analyse von Fehlern in der Paketverwaltung 
## Institutionelles Wissen: Satellite-Infrastruktur 
**Content-View-Modell (pro Team):** 
- base-rhel9: Alle RHEL-Server, nur grundlegende OS-Pakete
- ops-tooling: SRE-Team, Monitoring, Diagnose-Tools 
- aiml-workloads: KI/ML-Team, Python 3.11+, CUDA, Data-Science-Bibliotheken (CRB + EPEL) 
**Eskalationspfad:** 
- Standard: Content View Request SOP v2.3 
- Fast-Track: Kanal #platform-satellite (2-hour SLA for AI/ML workloads)

Das Modell diente als Reasoning-Engine. Der Skill lieferte das institutionelle Wissen. Gemeinsam lieferten sie Analysen, die Frontier-Qualität übertrafen, weil wir unseren spezifischen operativen Kontext integriert haben.

Die Kostenrechnung

Die Kosten für Frontier-Modelle steigen im operativen Umfeld schnell stark an:

• Abrechnung pro Token: Jede Vorfallsanalyse umfasst mehrere LLM-Aufrufe (Klassifizierung, spezialisiertes Reasoning, Prüfung).
• Volumenskalierung: Bei mehr als 40 Ausfällen pro Woche werden Token-Kosten zu einem erheblichen Kostenfaktor.
• Keine Kostendeckelung: Nutzungsspitzen bei Zwischenfällen führen zu unberechenbaren Rechnungen.

Open Source-Modelle auf eigener Infrastruktur verursachen feste Rechenkosten:

Kostenmodell für Frontier-Modelle: 
- 15 USD pro 1 Million Input-Token 
- 75 USD pro 1 Million Output-Token 
- Durchschnittlicher Vorfall: ~50.000 Token (Klassifizierung + Analyse + Prüfung) 
- 40 Vorfälle/Woche × 52 Wochen = 2.080 Vorfälle/Jahr 
- Jährliche Kosten: ~7.800 USD allein für LLM-API-Gebühren 
Kostenmodell für Open Source-Modelle: 
- Feste GPU-Infrastruktur (Nvidia A100 oder H100) 
- Red Hat OpenShift AI-Subskription 
- Keine Abrechnung pro Token 
- Vorhersehbare jährliche Kosten unabhängig vom Vorfallsvolumen

Wenn Sie Hunderte von Vorfällen pro Woche bearbeiten, verlagert sich die Wirtschaftlichkeit eindeutig zugunsten von Open Source.

Red Hat OpenShift AI Model as a Service (MaaS)

Red Hat OpenShift AI bietet Model as a Service (MaaS), ein Portfolio an Open Source-Modellen, die auf OpenShift mit vLLM-Inferenzbeschleunigung auf verschiedenen GPUs laufen.

Hier sind Beispiele für Modelle, die mit MaaS verfügbar sind:

In der Produktion setzen Sie nicht bloß ein einzelnes Modell ein. Sie können Modelle je nach Agent kombinieren:

• ops_manager (Orchestrator): qwen3-235b (benötigt starke Klassifizierung und Delegation)
• sre_linux (Spezialist): gpt-oss-120b (fokussierte Domäne, strukturierte Ausgabe)
• reviewer (Validator): gpt-oss-20b (einfache Kohärenzprüfung)

Dieser mehrschichtige Ansatz optimiert die Kosten und wahrt gleichzeitig die Qualität. Ihr Triage-Agent benötigt keine 235B Parameter, um zu prüfen, ob ein Protokoll „No package X available“ enthält.

Die Architektur: Agenten der 2. Generation

Open Source-Modelle eignen sich für komplexe operative Aufgaben vor allem durch den Harness – jenes Framework, das das LLM einbettet und ansteuert, anstatt es unbeaufsichtigt agieren zu lassen.

Agenten der 1. versus 2. Generation

Agenten der 1. Generation (klassisches ReAct-Muster) stoßen bei mehrstufigen Abläufen an Grenzen:

• Kontext auf den bisherigen Gesprächsverlauf begrenzt
• Performance sinkt nach etwa 50 Tool-Aufrufen ab („Dumb Zone“)
• Kein persistenter Status außerhalb des Chats
• Jede Aufgabe teilt sich ein einziges Kontextfenster

Agenten der 2. Generation (Deep Agents, Claude Agent SDK) stützen sich auf 4 architektonische Säulen:

1. Explizite Planung (To-do-Listen als persistente Kontextanker)
2. Persistentes Dateisystem (virtueller Workspace für Notizen und strukturierte Artefakte)
3. Erzeugung von Sub-Agenten (Delegation an Spezialisten mit bereinigtem Kontext)
4. Kontextisolierung (jeder Spezialist sieht nur die benötigten Informationen)

Beispiel: Incident-Response-Pipeline

Unsere AIOps-Pipeline setzt auf das Muster der Deep Agents:

ops_manager (langlebiger Deep Agent)   
├── Empfängt Webhook bei AAP2-Job-Fehlern   
├── Klassifiziert die Fehlerdomäne (ansible/linux/openshift/networking)   
├── Startet temporären Spezialisten-Sub-Agenten   
│   └── sre_linux (frischer Kontext)   
│       ├── Lädt Skills: analyze-linux-failure, create-ticket, common   
│       ├── Analysiert Vorfalldaten   
│       └── Gibt strukturierten TicketPayload zurück   
├── Startet temporären Reviewer-Sub-Agenten   
│   └── reviewer (validiert Ticketkohärenz)   
└── Reicht Ticket bei Jira ein + benachrichtigt Rocket.Chat

Jeder sre_*-Sub-Agent ist temporär (wird nach Bedarf erstellt und nach der Nutzung verworfen). Das bedeutet:

• Kontextisolierung: Ein Paketfehler beeinflusst nicht den Kontext eines SSH-Fehlers
• Fokussiertes Fachwissen: Jeder Agent lädt nur seine domänenspezifischen Skills
• Sauberer Ausgangszustand: Jede Analyse startet neu, ohne angesammelte Historie

Ein Open Source-Modell mit 235B Parametern eignet sich hervorragend für die konkrete Aufgabe, da es sich nicht an 50 vorherige Vorfälle „erinnern“ muss. Es muss lediglich den vorliegenden Fall analysieren – mit genau den passenden geladenen Skills.

Datensouveränität + Kosten + Qualität = produktionsreif

3 Faktoren machen Open Source-Modelle bereit für den Produktiveinsatz bei agentischen Workloads:

1. Datensouveränität: Ihre Protokolle verbleiben in Ihrer Infrastruktur (kein Risiko bezüglich DSGVO/DORA)
2. Kosten: feste Infrastrukturkosten statt unvorhersehbarer Abrechnung pro Token
3. Qualität: Agentische Harnesses kombiniert mit Skills liefern Ergebnisse auf Frontier-Niveau

Wir setzen dies seit 6 Monaten produktiv ein und bearbeiten pro Woche mehr als 40 Infrastrukturvorfälle. Unsere MTTR sank bei bekannten Fehlermustern von 45 Minuten auf 12 Minuten. Unser Compliance-Team ist mit dem Audit-Trail zufrieden. Unsere Infrastrukturkosten sind kalkulierbar.

Das Open Source-Modell übernimmt:

• Fehler in Ansible Playbooks und Probleme mit Zugangsdaten
• Linux-Paketverwaltung und systemd-Fehler
• Probleme beim Lifecycle von OpenShift-Pods und bei der rollenbasierten Zugriffskontrolle (Role-based Access Control, RBAC)
• DNS- und Konnektivitätsprobleme im Netzwerk

Gleiche Pipeline. Gleiche Skills. Dieselben Prompts. Anderes Modell. Und es funktioniert.

Probieren Sie es selbst aus

Möchten Sie praktische Erfahrung beim Aufbau einer agentischen AIOps-Pipeline mit Open Source-Modellen sammeln? Testen Sie den vollständigen Workshop, indem Sie sich an Ihr Red Hat Vertriebsteam wenden.

Ressourcen

• Red Hat OpenShift AI
• LangChain Deep Agents
• Open Source als Fundament souveräner KI
• Herausforderungen im Bereich der Souveränität für Unternehmen in der EMEA-Region

Über diesen Artikel: Dieser Beitrag basiert auf einem praxisorientierten Workshop, der für Demos im Außendienst von Red Hat entwickelt wurde. Die beschriebenen Methoden laufen in produktiven SRE-Umgebungen und verarbeiten reale Infrastrukturvorfälle. Wenden Sie sich an Ihr Red Hat Vertriebsteam, um das vollständige Lab auszuprobieren.