Skip to content
RiverCore
Dynatrace 2026 SRE-Studie: KI-Monitoring ist jetzt der Kernberuf
AI model monitoringSRE workloadobservability toolsAI monitoring top SRE priority 2026site reliability engineering AI models

Dynatrace 2026 SRE-Studie: KI-Monitoring ist jetzt der Kernberuf

2 Sep 20267 Min. LesezeitSarah Chen

Zwei Drittel der Site-Reliability-Engineers geben heute an, dass das Monitoring von KI-Modellen ihre wichtigste Aufgabe ist. Dieser einzelne Datenpunkt – 67 Prozent – definiert neu, was SRE im Jahr 2026 tatsächlich bedeutet: nicht Linux-Server und Kubernetes-Pods, sondern Model-Endpoints, Drift und Inferenzlatenz, die in derselben On-Call-Rotation wie das Zahlungs-Gateway sitzen.

Dynatrace veröffentlichte den Befund am 26. August 2026 im Report „State of SRE and Platform Engineering 2026" – und kombinierte ihn mit einem Unternehmenszug: der angekündigten Absicht, Arize zu übernehmen, einen Anbieter von KI-Evaluierungstools. Studie und M&A zusammen gelesen verraten, wohin der Observability-Markt die Engineering-Budgets der nächsten drei Jahre lenken will.

Was geschehen ist

Die Studie befragte 919 IT-Führungskräfte weltweit, und wie Express Computer berichtete, lautet die zentrale These: KI-Workloads definieren neu, was SRE- und Platform-Engineering-Teams leisten müssen. Die Schlagzeilen-Zahlen sind es wert, nebeneinandergestellt zu werden – denn ihr Zusammenspiel ergibt das eigentliche Bild.

Zunächst zur Verbreitung. Gartner, im Report zitiert, prognostiziert, dass 80 Prozent der Unternehmen bis 2028 SRE-Praktiken übernehmen werden, gegenüber 30 Prozent im Jahr 2024. Das entspricht einer 2,67-fachen Ausweitung der Praxis in vier Jahren – selbst nach Maßstäben der Enterprise-Software-Diffusion ein aggressives Wachstum. Rückendeckung von der Führungsebene ist bereits vorhanden: 92 Prozent der Organisationen berichten von Unterstützung des Managements für SRE-Initiativen, und 89 Prozent der Organisationen im Platform Engineering haben eine interne Developer-Plattform aufgebaut, wobei 60 Prozent davon eine breite abteilungsübergreifende Akzeptanz melden.

Dann der KI-Überbau. 67 Prozent der SREs nennen KI-Modell-Monitoring als ihren wichtigsten Anwendungsfall. 58 Prozent sagen, das Monitoring von Modell-Performance und -Genauigkeit ist bereits ihre häufigste KI-gestützte Fähigkeit. Die Hälfte der SREs nutzt KI für die automatisierte Incident-Response. 55 Prozent der Platform Engineers konzentrieren sich darauf, KI-gestützte Developer-Tools wie Copilots und Chatbots auszuliefern.

Die Reibungspunkte sind ebenso klar quantifiziert. 37 Prozent der Platform Engineers nennen Tool-Integration als ihre größte Herausforderung. Nur 40 Prozent verankern Observability über alle Deployment-Phasen hinweg. Nahezu die Hälfte der SREs sagt, zu viele Datenquellen und Metriken erschweren die Definition sinnvoller SLOs. Und Dynatrace räumt ein, dass KI beim Kostenabbau und bei der Mean Time to Resolution hinter den Erwartungen zurückbleibt – auch wenn sie die Erwartungen in puncto Zuverlässigkeit und Produktivität grundsätzlich erfüllt. Die Quelle gibt das Ausmaß des MTTR-Rückstands nicht in absoluten Minuten an, was jedoch entscheidend ist: Es bestimmt, ob „hinter den Erwartungen" einen Rundungsfehler oder eine ganze Größenordnung bedeutet.

