Rund um den Betrieb von Software hat sich ein neues Etikett etabliert: „AI SRE“. Gemeint sind Werkzeuge, die Störungen erkennen, Ursachen eingrenzen und im besten Fall selbst gegensteuern. In einem aktuellen Beitrag kritisiert Severin Neumann genau dieses Schlagwort und plädiert stattdessen für ein Modell der Cloud Native Computing Foundation (CNCF) – jener Stiftung, die Projekte wie Kubernetes und Prometheus beheimatet. Der Kern seines Arguments: Automatisiert werden sollen Reliability-Aufgaben, nicht Menschen.

Was hinter den Kürzeln steckt

SRE steht für Site Reliability Engineering, also die Disziplin, die den zuverlässigen Betrieb von Anwendungen mit ingenieurmäßigen Methoden absichert: messbare Zielwerte für Verfügbarkeit, automatisierte Reaktionen auf wiederkehrende Fehler, klar geregelte Bereitschaftsdienste und eine Nachbereitung von Störungen, die auf Ursachen statt auf Schuldige zielt.

„AI SRE“ verspricht, diese Rolle mit KI-Systemen zu besetzen. Und genau da setzt die Kritik an: Ein Etikett auf einem Produkt sagt noch nichts darüber aus, welche konkrete Aufgabe es abnimmt und wie verlässlich es das tut.

Warum die Unterscheidung praktisch relevant ist

Für Betreiberinnen und Betreiber von Websites, Portalen und Fachanwendungen ist der Unterschied kein Wortspiel, sondern eine Frage der Beschaffung. Wer eine Rolle einkauft, kauft ein Versprechen. Wer eine Aufgabe automatisiert, kann prüfen, ob das Ergebnis stimmt.

Konkrete Aufgaben lassen sich benennen und bewerten:

  • Alarme zusammenfassen, statt bei einem Ausfall dreißig einzelne Meldungen zu verschicken
  • bei einer Störung automatisch die relevanten Logs, Metriken und letzten Deployments zusammenstellen
  • Standardmaßnahmen wie das Zurückrollen einer Version oder das Neustarten eines Dienstes anstoßen
  • wiederkehrende Handgriffe aus dem Betriebsalltag in ausführbare Abläufe überführen

Für jede dieser Aufgaben lässt sich fragen: Wie oft tritt sie auf? Wie viel Zeit kostet sie heute? Und woran erkennt man, dass die Automatisierung richtig gehandelt hat? Diese Fragen sind bei einem Produkt, das schlicht „KI für den Betrieb“ verspricht, deutlich schwerer zu beantworten.

KI ist eine Zutat, kein Fundament

Sprachmodelle sind gut darin, unstrukturierte Informationen zu verdichten – etwa lange Logausgaben zu einer lesbaren Zusammenfassung, oder aus einer Störungshistorie einen Vorschlag für die nächste Prüfung abzuleiten. Das ist im Bereitschaftsdienst um drei Uhr morgens ein realer Gewinn.

Was Sprachmodelle nicht mitbringen: eine verlässliche Datengrundlage. Wenn eine Anwendung keine sauberen Metriken liefert, keine nachvollziehbare Deployment-Historie hat und Konfigurationen nicht versioniert sind, kann auch ein Modell nur raten. Der Aufwand liegt dann nicht in der KI, sondern in der Vorarbeit: Observability, also die Fähigkeit, den Zustand eines Systems von außen anhand von Metriken, Logs und Traces zu beurteilen, ist die Voraussetzung – nicht das Nebenprodukt.

Hinzu kommt die Frage der Handlungsbefugnis. Ein System, das Vorschläge macht, ist unkritisch. Ein System, das eigenständig in Produktion eingreift, braucht dieselben Schutzmechanismen wie ein Mensch: begrenzte Rechte, nachvollziehbare Protokolle, definierte Rückwege.

Was das für die Bewertung von Angeboten heißt

Wenn ein Anbieter KI-gestützten Betrieb anbietet, lohnen sich einige nüchterne Rückfragen:

  1. Welche Aufgabe genau wird automatisiert – und was passiert bei allen anderen?
  2. Welche Daten braucht das System, und liegen die im eigenen Betrieb überhaupt in ausreichender Qualität vor?
  3. Darf das System handeln oder nur vorschlagen? Wenn es handeln darf: in welchem Umfang, und wie wird das protokolliert?
  4. Wie sieht der Rückfallmodus aus, wenn die Automatisierung ausfällt oder falsch entscheidet?
  5. Wer trägt die Verantwortung für eine Fehlentscheidung – vertraglich und organisatorisch?

Antworten auf diese Fragen sagen mehr über den Nutzen eines Werkzeugs aus als jedes Kürzel im Produktnamen.

Der unspektakuläre Teil bleibt der wichtigste

Zuverlässiger Betrieb entsteht selten durch ein einzelnes Werkzeug. Er entsteht durch wiederholbare Deployments, durch Monitoring, das die richtigen Dinge misst, durch dokumentierte Abläufe für den Störungsfall und durch die Bereitschaft, nach einem Vorfall wirklich nachzuarbeiten. Das gilt für ein TYPO3-Portal mit angebundenen Fachsystemen genauso wie für eine verteilte Microservice-Architektur.

Diese Grundlagen sind wenig glamourös und lassen sich schlecht auf eine Folie schreiben. Sie sind aber die Basis, auf der Automatisierung – mit oder ohne KI – überhaupt erst wirken kann. Ein Modell, das Reliability-Aufgaben adressiert statt Rollen zu ersetzen, macht diesen Zusammenhang explizit: Der Mensch bleibt in der Verantwortung, die Maschine übernimmt die Wiederholung.

Für Web- und Softwareprojekte heißt das: Bevor über KI-gestützte Betriebswerkzeuge entschieden wird, sollte geklärt sein, welche Betriebsaufgaben heute manuell und wiederkehrend anfallen und ob die dafür nötigen Daten sauber vorliegen. Wer diese Vorarbeit leistet, kann KI gezielt dort einsetzen, wo sie tatsächlich Zeit spart – und behält gleichzeitig einen Betrieb, der auch dann funktioniert, wenn das Werkzeug einmal danebenliegt.

Quellen