AI für SRE: Warum Automatisierung das Ziel ist und KI nur ein Werkzeug

Das Schlagwort „AI SRE“ suggeriert, dass künstliche Intelligenz künftig die Menschen im Site Reliability Engineering ersetzt. Genau daran stört sich Severin Neumann, Head of Community bei Bronto und Mitglied des OpenTelemetry Governance Committee. In seinem Vortrag „AI für SRE richtig einsetzen: Von klassischer Automation bis LLMs“ bei der Mastering Observability im April 2026 plädiert er für eine andere Sichtweise: KI ist nicht das Ziel, sondern eines von vielen Werkzeugen, um Reliability-Arbeit schrittweise zu automatisieren.

Neumann bevorzugt daher die Formulierung „AI for SRE“ – also KI für SRE statt SRE. Die Unterscheidung ist mehr als Wortklauberei. Sie verweist darauf, dass Site Reliability Engineering weit mehr umfasst als die Reaktion auf Störungen. Zu SRE gehören Instrumentierung, Kapazitätsplanung, die Prävention von Vorfällen, in Code gegossene Resilienz durch Timeouts, Retries oder Circuit Breaker, Post-Mortems und kontinuierliche Verbesserung. Incident Response ist in dieser Lesart der letzte Ausweg, nicht der Kern der Disziplin.

Wichtig ist Neumann eine zweite Klarstellung: KI ist nicht gleich Large Language Model. LLMs seien nur eine Teilmenge dessen, was unter künstliche Intelligenz fällt – und sie bringen erhebliche Grenzen mit. Halluzinationen, fehlendes Kausalverständnis, begrenzte Kontextfenster, mangelndes Echtzeit-Bewusstsein, fehlende Reproduzierbarkeit von Antworten, die Abhängigkeit von der Prompt-Qualität und die hohen Kosten für Inferenz und GPU-Rechenzeit sprechen dagegen, LLMs als Universalwerkzeug für jedes Problem zu nutzen. Daneben stünden klassische Machine-Learning-Modelle für Anomalieerkennung, Trendanalyse und Forecasting sowie deterministische Automatisierung durch Regeln, Linter, Operatoren und Runbooks. Die Leitfrage laute deshalb nicht „Wo können wir ein LLM einsetzen?“, sondern „Welches Werkzeug passt hier?“.

Um diese Frage systematisch zu beantworten, entsteht innerhalb der CNCF TAG Operational Resilience ein Referenzmodell mit dem Titel „Levels of Service Reliability Automation“. In einem CNCF-Blog beschreibt Mario Fahlandt, ehemaliger Leiter der TAG, das Whitepaper als Versuch, operative Autonomie von reaktivem Firefighting bis hin zu selbstheilenden Systemen abzubilden. Das Framework soll Teams eine gemeinsame Landkarte an die Hand geben, die zeigt, wie Reliability-Arbeit über alle Domänen hinweg vom rein manuellen Vorgehen zu wachsender Autonomie fortschreiten kann.

Eine Matrix statt eines Organisationslevels

Das Modell ist als zweidimensionale Matrix aufgebaut. Die horizontale Achse beschreibt den Automatisierungsgrad in fünf Stufen: Manual, Automatic, Assisted, Guided und Autonomous. Auf der vertikalen Achse stehen die Reliability-Aktivitäten – Instrumentation, Reliability Implementation, Incident Prevention beziehungsweise Risk Prevention sowie Incident Response. In den einzelnen Zellen werden konkrete Werkzeuge, Anforderungen und Fähigkeiten je Aktivität und Level beschrieben.

Darin unterscheidet sich der Ansatz von klassischen Reifegradmodellen, wie sie aus SRE- oder Observability-Frameworks bekannt sind. Statt eine ganze Organisation einem Level wie „Initial“ oder „Optimizing“ zuzuordnen, kartiert das Modell jede Aktivität einzeln. Ein Team kann bei der Instrumentierung noch komplett manuell arbeiten, bei der Incident Response aber bereits auf der Stufe Guided sein. Das bildet die Praxis realistischer ab, weil Teams in verschiedenen Bereichen unterschiedlich weit sind. Der Fokus liegt dabei explizit auf operativer Autonomie – ähnlich den SAE-Levels des autonomen Fahrens, übertragen auf Reliability-Arbeit.

