SLA/SLO & Incident Response: Störungen professionell managen

Service Levels und Incident Response gehören zusammen: SLOs definieren, was „gut genug“ für Nutzer ist – Incident Response sorgt dafür, dass Sie auch bei Störungen schnell wieder dorthin zurückkehren. Ohne klare Ziele werden Alerts beliebig. Ohne geübte Response‑Prozesse bleiben SLOs Theorie.

Dieser Artikel erklärt die Begriffe SLA/SLO/SLI, zeigt, wie Error Budgets als Steuerungsinstrument funktionieren, und beschreibt einen praxistauglichen Incident‑Prozess inklusive Rollen, Kommunikation und Postmortems.

SLA, SLO und SLI: klare Begriffe, klare Steuerung

SLI (Service Level Indicator)

Ein SLI ist die messbare Kennzahl, z. B.:

• Verfügbarkeit (Successful Requests / Total Requests)

• Latenz (p95/p99) für eine definierte Request‑Klasse

• Fehlerrate (5xx, Timeouts, Business Errors)

Wichtig: SLIs müssen klar definieren, was gemessen wird (Endpoint/Operation), für wen (Nutzergruppe/Tenant), und wie aggregiert wird.

SLO (Service Level Objective)

Ein SLO ist ein internes Ziel, z. B.:

• „99,9% erfolgreiche Requests pro 30 Tage“

• „p95 Latenz < 300 ms für Checkout‑Requests“

SLOs sollten realistisch sein und den Nutzerimpact abbilden. Sie sind ein Steuerungsinstrument für Produkt, Engineering und Betrieb.

SLA (Service Level Agreement)

Ein SLA ist eine vertragliche Zusage. In der Praxis sollten SLAs konservativer als SLOs sein, weil:

• Messmethoden variieren können,

• Ausnahmen (Maintenance Windows) geregelt werden müssen,

• Vertragsstrafen und Kommunikation dranhängen.

Die Auswahl guter SLIs: „Messbar“ reicht nicht

Ein häufiger Fehler ist, nur Infrastruktur‑Metriken als „SLI“ zu verwenden (CPU, RAM). Das misst Ressourcen, aber nicht Nutzererlebnis. Bewährte Leitplanken:

• User‑Journey‑nah: SLIs auf zentrale Operationen (Login, Suche, Checkout, API‑Calls).

• Erreichbarkeit + Korrektheit: „Success“ muss fachlich sinnvoll definiert sein.

• Segmentierbar: nach Region, Tenant, Endpoint, Error‑Klasse.

• Manipulationssicher: nicht einfach „grün“ durch Wegfiltern.

Die technische Basis dafür liefert Observability:

• Monitoring & Observability

Error Budgets: der pragmatische Trade‑off zwischen Velocity und Reliability

Ein Error Budget ist der tolerierte Anteil „nicht gut“ innerhalb eines Zeitfensters:

• SLO 99,9% → Error Budget 0,1% (≈ 43 Minuten pro 30 Tage)

Das Budget ist kein Freifahrtschein, sondern ein Steuerungshebel:

• Budget vorhanden → Experimentieren/Release‑Frequenz möglich

• Budget sinkt schnell → Risiko reduzieren (z. B. kleinere Changes, stärkere Gates)

• Budget aufgebraucht → Fokus auf Reliability (Stabilisierung, Tech Debt, Hotspots)

Damit wird die Diskussion „mehr Features vs. mehr Stabilität“ objektivierbarer.

Alerting: Burn‑Rate statt Threshold‑Rauschen

SLO‑Alerting funktioniert besonders gut über Burn‑Rates: Wie schnell wird das Error Budget verbraucht?

Beispiele:

• schneller Burn (Sev1): Budget in 1 Stunde verbraucht → sofortiges Paging

• langsamer Burn (Sev2/3): Budget in 6–12 Stunden verbraucht → zeitnaher Fokus

Das reduziert Alert Fatigue und korreliert stärker mit realem Nutzerimpact.

Incident Response: ein praxistauglicher Prozess

1) Detection und Initiale Alarmierung

• SLO-/Signal‑basierte Alerts (nicht nur „CPU“)

• klare Routing‑Regeln (Service → Team → On‑Call)

Typische On‑Call Tools:

• PagerDuty: https://www.pagerduty.com/

