Predictive Reliability: Wie KI-Modelle drohende SLO-Verletzungen erkennen, bevor sie auftreten

Server-Rack in einem Rechenzentrum – symbolisch für zuverlässige Infrastruktur und SRE-Praktiken (Quelle: Pexels)

Site Reliability Engineering basiert auf dem Prinzip, Zuverlässigkeit messbar zu machen – über SLOs, Error Budgets und kontinuierliche Beobachtung. Ein strukturelles Problem dabei: Die meisten SRE-Prozesse sind reaktiv. Teams erfahren von einem SLO-Verstoß erst, wenn er bereits eingetreten ist. Das Error Budget ist dann schon verbraucht, der Schaden für Nutzer angerichtet.

Predictive Reliability ist ein Ansatz, der diesen Mechanismus umkehrt: Statt auf Verstöße zu reagieren, sollen drohende SLO-Verletzungen frühzeitig erkannt und als Warnsignal behandelt werden – bevor sie auftreten. Machine-Learning-Modelle spielen dabei eine zentrale Rolle.

Das Problem mit rein reaktivem SRE

Klassische SLO-Systeme messen Verfügbarkeit, Latenz oder Fehlerrate über einen definierten Zeitraum und prüfen, ob ein Schwellenwert unterschritten wurde. Das ist wertvoll, aber zeitlich begrenzt informativ: Wenn eine Latenz-SLO besagt, dass 99 % der Requests unter 300 ms bleiben müssen, und 98,9 % der heutigen Requests diesen Wert einhalten, scheint alles in Ordnung.

Was diese Sicht nicht zeigt: Ein Trend, der sich über die letzten 48 Stunden aufgebaut hat und die Latenz täglich um 5 ms steigen lässt. Bei aktuellem Tempo wird die SLO in drei Tagen verletzt sein. Ein reaktives System schweigt, bis es zu spät ist.

Predictive Reliability: Der grundlegende Ansatz

Predictive Reliability nutzt historische Metriken, Zeitreihenanalyse und ML-Modelle, um diese Trendentwicklungen zu erkennen und vorherzusagen, wann ein SLO verletzt werden wird. Der Grundgedanke ist einfach: Wenn Messdaten einen Verlauf zeigen, kann dieser Verlauf extrapoliert werden.

In der Praxis ist das komplexer, weil viele Faktoren gleichzeitig wirken:

Saisonale Muster (Tageszeiten, Wochentage, Stoßzeiten)
Deployment-Effekte (neue Versionen verändern Metriken sprunghaft)
Externe Faktoren (Traffic-Spitzen, Abhängigkeiten zu Drittsystemen)
Langfristige Wachstumstrends (mehr Nutzer bedeuten mehr Last)

Ein sinnvolles Vorhersagemodell muss diese Faktoren auseinanderhalten: Was ist saisonal normales Verhalten, was ist eine echte Anomalie, die auf ein Problem hindeutet?

Technische Grundlagen: Zeitreihenmodelle und Anomalieerkennung

Für Predictive Reliability kommen verschiedene Klassen von Modellen zum Einsatz:

Klassische Zeitreihenmodelle

Modelle wie ARIMA, Prophet (von Meta entwickelt, Open Source) oder Holt-Winters Exponential Smoothing eignen sich gut für Metriken mit klaren saisonalen Mustern. Prophet beispielsweise zerlegt eine Zeitreihe in Trend, Saisonalität und Residual und kann mehrere Saisonalitäten gleichzeitig modellieren – Tages- und Wochenmuster für eine API-Latenz etwa.

Machine-Learning-Ansätze

LSTM-Netze (Long Short-Term Memory), Gradient-Boosting-Modelle oder Transformer-basierte Zeitreihenmodelle (wie TimesFM von Google) können komplexere Abhängigkeiten abbilden, benötigen aber mehr Trainingsdaten und Rechenressourcen. Sie eignen sich besonders, wenn mehrere Metriken gleichzeitig betrachtet werden sollen – etwa Latenz, CPU-Last und Fehlerrate gemeinsam.

