SLOs, Incident & On-Call

Das Ops in LLMOps

Ein LLM-Feature ist im Betrieb ein besonderer Dienst: Er ist nicht-deterministisch (dieselbe Eingabe, verschiedene Ausgabe), teuer und ratelimitiert, hängt an einem externen Anbieter — und wenn er „falsch“ antwortet, gibt es keinen Stacktrace. Trotzdem gelten die klassischen SRE-Prinzipien: messbare Ziele, Fehler-Budgets, graceful degradation, geübte Incident-Response.

Dieses Modul ist die Brücke zur SRE-Praxis, angewandt auf LLM-Eigenheiten. Es geht nicht um Modellauswahl oder Prompt-Qualität, sondern darum, den fertigen Dienst zuverlässig laufen zu lassen: beobachten, Ziele setzen, unter Last und Ausfall stabil bleiben, im Zwischenfall richtig handeln.

SLIs, SLOs und die Fehler-Taxonomie

Ein SLI (Service Level Indicator) ist eine gemessene Kennzahl deines Dienstes, ein SLO (Service Level Objective) das Ziel darauf — z. B. „99,5 % der Anfragen liefern in unter 8 s eine gültige Antwort“. Ein SLI muss in Echtzeit maschinell messbar sein, sonst kannst du weder alarmieren noch ein Fehler-Budget führen.

Deshalb ist „die Antwort ist inhaltlich falsch“ kein brauchbarer Verfügbarkeits-SLI: Korrektheit erfordert Ground-Truth oder ein (selbst probabilistisches, teures, langsames) Urteil — das gehört ins Offline-Eval und ins Drift-Monitoring, nicht auf den Pager. Der Verfügbarkeits-SLI stützt sich auf einen maschinell prüfbaren Antwort-Vertrag und eine klare Fehler-Taxonomie:

Provider-5xx (500/503)

Anbieter-seitiger Fehler, meist transient. Zählt gegen Verfügbarkeit; kandidat für Backoff-Retry.

Rate-Limit (429)

Deine Anfrage wurde gedrosselt — ein Kapazitätssignal, kein Defekt. Retry-After beachten.

Timeout

Antwort kam nicht rechtzeitig zurück — hängt an deiner Timeout-Wahl (siehe Tail-Latenz).

Schema-invalide Antwort

HTTP 200, aber unbrauchbar: kein valides JSON, leer, abgeschnitten. App-Fehler trotz HTTP-Erfolg.

Ein SLO impliziert ein Fehler-Budget: 99,5 % Ziel = 0,5 % erlaubte Fehler. Das Budget ist Betriebsmittel — es finanziert Deploys und Experimente. Ein 100-%-Ziel ist bei einem probabilistischen, fremd-gehosteten Dienst weder erreichbar noch sinnvoll.

Tail-Latenz: der Median lügt

Generative Aufrufe sind langschwänzig (heavy-tailed): Die Antwortdauer hängt an der erzeugten Token-Zahl, und Retries auf transiente Fehler starten die ganze Generierung neu. Der Median (p50) sieht dann harmlos aus, während p95/p99 weit darüber liegen — und genau diese langsamen Anfragen sind die, die Nutzer als „hängt“ erleben.

Bei Fan-out verschärft sich das: Wartet eine Anfrage auf mehrere Aufrufe, bestimmt der langsamste die Gesamtlatenz — schon moderate p99 einzelner Aufrufe summieren sich („the tail at scale“). Betreibe und alarmiere deshalb gegen p95/p99, nicht gegen Mittelwert oder Median.

Der Timeout ist keine technische Nebensache, sondern eine SLO-/UX-Entscheidung: Er kappt den Schwanz. Zu kurz → viele abgeschnittene Anfragen (die einen Fallback brauchen); zu lang → Nutzer warten, Verbindungen und Kapazität bleiben gebunden. Wähle ihn bewusst am Tail entlang, mit einem definierten Verhalten für die gekappten Anfragen.