Technische Anatomie

Das Engineering-Problem hinter diesen Zahlen ist, dass KI-Workloads die Annahmen brechen, auf denen klassische Observability aufgebaut wurde. Ein traditioneller Dienst hat eine Anfrage, eine Antwort, ein Latenz-Histogramm und eine Fehlerquote. Man kann ihn in einen OpenTelemetry-Span einbetten, einen SLO auf p99-Latenz und Error-Budget definieren – und die Sache ist erledigt. Ein LLM-Endpoint hat all das plus eine zweite Oberfläche: die Qualität, Faktentreue und Sicherheit der Ausgabe. Eine 200-OK-Antwort mit einer halluzinierten Antwort ist ein stiller Fehler, den keine HTTP-Layer-Probe erkennt.

Deshalb listen 58 Prozent der SREs Modell-Performance- und Genauigkeits-Monitoring als ihre häufigste KI-Fähigkeit auf, und deshalb ist die Arize-Übernahme strukturell bedeutsam. KI-Evaluierungsplattformen sind auf Offline- und Online-Evaluierung spezialisiert: Ground-Truth-Vergleiche, LLM-as-Judge-Scoring, Embedding-Drift, Prompt-Regressions-Suiten. Observability-Plattformen sind auf Traces, Metriken, Logs und Incident-Workflows spezialisiert. Historisch gesehen lebten diese in separaten Tools, die von separaten Teams verantwortet wurden – genau diese Lücke hat Steve Tack, Chief Product Officer von Dynatrace, benannt: „KI-Engineering-Teams haben in einem Set von Tools evaluiert, während Operations-Teams in einem anderen überwacht haben. Diese Lücke ist nicht länger tragbar, je tiefer KI in die Enterprise-Produktion einzieht."

Das SLO-Problem ist die zweite technische Wunde. 89 Prozent der SREs verwenden SLOs zumindest in einigen Teams oder Systemen – das klingt gesund, bis man das Gegengewicht liest: Nahezu die Hälfte sagt, zu viele Datenquellen und Metriken verhindern die Definition wirksamer SLOs. Wenn man Modellqualitäts-Metriken, Token-Kosten-Metriken, Safety-Classifier-Scores und Retrieval-Augmentation-Trefferquoten zusätzlich zu den Golden-Signal-Metriken aus dem darunterliegenden Kubernetes-Layer hinzufügt, wird die SLO-Definition zu einem Taxonomie-Problem, nicht zu einem Mathematik-Problem. Dass bereits die Hälfte der SREs die Incident-Response an KI-gestützte Automatisierung delegiert, verschärft dies, denn agentische Remediation mit unscharfen SLOs führt dazu, dass automatisierte Aktionen auf Rauschen reagieren.

Was wir aus der Quelle nicht wissen, ist, wie viele dieser Organisationen agentische Remediation tatsächlich in der Produktion und nicht nur im Staging eingesetzt haben. Der Report beschreibt Teams, die „bewusst Transparenz und menschliche Aufsicht priorisieren, bevor sie die Automatisierung ausweiten" – das ist eine überprüfbare Aussage: Wenn sie zutrifft, sollten wir sehen, dass automatisierte Aktionsvolumina im Vergleich zu Monitoring-Volumen in den nächsten zwölf Monaten flach bleiben oder unterdurchschnittlich wachsen. Wenn nicht, ist bis Mitte 2027 ein öffentlicher Postmortem über einen außer Kontrolle geratenen Remediator zu erwarten.

Wer unter Druck gerät

