🚀 Platform Engineer Lektion 36/50 ~6 Min. Fortgeschritten

SLIs, SLOs und Error Budgets für Plattform-Services

Reliability-Targets für interne Plattformen und Error-Budget-Politik.

Lernziele

Nach dieser Lektion kannst du erklären, warum interne Plattform-Services eigene SLOs brauchen, wie du SLIs für CI, Cluster-API und Provisioning definierst und wie Error Budgets Feature-Arbeit gegen Reliability-Arbeit austarieren. Du kannst den Unterschied zwischen einem Monitoring-Dashboard und einem SLO-basierten Reliability-Target benennen und eine Error-Budget-Politik skizzieren.

Das Problem: „Intern” heißt nicht „Unwichtig”

Wenn die CI-Plattform drei Stunden down ist, deployt kein Team. Wenn die Cluster-API nicht antwortet, können keine neuen Environments provisioniert werden. Wenn Vault nicht erreichbar ist, starten Pods ohne frische Secrets nicht neu. Interne Plattform-Services sind Multiplikatoren: Ein Ausfall trifft alle Stream-Teams gleichzeitig — und trotzdem haben die meisten Platform-Teams keine definierten Reliability-Targets.

Stattdessen gilt eine informelle Erwartung: „sollte halt laufen”. Das führt zu vorhersehbaren Problemen: Kein Prioritätsrahmen, wenn Reliability und Feature-Requests konkurrieren. Kein objektiver Maßstab für On-Call (Lektion 39). Keine Grundlage für Postmortems (Lektion 37). Und im schlimmsten Fall: Das Platform-Team baut neue Capabilities, während die bestehenden instabil sind — bis ein großer Incident alle Feature-Pläne verdrängt.

SLIs, SLOs und Error Budgets bringen die gleiche Disziplin, die Google und das SRE-Handbuch für externe Services empfehlen, auf interne Plattformen.

SLI, SLO, Error Budget — die Begriffe

SLI (Service Level Indicator) ist eine messbare Metrik, die den Nutzer-Zustand widerspiegelt — nicht die Maschine. Für eine CI-Plattform ist „CPU des Runner-Nodes” kein SLI; „Anteil der Builds, die innerhalb von 10 Minuten erfolgreich abschließen” schon. Für GitOps: „Anteil der Sync-Requests, die innerhalb von 60 Sekunden reconciled sind”.

SLO (Service Level Objective) ist das Ziel für einen SLI über ein Zeitfenster: „99,5 % der Builds schließen innerhalb von 10 Minuten ab (monatlich gemessen).” Das SLO ist ein interner Vertrag mit den Stream-Teams — nicht mit externen Kunden, aber mit derselben Ernsthaftigkeit.

Error Budget ist die erlaubte Unzuverlässigkeit: Bei 99,5 % SLO über 30 Tage darfst du 0,5 % der Builds verfehlen — das sind bei 100.000 Builds im Monat 500 fehlgeschlagene oder zu langsame Läufe. Das Budget ist kein Bug-Kontingent, sondern ein Steuerungsinstrument: Solange Budget übrig ist, darf das Team Features shippen. Ist es aufgebraucht, friert Feature-Arbeit ein und Reliability hat Vorrang.

SLIs für typische Plattform-Services

Jeder Service aus den Lektionen 31–35 braucht mindestens einen SLI, der den Nutzer-Erlebnis-Aspekt misst:

Service	SLI-Beispiel	Warum nicht Infrastruktur-Metrik
CI/CD Build Platform	Build-Success-Rate + p95 Build-Dauer	Runner-CPU sagt nichts über Queue-Stau
Compute-Provisioning	% Environments provisioniert in < 5 Min	Controller-Pod-Restarts sind Symptom, nicht SLI
Observability	Query-Success-Rate + Ingest-Latenz p95	Prometheus-Pod-Count ≠ Dashboard-Ladezeit
Secrets (Vault)	Secret-Read-Success-Rate + Latenz p99	Vault-Seal-Status ist binär, nicht graduell
DBaaS	Connection-Success-Rate + Query-Latenz p95	PVC-Usage warnt, misst aber nicht Verfügbarkeit

Die Metriken kommen aus der Observability-Schicht (Lektion 32) — deshalb ist Observability-as-a-Service Voraussetzung für SLOs, nicht umgekehrt.

Error-Budget-Politik: Was passiert bei Verbrauch?

Eine Error-Budget-Politik muss vor dem ersten Incident schriftlich existieren. Mindestens diese Regeln:

Budget > 50 % verbleibend: Normalbetrieb. Features und Reliability parallel.
Budget 10–50 %: Erhöhte Vorsicht. Keine riskanten Changes (Operator-Upgrades, große Migrationen) ohne Canary.
Budget < 10 %: Feature-Freeze für den betroffenen Service. Alle Kapazität geht in Reliability-Arbeit: Root-Cause-Analyse, Toil-Reduktion, Runbook-Verbesserung.
Budget aufgebraucht: Eskalation an Engineering-Leadership. Postmortem-Pflicht. Kein neues Feature bis SLO über zwei aufeinanderfolgende Fenster wieder grün.