Anomalieerkennung als erster Schritt

Bevor eine Vorhersage sinnvoll ist, muss das System verstehen, was "normal" bedeutet. Anomalieerkennungs-Algorithmen wie Isolation Forest, DBSCAN oder autoregressives Scoring lernen, das übliche Verhalten einer Metrik zu modellieren. Abweichungen davon werden markiert – und können dann als Eingabe für Vorhersagemodelle dienen.

Error Budget Forecasting: Der praktischste Einstieg

Für SRE-Teams ist Error Budget Forecasting oft der direkteste Einstiegspunkt in Predictive Reliability. Die Frage ist konkret: Wird das Error Budget für diesen Monat bis zum Monatsende aufgebraucht sein?

Auf Basis des bisherigen Verbrauchs im Monat und bekannter Muster aus Vormonaten lässt sich ein Verbrauchstrend berechnen. Zeigt der Trend, dass bei unverändertem Verhalten das Budget in 10 Tagen erschöpft sein wird, können Teams proaktiv reagieren: Release-Frequenz drosseln, bestimmte Features zurückhalten oder Incident-Reviews vorziehen.

Viele Monitoring-Plattformen bieten inzwischen integrierte Burndown-Projektionen für Error Budgets. Wer diese nicht nutzt, kann sie mit einfachen Zeitreihenberechnungen in eigenen Dashboards nachbauen.

Integration in bestehende Monitoring-Stacks

Predictive Reliability muss kein eigenständiges System sein. Die Integration in vorhandene Stacks ist oft der pragmatischere Weg:

Prometheus + Grafana: Mit der Prediction-Funktion in PromQL lassen sich einfache Trendvorhersagen direkt in Dashboards und Alert-Regeln integrieren (predict_linear()).
Datadog: Bietet nativ Forecasting-Funktionen auf Basis von Zeitreihenmodellen, konfigurierbar direkt in Monitoren und Dashboards.
Custom ML-Pipelines: Für anspruchsvollere Anforderungen können Teams Python-Pipelines (Prophet, scikit-learn) in Airflow- oder Argo-Workflows integrieren, die täglich neue Vorhersagen berechnen.

Grenzen und Herausforderungen

Predictive Reliability ist kein Allheilmittel. Einige Grenzen sind strukturell:

Unvorhersehbare Ereignisse: Infrastrukturausfälle durch externe Anbieter, plötzliche Traffic-Spikes oder Zero-Day-Vorfälle sind statistisch nicht vorhersagbar.
Datenqualität: Fehlerhafte oder lückenhafte Metrikdaten führen zu falschen Vorhersagen. Garbage in, garbage out gilt hier besonders.
False Alerts: Zu aggressive Vorhersagen können zu Alarm-Fatigue führen, wenn Teams ständig Warnungen erhalten, die nicht zu tatsächlichen Problemen führen.
Modelldrift: Vorhersagemodelle, die auf historischen Daten trainiert wurden, werden ungenauer, wenn sich das System grundlegend verändert – etwa durch ein Re-Architecting oder ein starkes Nutzerwachstum.

Predictive Reliability ergänzt, aber ersetzt nicht reaktive Überwachung. Beide Schichten gemeinsam ergeben eine belastbarere SRE-Praxis.

Fazit

SRE-Teams, die SLO-Verstöße konsequent vermeiden wollen, kommen an vorausschauender Beobachtung nicht vorbei. Predictive Reliability – ob über einfaches Error-Budget-Forecasting mit predict_linear() oder über komplexere ML-Pipelines – gibt Teams die Zeit, zu handeln bevor Nutzer den Schaden spüren.

Der Einstieg muss nicht komplex sein: Eine Burndown-Projektion für das Error Budget, kombiniert mit einem einfachen Alert bei drohender Unterschreitung, ist ein erster konkreter Schritt, der für die meisten Teams sofort umsetzbar ist.

Bildquelle: Pexels / Brett Sayles