Am Beispiel der Instrumentierung wird die Spannweite deutlich. Auf der Stufe Manual binden Entwicklerinnen und Entwickler Telemetrie selbst über die OpenTelemetry-SDKs ein und annotieren Spans, Metriken und Logs von Hand. Automatic bedeutet automatische Injektoren über Agents oder Sidecars. Auf der Stufe Assisted schlagen Tools fehlende Spans oder Metriken vor, während der Mensch entscheidet. Guided umfasst KI-gestützte Skills, die während Code-Reviews auf fehlende Trace-Kontexte oder unvollständige Semantic Conventions hinweisen. Auf der Stufe Autonomous bringen Systeme Telemetrie selbstständig an oder ändern sie – etwa durch dynamische Instrumentierung anhand von Laufzeitsignalen.

Ähnlich verhält es sich bei der Reliability Implementation, also den Schutzmechanismen im Code. Manuell designen Entwicklerinnen jedes Timeout, jeden Retry und jeden Circuit Breaker selbst. Regelbasierte Linter prüfen automatisch, ob HTTP-Calls überhaupt ein Timeout besitzen. Service-Mesh-Sidecars erzwingen Standard-Patterns global per Policy. Auf höheren Stufen schlagen Tools Retry-Strategien anhand von Traffic-Analysen vor, und LLM-basierte Code-Reviews identifizieren fehlende Timeouts, unbehandelte Promise Rejections oder Retry-Schleifen ohne Jitter.

Prävention vor Reaktion – und die Sache mit dem Alert Noise

Zentral ist für Neumann die Trennung von Prävention und Reaktion. Prävention bedeutet, ein Risiko zu erkennen, bevor Nutzer betroffen sind; bei der Response sind sie es bereits. Den Beginn eines Vorfalls zu erkennen, sei schwer – das Risiko vorher zu erkennen, noch schwerer. Daraus folgt eine klare Ansage: Ohne funktionierende Risiko-Prävention könnten „AI SREs“ nur assistieren und begleiten, aber nie die höchste Automatisierungsstufe erreichen. Hohe Autonomie in der Incident Response ohne starke Prävention führe lediglich zu effizienterem, aber nicht nachhaltigeren KI-Firefighting.

Auf die Frage, ob es also gutes Alerting brauche, antwortet Neumann mit einem gedehnten „Ja – naja…“. Sein Kritikpunkt: Alerting werde oft mit Detection vermischt, sodass alles gemeldet wird, was erkannt wird. Das Ergebnis ist Alert Noise. LLMs als Alert-Prozessoren lösen dieses Problem nicht, sondern erhöhen die Komplexität – schon die Auswertung von viel Alert Noise ist teuer, und es stellt sich die Frage, welche Alerts überhaupt in den Prompt gelangen: alle, aggregierte oder gefilterte.

Neumann fordert stattdessen gute Telemetrie mit niedrigem Rauschanteil und fortgeschrittene ML-Methoden jenseits reiner LLMs für Detection und Klassifikation. Eine Schlüsselrolle spielen dabei Semantic Conventions, wie sie OpenTelemetry definiert: Einheitliche Daten senken die Verarbeitungskosten, verbessern die Signalqualität und erhöhen das Verständnis – für Menschen wie für KI-Systeme. Für eine autonome Incident Response und Prävention brauche es solide Telemetrie und gute Erkennung. Neumann lädt ausdrücklich zur Mitarbeit am CNCF-Whitepaper ein.

Wenn KI ohne Telemetrie mehr schadet als nützt