Drei Gruppen sind exponiert. Erstens: eigenständige KI-Evaluierungs-Anbieter, die nicht Arize sind. Dynatrace hat mit dem Scheckbuch erklärt, dass KI-Evaluierung ein Feature von Observability ist und keine eigenständige Kategorie. Datadog, New Relic, Splunk, Grafana Labs und Chronosphere müssen nun alle Stellung beziehen: bauen, kaufen oder kooperieren. In den nächsten zwei Quartalen ist mindestens eine weitere Übernahme eines Evaluierungs-Anbieters zu erwarten. Wenn das nicht passiert, ist das ein Signal, dass die etablierten Anbieter glauben, es schneller selbst bauen zu können, als sie es integrieren könnten.

Zweitens: Platform-Engineering-Teams, die ihre IDP als einmaliges Lieferziel statt als lebendes Produkt betrachten. 89 Prozent der Platform-Engineering-Shops haben eine IDP, aber nur 60 Prozent melden breite Akzeptanz. Diese 29-Punkte-Lücke zwischen „gebaut" und „tatsächlich genutzt" ist der Punkt, an dem Budgets gekürzt werden, wenn ein CFO fragt, was das Platform-Team in diesem Jahr geliefert hat. In Fintech und iGaming insbesondere, wo Release-Geschwindigkeit ein Wettbewerbsvorteil ist, ist eine wenig genutzte IDP ein sehr sichtbarer Posten.

Drittens: SRE-Organisationen, die auf das Versprechen von MTTR-Reduktion durch KI-für-Ops gesetzt haben. Der Report weist explizit darauf hin, dass KI sowohl bei Kosten als auch bei MTTR hinter den Erwartungen zurückbleibt. Anbieter haben das Versprechen verkauft; das Versprechen wurde nicht vollständig eingelöst. Wer seine Personalplanung 2026 mit „KI wird die Incident-Dauer um X Prozent reduzieren" begründet hat, braucht eine neue Begründung – und die Quelle gibt nicht an, was X tatsächlich sein sollte. Das ist die Zahl, die Käufer jetzt von ihren Anbietern einfordern sollten.

Die nächsten 90 Tage für jede Gruppe: Eval-Anbieter verhandeln oder festigen ihre Position, Platform-Teams instrumentieren die Akzeptanz, und SRE-Leiter verhandeln die Erfolgskriterien für KI-Ops neu, bevor die Jahresplanung feststeht.

Playbook für Engineering-Teams

Wer Reliability oder Platform Engineering verantwortet, sollte dieses Quartal vier Schritte unternehmen.

Erstens: Prüfen Sie Ihren SLO-Katalog, bevor Sie KI-Qualitätsmetriken hinzufügen. Wenn Ihre Engineers bereits sagen, es gibt zu viele Metriken, um gute SLOs zu definieren, wird das Hinzufügen von Halluzinierungsraten und Token-Kosten-Budgets die Situation verschlechtern, nicht verbessern. Erst bereinigen. Ein praktisches Ziel: Kein Dienst hat mehr als fünf SLOs, und jeder SLO hat einen namentlich genannten Verantwortlichen, der ihn in den letzten 30 Tagen überprüft hat.

Zweitens: Behandeln Sie KI-Evaluierung und Produktions-Monitoring als eine Pipeline, nicht als zwei. Unabhängig davon, ob Sie Dynatrace plus Arize kaufen – die architektonische Wette ist richtig: Ihr Eval-Harness in CI sollte dieselben Signale aussenden, die Ihre Produktions-Observability verarbeitet, idealerweise über OpenTelemetry-Semantic-Conventions. Wenn das Eval-Team und das Ops-Team auf unterschiedliche Dashboards schauen, haben Sie genau die Lücke gebaut, die Tack beschrieben hat.

Drittens: Sichern Sie agentische Remediation durch explizite Blast-Radius-Kontrollen ab. Die Hälfte der SREs delegiert bereits die Incident-Response an KI. Bevor Sie diesen Bereich erweitern, definieren Sie, was die KI nicht anfassen darf: Produktionsdatenbanken, Zahlungs-Rails, alles mit einer Compliance-Grenze. Protokollieren Sie jede automatisierte Aktion in einem Append-Only-Audit-Stream.