• Opsgenie: https://www.atlassian.com/software/opsgenie

2) Triage und Severity

Definieren Sie Severity‑Stufen (z. B. Sev1–Sev4) mit eindeutigen Kriterien:

• Nutzerimpact (wie viele, wie stark)

• Business‑Impact (Umsatz, Kernprozess, regulatorisch)

• Workaround‑Verfügbarkeit

3) Rollen und Kommunikation

Bei größeren Incidents hilft Rollenklärung:

• Incident Commander (Koordination, Entscheidungen)

• Responder(s) (Diagnose/Fix)

• Comms Lead (Stakeholder‑Updates)

Transparente Kommunikation (intern/extern) verhindert Chaos. Ein Status‑Page‑System kann helfen:

• Statuspage: https://www.atlassian.com/software/statuspage

4) Mitigation (Time‑to‑Mitigate zählt)

Ziel: Impact schnell reduzieren, nicht sofort „perfekt fixen“. Typische Maßnahmen:

• Rollback oder Disable via Feature Toggle

• Traffic Shifting / Failover

• Rate Limiting / Degradation (z. B. weniger Features, stabile Kernfunktion)

5) Resolution und nachhaltige Behebung

Nach Stabilisierung folgt der dauerhafte Fix: Root Cause, Tests, Monitoring‑Verbesserung, technische Schulden adressieren.

6) Postmortem (blameless, aber konsequent)

Ein Postmortem ist dann wertvoll, wenn es konkrete Outcomes erzeugt:

• Timeline (was ist wann passiert)

• Root Cause + Contributing Factors

• Action Items mit Owner und Termin

• Verbesserungen an Alerts/Runbooks/Tests

Runbooks sind ein Kern‑Artefakt für On‑Call:

• Dokumentation & Runbooks

Verbindung zu Delivery: Incidents reduzieren heißt auch „besser deployen“

Viele Incidents sind Change‑getrieben. Deshalb gehören dazu:

• kleinere, häufigere Releases (weniger Risiko pro Change)

• CI/CD Quality Gates und sichere Deploy‑Strategien

• Patch‑ und Dependency‑Hygiene

Weiterführend:

• CI/CD-Pipeline-Aufbau

• Wartung & Patch Management

Beispiel-SLOs (damit der Start nicht abstrakt bleibt)

SLOs sollten sich auf wenige, kritische Nutzerpfade konzentrieren. Beispiele:

• API‑Service: „99,9% erfolgreiche Requests (2xx/3xx) über 30 Tage“ + „p95 Latenz < 300 ms für GET /orders“.

• Batch‑Job: „99% der Läufe enden innerhalb von 30 Minuten“ (und nicht nur „Job läuft“).

• Login: „99,95% erfolgreiche Logins“ (mit klarer Definition, was „erfolgreich“ ist).

Wichtig ist die Messdefinition: Welche Requests zählen, welche Ausnahmen gelten (Maintenance), und wie wird über Regionen/Tenants aggregiert. Gute SLOs sind präzise genug, um Alerts und Prioritäten daran auszurichten.

FAQ

Kann man ein SLA definieren, ohne SLOs zu haben?

Man kann, aber es wird schnell unpräzise: Ohne interne Ziele fehlt die Steuerbarkeit, und Incident‑Diskussionen werden politisch statt datenbasiert. SLOs sind meist die bessere operative Basis.

Wie viele SLOs pro Service sind sinnvoll?

Wenige. Oft reichen 1–2 pro Service (Success + Latency) für die kritischsten Operationen. Zu viele SLOs erzeugen Pflegeaufwand und verwässern Prioritäten.

Wie startet man On‑Call ohne Burnout?

Mit klaren Alerts (actionable), Runbooks, Rotation und Eskalationspfaden. Zudem hilft es, die häufigsten Incidents systematisch zu reduzieren (Postmortems, Fix‑Backlog).

Fazit

SLOs, Error Budgets und Incident Response sind kein Overhead, sondern Steuerung für zuverlässige IT. Mit gut definierten SLIs, sinnvollem Burn‑Rate‑Alerting, klaren Rollen und geübten Postmortems sinkt sowohl Ausfallzeit als auch Stress im Betrieb – und Delivery wird planbarer, weil Risiken messbar und beherrschbar werden.