Wie berechtigt diese Vorsicht ist, zeigen typische Fehlerbilder aus dem AIOps-Umfeld. Ein häufiges Muster: Ein KI-basiertes Event-Correlation-Tool gruppiert Alerts nach Ähnlichkeit und unterdrückt vermeintliche Duplikate. Ist die Telemetrie uneinheitlich und die historische Alert-Historie mit False Positives durchsetzt, lernt das Modell, bestimmte Muster zu ignorieren. Beginnt ein neuer Vorfall mit einem ähnlichen Muster, werden relevante Alerts unterdrückt – die mittlere Reparaturzeit steigt, SLOs werden verletzt. Das Tool agierte dabei korrekt im Rahmen seiner Trainingsdaten; die Telemetrie war das Problem.

Ein zweites Muster betrifft automatische Mitigation. Deckt Telemetrie nur Teilsysteme ab, kann ein ML-gestützter Auto-Mitigation-Loop falsche Korrelationen ziehen, eine scheinbare Ursache identifizieren und aggressiv Traffic abziehen. War der betroffene Service nicht die eigentliche Ursache, erzeugt die Maßnahme zusätzliche Last andernorts und löst eine Kettenreaktion aus. Auch LLM-Co-Piloten im On-Call können trügerische Sicherheit vermitteln: Bei lückenhafter Telemetrie liefert das Modell eine plausible, aber falsche Erklärung samt Mitigationsvorschlag, dem Menschen folgen, weil er detailliert und smart wirkt. Das Problem ist selten die KI allein, sondern die Kombination aus schlechter Observability, fehlender Prävention und mangelnder Governance.

Der EU AI Act als Rahmen für autonome SRE-Tools

Wer KI-Komponenten in kritischer Infrastruktur einsetzt, muss den EU AI Act im Blick behalten. Er definiert Hochrisiko-KI-Systeme, unter die auch Bereiche kritischer Infrastruktur fallen. SRE- und Monitoring-Systeme, die autonom in die Funktionsfähigkeit etwa von Energie-, Verkehrs- oder Finanzmarkt-Infrastruktur eingreifen, können als Bestandteil eines solchen Hochrisiko-Systems gelten – die juristische Einordnung muss projektspezifisch erfolgen.

Besonders relevant ist Artikel 14 zur menschlichen Aufsicht: Hochrisiko-Systeme müssen so gestaltet sein, dass natürliche Personen sie wirksam überwachen und bei Bedarf eingreifen können. Menschen müssen die Kapazitäten und Grenzen des Systems verstehen, Anomalien und Fehlfunktionen erkennen und sich der Gefahr von Automation Bias bewusst sein. Für die Stufe Autonomous im Neumann-Modell bedeutet das: Es muss klar definiert sein, wer die Aufsicht führt, und es braucht Not-Aus-Mechanismen sowie Governance-Prozesse wie Rollback-Policies. LLM-Plattformen können zudem als General-Purpose AI mit systemischem Risiko gelten, was Risiko-Evaluation, adversariales Testen und die Meldung schwerwiegender Vorfälle an das EU AI Office nach sich zieht. In Deutschland kommen DSGVO sowie sektorspezifische Regulierung durch BaFin oder BNetzA hinzu.

Neumanns Fazit bleibt konsistent: Alle Tätigkeiten, die zur Reliability beitragen, müssen adressiert werden. Automatisierung ist das Ziel, KI nur ein Werkzeug. Ob eine autonome Stufe über LLMs, klassische ML-Modelle oder SLO-basierte Control-Loops erreicht wird, ist zweitrangig – entscheidend sind solide Telemetrie, saubere Prävention und eine klare Rollenverteilung zwischen Mensch und Maschine.

Severin Neumann ist Head of Community bei Bronto. Er beschäftigt sich seit vielen Jahren mit Observability, verteilten Systemen und der Frage, wie Engineering-Teams komplexe Softwarelandschaften zuverlässig betreiben können. Severin ist Mitglied des OpenTelemetry Governance Committees sowie Co-Maintainer der OpenTelemetry-Dokumentation und engagiert sich aktiv in der Open-Source- und Cloud-Native-Community.

(map)