Viertens: Messen Sie die IDP-Akzeptanz wöchentlich, nicht quartalsweise. Wenn Ihre interne Plattform in der 29-Punkte-Lücke zwischen „implementiert" und „breit akzeptiert" feststeckt, ist die Lösung Developer-Experience-Arbeit, keine weiteren Features. Instrumentieren Sie die Plattform selbst mit derselben Telemetrie, die Sie von den Anwendungs-Teams fordern.

Wichtigste Erkenntnisse

  • 67 Prozent der SREs stufen KI-Modell-Monitoring als ihren wichtigsten Anwendungsfall ein – das definiert das SRE-Berufsbild effektiv rund um Modellverhalten statt ausschließlich um Infrastruktur neu.
  • Gartners Prognose von 80 Prozent SRE-Adoption bis 2028, ausgehend von 30 Prozent im Jahr 2024, bedeutet eine 2,67-fache Skalierung der Praxis in vier Jahren – und der Tooling-Markt konsolidiert sich entsprechend.
  • Die beabsichtigte Übernahme von Arize durch Dynatrace ist eine Wette darauf, dass KI-Evaluierung als Feature in Observability aufgeht und keine eigenständige Kategorie bleibt. Achten Sie auf Folge-M&A von Datadog, Splunk oder Grafana innerhalb von zwei Quartalen.
  • KI liefert laut Report bei MTTR und Kosten weniger als erwartet, doch die Quelle quantifiziert den Rückstand nicht – das ist die Zahl, die jeder Käufer vor der Planung 2027 von seinem Anbieter einfordern sollte.
  • Das größte versteckte Risiko ist agentische Remediation, die auf unscharfen SLOs läuft. Wenn Teams Metriken nicht bereinigen und den Automatisierungs-Blast-Radius nicht kontrollieren, ist bis Mitte 2027 ein öffentlicher Incident durch einen automatisierten Remediator zu erwarten.

Häufig gestellte Fragen

F: Was ist der Dynatrace State of SRE and Platform Engineering 2026 Report?

Es handelt sich um eine globale Befragung von 919 IT-Führungskräften, die Dynatrace am 26. August 2026 veröffentlicht hat. Sie untersucht, wie Unternehmen Observability, Automatisierung und KI orchestrieren, um SRE und Platform Engineering zu skalieren. Das zentrale Ergebnis: KI-Workloads formen um, wofür diese Teams verantwortlich sind – 67 Prozent der SREs nennen KI-Modell-Monitoring als ihren wichtigsten Anwendungsfall.

F: Warum übernimmt Dynatrace Arize?

Dynatrace hat die Absicht angekündigt, Arize zu übernehmen, um die Lücke zwischen KI-Evaluierungs-Tools der KI-Engineering-Teams und Observability-Tools der Operations-Teams zu schließen. Wie Steve Tack, Chief Product Officer von Dynatrace, formulierte: Der Betrieb in separaten Systemen ist nicht länger tragbar, je tiefer KI in die Enterprise-Produktion eindringt. Der Deal integriert KI-native Evaluierung direkt in die Observability-Plattform.

F: Warum bleibt KI bei MTTR laut dem Report hinter den Erwartungen zurück?

Die Studie stellt fest, dass KI die Erwartungen bei Zuverlässigkeit und Entwicklerproduktivität grundsätzlich erfüllt, bei Kostenreduktion und Mean Time to Resolution jedoch zurückbleibt. Zu den beitragenden Faktoren zählen Tool-Integrations-Probleme (von 37 Prozent der Platform Engineers als größte Herausforderung genannt) und Metrik-Überlastung – nahezu die Hälfte der SREs sagt, zu viele Datenquellen behindern eine wirksame SLO-Definition. Der Report quantifiziert den genauen MTTR-Rückstand nicht.

SC
Sarah Chen
RiverCore Analyst · Dublin, Ireland
TEILEN
// ÄHNLICHE ARTIKEL
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE