TL;DR

Ein Error Budget definiert, wie viel Unzuverlässigkeit dein Service sich leisten darf. Es ergibt sich direkt aus dem SLO: Bei 99,9 % Verfügbarkeit bleiben 43,2 Minuten Downtime pro Monat. Burn-Rate-Alerts in Prometheus warnen frühzeitig, und eine klare Policy regelt, was passiert, wenn das Budget aufgebraucht ist.

Error Budgets für Kubernetes-Services

Dein Team diskutiert, ob das nächste Feature oder ein Stabilitäts-Fix Priorität hat. Ohne Daten endet das in Meinungen. Error Budgets liefern die Daten — eine messbare Grenze zwischen akzeptabler und inakzeptabler Unzuverlässigkeit.

Was ist ein Error Budget?

Das Error Budget ergibt sich direkt aus dem Service Level Objective (SLO):

Error Budget = 1 - SLO

Beispiel:
SLO = 99.9 % Verfügbarkeit
Error Budget = 0.1 % = 43.2 Minuten/Monat

Diese 43,2 Minuten sind das Budget, das dein Team für Deployments, Experimente und unvermeidbare Ausfälle ausgeben darf. Solange Budget übrig ist, hat Velocity Vorrang. Ist es aufgebraucht, hat Reliability Vorrang.

Error Budget berechnen mit Prometheus

Die Berechnung basiert auf zwei Metriken: erfolgreiche und gesamte Requests. Für einen Kubernetes-Service mit Istio oder einem Ingress-Controller sieht die PromQL so aus:

# Prometheus Recording Rules für Error Budget
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: error-budget-rules
  namespace: monitoring
spec:
  groups:
    - name: error-budget
      interval: 60s
      rules:
        # Erfolgsrate der letzten 30 Tage (rolling window)
        - record: slo:success_rate:30d
          expr: |
            sum(rate(http_requests_total{code=~"[2-4].*", namespace="production"}[30d]))
            /
            sum(rate(http_requests_total{namespace="production"}[30d]))

        # Verbrauchtes Error Budget (0 = nichts verbraucht, 1 = komplett aufgebraucht)
        - record: slo:error_budget_consumed:ratio
          expr: |
            1 - (
              (slo:success_rate:30d - 0.999)
              /
              (1 - 0.999)
            )

Die Metrik slo:error_budget_consumed:ratio zeigt den Verbrauch als Wert zwischen 0 und 1. Bei 0,75 sind 75 % des Budgets aufgebraucht.

Burn-Rate-Alerts konfigurieren

Ein einfacher Threshold-Alert reicht nicht. Burn-Rate-Alerts erkennen, wie schnell das Budget verbrannt wird, und warnen je nach Geschwindigkeit unterschiedlich.

# Burn-Rate-Alert-Rules
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: burn-rate-alerts
  namespace: monitoring
spec:
  groups:
    - name: burn-rate-alerts
      rules:
        # Schnelle Burn Rate: 14.4x über 5 Minuten UND 1 Stunde
        - alert: ErrorBudgetBurnCritical
          expr: |
            (
              1 - (sum(rate(http_requests_total{code=~"[2-4].*", namespace="production"}[5m]))
              / sum(rate(http_requests_total{namespace="production"}[5m])))
            ) > (14.4 * 0.001)
            and
            (
              1 - (sum(rate(http_requests_total{code=~"[2-4].*", namespace="production"}[1h]))
              / sum(rate(http_requests_total{namespace="production"}[1h])))
            ) > (14.4 * 0.001)
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "Error Budget wird 14.4x schneller verbrannt als erlaubt"
            description: "Bei dieser Rate ist das Error Budget in 2 Stunden aufgebraucht."

        # Langsame Burn Rate: 1x über 6 Stunden
        - alert: ErrorBudgetBurnSlow
          expr: |
            (
              1 - (sum(rate(http_requests_total{code=~"[2-4].*", namespace="production"}[6h]))
              / sum(rate(http_requests_total{namespace="production"}[6h])))
            ) > (1 * 0.001)
          for: 30m
          labels:
            severity: warning
          annotations:
            summary: "Error Budget wird stetig verbraucht"
            description: "Die aktuelle Fehlerrate übersteigt das erlaubte Niveau."