Das klingt hart — ist aber fairer als der implizite Modus „wir reagieren auf den lautesten Schreihals”. Stream-Teams können sagen: „Euer CI-SLO ist seit zwei Wochen rot — wir akzeptieren keinen weiteren Runner-Pool-Umbau, bis die Success-Rate wieder stimmt.”

SLOs setzen: vom Dashboard zum Vertrag

Vier Schritte, die du in der Praxis durchläufst:

1. User Journey identifizieren. Was will ein Entwickler tun? „Build starten”, „Environment anfordern”, „Dashboard laden”, „Secret lesen”. Jede Journey bekommt einen SLI.

2. Datenquelle validieren. Kannst du den SLI aus vorhandenen Metriken berechnen? Wenn nicht, instrumentiere zuerst — kein SLO auf Basis von kubectl get pods.

3. Zielwert mit Stakeholdern verhandeln. 99,9 % klingt gut, ist aber für eine interne CI bei 8,7 Stunden Ausfallzeit pro Monat. Starte konservativ (99,5 %), verschärfe nach zwei Quartalen mit Daten.

4. Alerting auf Burn Rate. Page nicht bei jedem einzelnen SLO-Verstoß — alerte auf schnellen Budget-Verbrauch (multi-window, multi-burn-rate nach Google SRE Workbook). Ein einzelner langsamer Build ist kein Incident; 5 % Budget in einer Stunde schon.

Praxis: Ein SLO für die CI-Plattform definieren

SLI wählen: build_success_within_sla = Builds mit Status success UND Dauer < 600s, geteilt durch alle Builds.
Messung: Prometheus-Query über CI-Exporter-Metriken — sum(rate(builds_success_within_sla[30d])) / sum(rate(builds_total[30d])).
SLO setzen: 99,5 % über 30 Tage.
Budget berechnen: Bei 50.000 Builds/Monat → 250 Builds dürfen SLA verfehlen.
Dashboard: Ein Panel mit aktuellem SLO-Stand, verbleibendem Budget und Burn-Rate-Alert.
Politik kommunizieren: Im Platform-Team-Channel und im internen Status-Page — Stream-Teams müssen den SLO kennen.

Wenn Schritt 6 fehlt, ist der SLO ein internes Spreadsheet, kein Vertrag.

Typische Stolperfallen

Infrastruktur-Metriken als SLI: „Node-Not-Ready < 3” sagt nichts darüber, ob Entwickler deployen können. Immer nutzerorientiert messen.

Zu viele SLOs: Jedes Pod bekommt ein SLO — niemand kann priorisieren. Drei bis fünf SLOs für die gesamte Plattform, nicht fünfzig.

SLO ohne Alerting: Ein Dashboard, das montags angeschaut wird, ist kein SLO. Burn-Rate-Alerts sind Pflicht.

100 % SLO: Unmöglich und teuer. 99,5–99,9 % ist für interne Services realistisch; 100 % blockiert jeden Change.

Kein Error-Budget-Freeze: Budget aufgebraucht, aber Features werden trotzdem gemergt — das SLO wird zur Lüge.

Interview-Vorbereitung

Auf „Wie definierst du SLOs für interne Plattform-Services?” antwortest du: Problem (Plattform-Ausfall trifft alle Teams, keine Priorisierung ohne Targets) → SLI (nutzerorientiert: Build-Success, Provisioning-Zeit, nicht Node-CPU) → SLO + Budget (interner Vertrag, Feature-Freeze bei Verbrauch) → Alerting (Burn Rate, nicht Einzelverstoß).

Follow-ups:

„SLI vs. SLA?” — SLI ist die Metrik, SLA ist der externe Vertrag mit Konsequenzen (oft mit Geld). Interne Plattformen haben meist SLOs ohne SLA — aber mit Error-Budget-Politik.
„Welches SLO zuerst?” — CI/CD oder Provisioning — was am häufigsten genutzt wird und am meisten Teams gleichzeitig trifft.
„Was tun bei aufgebrauchtem Budget?” — Feature-Freeze, Reliability-Fokus, Postmortem, erst nach zwei grünen Fenstern wieder Features.

Zusammenfassung

SLIs, SLOs und Error Budgets machen Reliability für interne Plattform-Services messbar und steuerbar. SLIs messen Nutzer-Erlebnis (Build-Success, Provisioning-Zeit), nicht Infrastruktur-Gesundheit. Error Budgets entscheiden, wann Features und wann Stabilität Vorrang haben. Burn-Rate-Alerting und eine schriftliche Budget-Politik sind Voraussetzung — sonst bleibt das SLO eine Dashboard-Dekoration.

Wenn ein SLO verletzt wird, beginnt Incident Management — die nächste Lektion behandelt Severity, Kommunikation und Postmortems speziell für Platform Teams.