# Reliabilität, SLOs & Incident

> Einen probabilistischen Dienst betreiben: SLIs/SLOs definieren, Tail-Latenz, graceful degradation, Provider-Rate-Limits als Kapazitätsgrenze, Incident-Response ohne Stacktrace und Provider-Ausfallrisiko.

Track: [LLM Production Ops](https://physar.tech/learn/llm-production-ops)  
Kanonische Fassung: https://physar.tech/learn/llm-production-ops/reliability-slo-incident  
Stand: 2026-07-25  
Interaktiver Teil: 6 Checks (nur im Browser)

## Reliabilität, SLOs & Incident: einen probabilistischen Dienst betreiben

### 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.

> **Merksatz:** Ein LLM-Dienst ist ein probabilistischer, fremd-gehosteter Downstream. Betreibe ihn wie eine **unzuverlässige externe Abhängigkeit** — nicht wie eine Funktion, die immer klappt.

### 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. |

> **Merksatz:** Ein SLI misst, was du **in Echtzeit** entscheiden kannst. „Falsche Antwort“ ist real, aber kein SLI — und ein reines HTTP-200 verdeckt schema-invalide Antworten.

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.

> **Merksatz:** Mittelwerte verstecken den Schwanz. Setze Timeout und SLO gegen **p95/p99** — den erlebst du, nicht den Median.

### 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.

> **Merksatz:** Ein akzeptabler degradierter Modus ist **noch nützlich** und **ehrlich signalisiert**. Ein stiller Qualitäts-Absturz, den niemand bemerkt, ist keine Degradation, sondern eine getarnte Störung.

### 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.

> **Merksatz:** Concurrency ist keine Kapazität, wenn ein Provider-Quota der Engpass ist. Spitzen mit Queue/Backpressure/Load-Shedding formen — blinde Retries verschärfen die Drossel.

### 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.

erkennen → Severity einstufen → **mitigieren** → diagnostizieren → kommunizieren

> **Merksatz:** Erst stoppen, dann verstehen. Ein Vorwärts-Fix unter Unsicherheit zerstört den Vergleich zum bekannt-guten Stand — der Rücksprung dorthin ist die sichere Mitigation.

### 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.

> **Merksatz:** Redundanz gegen korrelierte Ausfälle braucht **unabhängige** Anbieter — und lohnt nur, wenn das Verfügbarkeitsziel die Zusatzkomplexität (Parität, Eval-Doppelung, Kosten) trägt.

### 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**.

> **Gleich im Check:** In den nächsten Entscheidungen betreibst du diesen Dienst selbst durch reale Ops-Situationen — und siehst pro Option, **warum** sie trägt oder nicht.

## Quellen

- Google SRE Book — Kapitel „Service Level Objectives“ (Beyer, Jones, Murphy, Smith)
- Google SRE Book — Kapitel „Handling Overload“ & „Addressing Cascading Failures“ (Load-Shedding, Backpressure)
- Google SRE Book — Kapitel „Managing Incidents“ & „Emergency Response“
- The Tail at Scale — Dean & Barroso, Communications of the ACM, 2013
- Exponential Backoff And Jitter — Marc Brooker, AWS Architecture Blog, 2015
- Release It! — Michael Nygard (Circuit Breaker, Bulkhead, Fail Fast)
- Google SRE Workbook — Kapitel „Implementing SLOs“ (SLI-Auswahl, Fehler-Budget)
- Google SRE Book — Kapitel „Service Level Objectives“ (Latenz-Perzentile als SLI)
- Google SRE Book — Kapitel „Addressing Cascading Failures“ (Graceful Degradation)
- Release It! — Michael Nygard (Fail Fast, Circuit Breaker, Fallback)
- Google SRE Book — Kapitel „Handling Overload“ (Load-Shedding, Backpressure)
- Google SRE Book — Kapitel „Managing Incidents“ (Mitigation vor Root-Cause)
- Google SRE Book — Kapitel „Emergency Response“ (Severity, Kommunikation)
- Google SRE Book — Kapitel „Managing Critical State“ & „Addressing Cascading Failures“ (Redundanz, korrelierte Ausfälle)
- Release It! — Michael Nygard (Bulkhead, Dependency Isolation)