Die Kombination aus kurzem und langem Fenster (5 min + 1 h) verhindert False Positives bei kurzen Spikes.

Error Budget Policy definieren

Die Policy ist das wichtigste Dokument — sie legt fest, was passiert, wenn das Budget knapp wird. Ohne Policy sind Error Budgets nur Dashboards.

Stufe 1: Budget über 50 % verfügbar

Normaler Betrieb. Feature-Entwicklung hat Priorität. Das Team deployt nach eigenem Ermessen.

Stufe 2: Budget zwischen 20-50 %

Erhöhte Aufmerksamkeit. Jedes Deployment braucht ein Rollback-Plan. Canary-Deployments werden Pflicht. Das Team reviewt die größten Fehlerquellen der letzten Woche.

Stufe 3: Budget unter 20 %

Feature-Freeze. Nur noch Reliability-Arbeit und kritische Bugfixes. Das Team startet einen Reliability-Sprint mit folgenden Prioritäten:

1. Root-Cause-Analyse der größten Fehlerverursacher
2. Retry-Logik und Circuit Breaker überprüfen
3. Resource-Limits und HPA-Konfiguration anpassen
4. Chaos-Engineering-Tests für bekannte Schwachstellen

Stufe 4: Budget aufgebraucht (0 %)

Vollständiger Deployment-Stopp für Feature-Code. Alle Engineering-Kapazitäten fließen in Stabilität. Erst wenn das Budget im Rolling Window wieder über 20 % steigt, wird der Feature-Freeze aufgehoben.

Dashboard-Queries für Grafana

Diese PromQL-Queries zeigen den Error-Budget-Status in einem Grafana-Dashboard:

# Verbleibendes Error Budget in Prozent
(1 - slo:error_budget_consumed:ratio) * 100

# Error Budget in Minuten (bei 30-Tage-Window und 99.9% SLO)
(1 - slo:error_budget_consumed:ratio) * 43.2

# Aktuelle Burn Rate (Faktor)
(
  1 - (sum(rate(http_requests_total{code=~"[2-4].*"}[1h]))
  / sum(rate(http_requests_total{}[1h])))
) / 0.001

Error Budgets in der Praxis einführen

Fang klein an. Wähle einen Service, definiere ein SLO basierend auf historischen Daten, und beobachte das Error Budget vier Wochen lang ohne Policy. Erst wenn das Team ein Gefühl für die Zahlen hat, führst du die Policy-Stufen ein.

Häufiger Fehler: SLOs zu hoch ansetzen. Ein SLO von 99,99 % gibt dir nur 4,3 Minuten Error Budget pro Monat — das ist für die meisten internen Services unrealistisch. Starte lieber mit 99,5 % und verschärfe schrittweise.

FAQ

Wer entscheidet über das SLO?

Das SLO wird gemeinsam von Product und Engineering festgelegt. Product definiert, welche Zuverlässigkeit die Nutzer erwarten, Engineering bewertet, was realistisch erreichbar ist.

Was zählt als Fehler im Error Budget?

Alles, was gegen das SLO verstößt — typischerweise HTTP-5xx-Responses, Timeouts über einem definierten Threshold oder fehlgeschlagene Health-Checks. Die genaue Definition gehört ins SLO-Dokument.

Wie gehe ich mit geplanter Maintenance um?

Geplante Wartungsfenster sollten nicht vom Error Budget abgezogen werden, wenn sie vorab kommuniziert wurden. Nutze dafür Excluded-Windows in der SLO-Berechnung oder eine separate Metrik.

Funktionieren Error Budgets auch für interne Services?

Ja, gerade für interne Services sind Error Budgets wertvoll. Sie machen die Kosten von Instabilität sichtbar und helfen bei der Priorisierung zwischen Feature-Arbeit und technischer Schuld.

Wie oft sollte das SLO überprüft werden?

Quartalsweise. Überprüfe ob das SLO noch zu den Nutzer-Erwartungen passt und ob die Error-Budget-Policy realistisch ist. Passe bei Bedarf an — ein SLO ist kein Vertrag, sondern ein Steuerungsinstrument.