Warum klassische SLOs oft unpräzise sind
Service Level Objectives – kurz SLOs – sind das Fundament moderner Reliability-Arbeit. Sie definieren, wie gut ein System performen muss, damit Teams und Nutzer zufrieden sind. Doch in der Praxis stoßen statisch definierte SLOs schnell an Grenzen: Ein Schwellenwert, der unter normaler Last sinnvoll ist, kann zu Wochenendbetrieb oder zu Quartalsabschlüssen völlig unrealistische Maßstäbe setzen. Die Folge: Alert-Fatigue auf der einen, stille Degradierungen auf der anderen Seite.
Genau hier setzt ein wachsender Einsatz von Machine Learning im SRE-Kontext an. KI-Methoden können historische Leistungsdaten auswerten, saisonale Muster erkennen und SLO-Schwellenwerte dynamisch anpassen – ohne dass jede Kalibrierung manuell durch das On-Call-Team erfolgen muss.
Das Grundproblem: Statische Schwellenwerte in dynamischen Systemen
Viele Teams definieren ihre SLOs einmalig, meist auf Basis eines „guten Monats" oder eines geschätzten Normalbetriebs. Diese Werte bleiben oft monatelang unverändert, während sich das System, der Traffic und die Nutzungsmuster längst gewandelt haben. Typische Konsequenzen:
- SLOs werden dauerhaft mit großem Puffer eingehalten – das Error Budget wird nie wirklich relevant
- Oder: SLOs werden regelmäßig verletzt, obwohl das System faktisch in Ordnung ist – weil die Basis-Erwartung nicht zur aktuellen Realität passt
- Saisonale Spitzen (Black Friday, Monatsabschlüsse, Spielupdates) werden nicht berücksichtigt
- Nachts gelten dieselben Toleranzen wie tagsüber, obwohl der Kontext völlig unterschiedlich ist
Das führt zu dem paradoxen Zustand, dass Teams entweder dauernd im Alarm-Modus sind oder sich von Alerts so wenig gestört fühlen, dass echte Probleme untergehen.
Wie maschinelles Lernen hier helfen kann
KI-gestützte SLO-Optimierung setzt an drei Stellen an:
1. Saisonale Baseline-Erkennung
Zeitreihenmodelle wie Prophet, SARIMA oder LSTM-Netzwerke können historische Performancedaten analysieren und wiederkehrende Muster erkennen. Statt eines festen Grenzwerts von beispielsweise 200 ms P95-Latenz wird ein erwartetes Band modelliert: Was ist für einen Dienstag um 14 Uhr eine normale Latenz? Was für einen Freitagabend? Was für die erste Woche nach einem Major-Release?
Das Ergebnis ist ein dynamischer Referenzbereich, der kontextsensitiv zeigt, wann etwas wirklich außergewöhnlich ist – und wann es sich um normales Systemverhalten handelt.
2. Automatische Error-Budget-Anpassung
Error Budgets definieren, wie viel Ausfall oder Degradierung innerhalb eines SLO-Zeitraums akzeptabel ist. Wenn das Budget aufgebraucht ist, sollten neue Releases gestoppt werden. Wenn noch viel Budget vorhanden ist, kann schneller deployt werden.
ML-Modelle können dabei helfen, diese Budgets feiner zu granulieren: Statt einem monatlichen Error Budget könnten wochenspezifische oder kontextabhängige Budgets definiert werden, die realistischer widerspiegeln, wann Nutzer besonders betroffen wären.
3. Anomalieerkennung auf Modellebene
Klassisches Monitoring prüft: Liegt ein Wert über oder unter einem Schwellenwert? KI-basiertes Monitoring kann multidimensional denken: Wie verhält sich die Kombination aus Latenz, Fehlerrate und Throughput? Wenn alle drei gleichzeitig in eine bestimmte Richtung driften, kann das ein Signal sein – auch wenn jeder einzelne Wert noch im grünen Bereich liegt.
Isolation Forest, Autoencoder oder Multivariate LSTM-Modelle sind Ansätze, die in produktiven SRE-Umgebungen eingesetzt werden, um solche korrelierten Anomalien früh zu erkennen.
Konkrete Anwendung im SRE-Alltag
Ein praktisches Beispiel: Ein Team betreibt eine API mit definierten SLOs für Latenz und Fehlerrate. Bisher galt ein fester Alert-Threshold von 5 % Fehlerrate. In der Weihnachtszeit steigt die Rate regelmäßig auf 3–4 % – ohne dass es einen echten Incident gibt, weil die Infrastruktur unter dem erhöhten Last gut skaliert. Das Team wird trotzdem mehrfach pro Woche geweckt.
Mit einem ML-Modell, das die Weihnachtssaison als reguläre Baseline kennt, würde der Threshold dynamisch auf 6–7 % angehoben – und das On-Call-Team nur dann alarmiert, wenn die Rate diesen kontextuellen Erwartungswert überschreitet. Gleichzeitig könnten Ausreißer unter normaler Last früher erkannt werden, weil das Modell weiß, dass 3 % Fehlerrate an einem ruhigen Dienstagmorgen sehr ungewöhnlich ist.
Grenzen und Risiken des Ansatzes
So vielversprechend KI-gestützte SLO-Optimierung ist, gibt es wichtige Einschränkungen:
- Datenqualität: ML-Modelle sind nur so gut wie die Daten, auf denen sie trainieren. Inkonsistente Metriken oder unvollständige Historien führen zu schlechten Vorhersagen.
- Black-Box-Problematik: Wenn ein Modell automatisch Thresholds anpasst, muss das Team verstehen können, warum. Unkontrollierte Anpassungen können Probleme verschleiern.
- Feedback-Schleifen: Wenn das Modell auf Basis von Incidents trainiert wird, die durch das Modell selbst ausgelöst wurden, können sich systematische Fehler einschleichen.
- Verantwortlichkeit: SLOs sind Versprechen an Stakeholder. Wer ist verantwortlich, wenn ein ML-Modell den Threshold so weit anhob, dass ein echter Incident nicht erkannt wurde?
Deshalb empfehlen erfahrene SRE-Teams: ML-Modelle als Entscheidungsunterstützung nutzen, nicht als autonome Entscheidungsträger. Die finale Threshold-Anpassung sollte nachvollziehbar, dokumentiert und durch einen Menschen genehmigt sein.
Tools und Frameworks im Überblick
Mehrere Observability-Plattformen bieten inzwischen ML-gestützte Anomalieerkennung an. Darüber hinaus gibt es Open-Source-Ansätze:
- Facebook Prophet: Zeitreihenprognose mit eingebautem Saisonalitätsmodell, gut geeignet für regelmäßige Muster
- Prometheus + Grafana ML-Plugins: Integration von Anomalieerkennung direkt in bestehende Monitoring-Stacks
- OpenTelemetry + ML-Pipelines: Basis für eigene Anomalieerkennungs-Pipelines auf Trace- und Metrikebene
- Elastic ML: Machine Learning Jobs in Elasticsearch für Log- und Metrikanomalien
Fazit
KI-gestützte SLO-Optimierung ist kein Ersatz für gute Reliability-Arbeit – sie ist eine Erweiterung davon. Teams, die bereits klare SLOs, saubere Metriken und eine gelebte Error-Budget-Kultur haben, können durch den Einsatz von ML präzisere Alerts, weniger Fehlalarme und ein realistischeres Bild ihres Systemzustands gewinnen. Der Schlüssel liegt darin, die Modelle transparent zu halten, ihre Entscheidungen nachvollziehbar zu machen und sie als Werkzeug im SRE-Werkzeugkasten zu verstehen – nicht als Autopilot.
Bildquelle: Foto von Taylor Vick via Unsplash
Quellen:
Google SRE Book: Service Level Objectives (sre.google)
Meta Open Source: Prophet – Forecasting at Scale (github.com/facebook/prophet)
Prometheus Docs: Alerting Best Practices (prometheus.io)