Graceful degradation: lieber schwächer als tot

Fällt der Anbieter aus oder ist überlastet, ist ein harter Fehler die schlechteste Antwort — er macht aus einer Teil-Störung eine Voll-Störung. Graceful degradation hält die Kernfunktion teilweise am Leben, statt hart zu scheitern.

• Cache: vorhandene oder ähnliche Antwort ausliefern statt neu generieren.
• Kleineres/sekundäres Modell: günstiger, schwächer, aber verfügbar.
• Statische/regelbasierte Antwort: vordefiniert, für den Notfall.
• Reduzierter Funktionsumfang: die teure Fähigkeit deaktivieren, den Rest liefern.

Rate-Limits sind deine Kapazitätsgrenze

Anbieter begrenzen dich über RPM (requests per minute) und TPM (tokens per minute) bzw. Quotas. Das ist deine reale Kapazitätsdecke — nicht deine CPU. Mehr Worker oder Concurrency erzeugen gegen ein festes RPM/TPM nur mehr 429er, keine Kapazität.

Ein 429 heißt „langsamer“, nicht „mehr versuchen“. Wer bei 429 sofort und synchron retried, baut einen Retry-Sturm (thundering herd) und verschärft die Drosselung, die er beheben will. Lastspitzen gehören geformt, nicht durchgeprügelt:

• Queue / Client-seitiger Rate-Limiter: Demand glätten, unter der Decke bleiben.
• Backpressure: dem Aufrufer signalisieren, langsamer zu senden.
• Load-Shedding: unwichtige/niedrigpriore Last früh abwerfen, um die wichtige zu schützen.
• Backoff mit Jitter, `Retry-After` beachten: Retries entzerren, statt sie zu synchronisieren.

Der Incident ohne Stacktrace

„Das System halluziniert seit heute Früh vermehrt“ oder „verweigert plötzlich gültige Anfragen“ — Health-Checks grün, Latenz normal, keine Errors im Log. Ein Qualitäts-Incident produziert kein Crash-Signal, ist aber echter Nutzer-Schaden. Fehlen eines Stacktraces ist nicht die Abwesenheit eines Incidents.

Wie bei jedem Incident gilt: Severity nach Nutzer-Wirkung einstufen und die Blutung zuerst stoppen. Ohne Stacktrace kann die Root-Cause-Analyse lange dauern — also erst mitigieren, dann diagnostizieren. Sichere Mitigation ist der Rücksprung auf einen bekannt-guten Stand (Rollback / Kill-Switch auf Fallback), nicht ein Vorwärts-Fix live.

Provider-Risiko: ein Anbieter, ein Single Point of Failure

Hängt dein Produkt an einem Anbieter, ist dessen Ausfall dein Ausfall — Retries helfen nicht, wenn die einzige Abhängigkeit komplett weg ist. Eine Multi-Provider-Strategie (ein zweiter Anbieter als Fallback) reduziert dieses Risiko, kostet aber real: Prompt-Parität (Anbieter verhalten sich unterschiedlich), doppelte Evals, eine gepflegte Abstraktion, mehr Kosten.

Deshalb ist es eine Abwägung, kein Automatismus: Ein zweiter Anbieter rechtfertigt sich, wenn das Verfügbarkeitsziel über dem liegt, was ein Anbieter allein liefert, und das Feature geschäftskritisch ist. Ein zweiter API-Key oder eine zweite Region desselben Anbieters ist keine echte Redundanz — der Ausfall ist korreliert.

Zusammenfassung — gleich im Check

Du kennst jetzt die Betriebs-Achsen eines LLM-Dienstes: SLIs/SLOs & Fehler-Taxonomie, Tail-Latenz & Timeout, graceful degradation, Rate-Limits als Kapazitätsgrenze, Incident ohne Stacktrace und Provider-Risiko.

Was hier anders ist als in klassischer Bereitschaft

