Katalog
concept#Zuverlässigkeit#Governance#DevOps#Observability

Error Budget Policy

Regelwerk, das die tolerierbare Fehlerquote eines Dienstes definiert und die organisatorischen Maßnahmen bei Überschreitung festlegt.

Eine Error Budget Policy definiert, wie viel Zuverlässigkeitsverlust ein Dienst innerhalb eines Zeitraums tolerieren darf und welche organisatorischen Maßnahmen bei Überschreitung greifen.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Organisatorisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

Monitoring-Systeme (z. B. Prometheus, Grafana)Incident-Management (z. B. PagerDuty, Opsgenie)CI/CD-Pipelines für Release-Gating

Prinzipien & Ziele

SLOs sind die Grundlage für jede Error-Budget-Entscheidung.Klare Eskalations- und Freigaberegeln verbinden Technik und Governance.Messbarkeit und Transparenz schaffen Vertrauen und Handlungsfähigkeit.
Betrieb
Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Falsche oder schlecht definierte SLIs verzerren Entscheidungen
  • Übermäßige Bürokratie durch zu rigide Policies
  • Teams umgehen Policies durch ungenügende Messung
  • Kleine, leicht messbare SLOs wählen
  • Automatisierte Alerts basierend auf Burnrate verwenden
  • Regelmäßige Reviews und Policy-Anpassungen durchführen

I/O & Ressourcen

  • Definition von SLOs, SLIs und Zeitfenstern
  • Zuverlässige Monitoring-Daten und Dashboards
  • Governance- und Escalation-Richtlinien
  • Entscheidungen zu Releases, Rollbacks oder Drosselungen
  • Priorisierte Stabilitätsmaßnahmen
  • Transparente Reports für Stakeholder

Beschreibung

Eine Error Budget Policy definiert, wie viel Zuverlässigkeitsverlust ein Dienst innerhalb eines Zeitraums tolerieren darf und welche organisatorischen Maßnahmen bei Überschreitung greifen. Sie verbindet SLOs mit Entscheidungsregeln für Releases, Priorisierung und Incident Response. Damit werden Risiken messbar gemacht und Governanceprozesse verankert.

✔

  • Balance zwischen Zuverlässigkeit und Geschwindigkeit
  • Klarere Entscheidungsgrundlage für Releases
  • Fördert datengetriebene Governance und Verantwortlichkeit

✖

  • Abhängig von qualitativem Monitoring und verlässlichen SLIs
  • Kann in sehr kurzen Zeitfenstern zu konservativen Entscheidungen führen
  • Erfordert disziplinierte Pflege von SLO-Definitionen

  • SLO-Compliance-Rate

    Anteil der Zeit, in der das SLO erfüllt wurde; zentrale Erfolgskontrolle.

  • Error-Burnrate

    Geschwindigkeit, mit der das Fehlerbudget verbraucht wird; Frühwarnindikator.

  • MTTR (Mean Time To Repair)

    Durchschnittliche Wiederherstellungszeit nach einem Incident; misst Reaktionsfähigkeit.

Google SRE Praxisbeispiel

Google verwendet Error Budgets zur Balance zwischen Zuverlässigkeit und Feature-Tempo in ihren Diensten.

Kleines Produktteam

Startup definiert einfache SLOs und blockiert Releases bei Budgetüberschreitung während Peak-Phasen.

E-Commerce-Plattform

Team priorisiert Bugfixes über neue Features, wenn die Error-Burnrate ein kritisches Level erreicht.

1

SLOs und SLIs für kritische Nutzerpfade definieren

2

Monitoring-Pipelines und Dashboards aufbauen

3

Policy-Regeln für Burnrate-Schwellen und Aktionen festlegen

4

Integrationen zu CI/CD und Incident-Management konfigurieren

⚠️ Technische Schulden & Engpässe

  • Unvollständige Instrumentierung führt zu unsicheren SLI-Werten
  • Manuelle Reports statt automatisierter Dashboards
  • Veraltete Runbooks und Eskalationspfade
Mangelnde SLI-QualitätFehlende Dashboard- oder Reporting-PipelinesUnklare Eskalationsprozesse
  • SLOs zu hoch ansetzen, um Störungen zu verschleiern
  • Fehlerbudget ignorieren und trotzdem Releases forcieren
  • SLIs aus nicht-repräsentativen Testdaten ableiten
  • Verwechslung von SLA (vertraglich) und SLO (intern)
  • Zu viele oder zu komplexe SLIs wählen
  • Keine automatisierten Messungen vorhanden
Kenntnis von SRE-Prinzipien und SLO-DesignMonitoring- und Observability-FähigkeitenOrganisatorische Kommunikation und Governance-Erfahrung
Verfügbarkeit von Monitoring- und Observability-ToolsKlare Servicebesitzer und VerantwortlichkeitenAutomatisierbarkeit von Release- und Gate-Entscheidungen
  • • Technische Fähigkeit zur Messung relevanter SLIs
  • • Organisatorische Zustimmung zu SLO-Werten
  • • Rechtliche oder Compliance-Anforderungen für Verfügbarkeit