Klassische Bereitschaft reagiert auf Dinge, die kaputt sind: Fehlerraten, Ausfälle, Sättigung. Bei LLM-Diensten kommt eine Klasse dazu, die nicht kaputt ist, sondern falsch: Der Dienst antwortet schnell, mit Code 200 — nur inhaltlich schlechter als gestern. Die dazugehörigen Signale sind indirekt, verrauscht und träge.

Daraus folgt die Kernfrage dieses Moduls: Wie baut man Alarme auf Signale, die naturgemäß schwanken, ohne die Bereitschaft mit Fehlalarmen zu zermürben — und ohne echte Regressionen zu verschlafen?

Alarmiere auf Symptome, nicht auf Ursachen

Die tragfähigste Regel bleibt auch hier: Ein Alarm sollte an dem hängen, was Nutzer erleben, nicht an einer vermuteten Ursache. Für LLM-Dienste heißt das eine kleine Menge symptomnaher Signale statt eines Zoos aus internen Kennzahlen.

Verfügbarkeit und Latenz

Klassisch, deckt aber nur den Ausfall ab, nicht die schlechte Antwort.

Formgültigkeit der Ausgabe

Anteil der Antworten, die den vereinbarten Vertrag verletzen — hart messbar.

Verweigerungs- und Leerantwortquote

Reagiert empfindlich auf Prompt- und Modelländerungen.

Retrieval-Leerquote

Zeigt Datenprobleme, bevor Nutzer sie melden.

Explizite Nutzerrückmeldung

Ehrlich, aber träge und verzerrt — nie als alleiniger Auslöser.

Rauschen bändigen, ohne blind zu werden

Qualitäts-Proxymetriken schwanken durch Nicht-Determinismus, Tagesverlauf und Nutzungsmix. Eine feste Schwelle auf ein rohes Signal erzeugt entweder Dauerlärm oder ist so hoch gesetzt, dass sie nichts fängt. Bewährt hat sich eine Kombination:

• Zeitfenster und Mindestmenge: erst auslösen, wenn genug Anfragen im Fenster liegen — sonst alarmiert die Nacht mit zwanzig Anfragen.
• Relativ statt absolut: gegen eine Baseline vergleichbarer Zeiträume oder gegen die parallel laufende Vorgängerversion.
• Nach Segment schneiden: ein Problem in einer Sprache, einem Mandanten oder einer Anfrageklasse verschwindet im Gesamtdurchschnitt.
• Mehrfenster-Logik: ein schnelles Fenster für den steilen Einbruch, ein langsames für die schleichende Verschlechterung.

Schweregrade für Qualitätsschäden

Ein Schweregradmodell, das nur Verfügbarkeit kennt, stuft eine LLM-Qualitätskrise systematisch zu niedrig ein — der Dienst ist ja erreichbar. Für probabilistische Dienste braucht das Modell eine zweite Achse: die Art des Schadens einer falschen Antwort.

• Sicherheits- oder rechtlich relevante Falschauskunft an Kunden: höchste Stufe, unabhängig von der Häufigkeit.
• Systematisch schlechtere, aber unschädliche Antworten: hoch, wenn breit; mittel, wenn eng begrenzt.
• Einzelne auffällige Ausgaben ohne Muster: kein Incident, sondern ein Prüfauftrag.
• Eine kaputte Ausgabeform, die nachgelagerte Systeme bricht: wie ein klassischer Ausfall behandeln.

Bereitschaft kann ein Modell nicht reparieren. Sie kann aber eine begrenzte Menge von Hebeln ziehen — und genau die gehören vorbereitet, benannt und geübt.

Ein LLM-Runbook braucht zusätzlich zwei Dinge, die klassische Runbooks nicht haben: eine Liste der ausgabewirksamen Achsen, die sich zuletzt geändert haben können — auch ohne eigenen Deploy —, und einen vorbereiteten Weg, eine Stichprobe echter Ausgaben schnell anzusehen. Ohne Ausgabeeinsicht bleibt jede Diagnose eine Vermutung.