Neue Produktideen gefährden den Betrieb, wenn klare Fehlergrenzen fehlen

Error Budgets wirken auf den ersten Blick wie ein Spezialbegriff aus der Site-Reliability-Engineering-Welt. Im Kern geht es aber um eine sehr verständliche Managementfrage: Wie viel Unzuverlässigkeit darf ein digitaler Service verkraften, bevor Tempo, neue Funktionen und Experimente zurückstehen müssen? Für ITSM-Generalisten ist das kein exotisches Google-Konzept, sondern eine Brücke zwischen Service Level Management, Change Enablement, Incident Review und Produktsteuerung.

Der Ausgangspunkt ist ein Service Level Objective, kurz SLO. Ein SLO beschreibt ein konkretes Zuverlässigkeitsziel aus Nutzersicht, etwa erfolgreiche Anfragen, Antwortzeiten oder Verfügbarkeit über einen Zeitraum. Das Error Budget ist der bewusst akzeptierte Rest zwischen perfektem Betrieb und diesem Ziel. Wer zum Beispiel nicht absolute Perfektion verspricht, sondern ein belastbares Ziel steuert, schafft eine Grenze: Solange das Budget nicht verbraucht ist, kann ein Team mehr Veränderung wagen. Wenn das Budget brennt, muss Stabilität Vorrang bekommen.

Warum Verfügbarkeit allein zu wenig steuert

Viele Serviceberichte kennen eine grüne Verfügbarkeitszahl, die im Management gut aussieht und im Incident trotzdem wenig erklärt. Ein Monatswert von 99,9 Prozent kann verbergen, dass genau der wichtigste Nutzerpfad in einer kritischen Stunde schlecht lief. Umgekehrt kann eine einzelne Störung dramatisch wirken, obwohl der Service über den relevanten Zeitraum noch innerhalb eines bewusst vereinbarten Risikorahmens liegt. SLOs und Error Budgets zwingen deshalb zur Vorfrage: Was zählt aus Sicht der Nutzer wirklich?

Google beschreibt SLOs ausdrücklich als messbare Ziele für Zuverlässigkeit und Error Budgets als Mechanismus, um das Verhältnis zwischen Innovationstempo und Stabilität zu steuern. Für ITSM heißt das: Nicht jede technische Metrik gehört automatisch in ein Steuerungsboard. Entscheidend sind Service Level Indicators, die den erlebten Service abbilden. Ein API-Service braucht andere Signale als ein internes Reportingportal, ein Identitätsdienst andere als ein Batch-Prozess in der Nacht.

Das Budget macht Produktentscheidungen ehrlicher

Ohne Error Budget klingt Stabilität schnell wie eine abstrakte Forderung der Betriebsseite. Produktteams wollen liefern, Fachbereiche warten auf Funktionen, Plattformteams wollen Standards modernisieren und Security drängt auf Änderungen. In solchen Situationen hilft eine gemeinsame Betriebsgrenze. Wenn der Service sein Budget kaum verbraucht hat, spricht mehr für kontrolliertes Ausprobieren. Wenn das Budget nach mehreren Incidents fast weg ist, wird ein zusätzlicher riskanter Release nicht nur technisch, sondern fachlich erklärungsbedürftig.

Damit wird das Error Budget zu einem Gesprächsinstrument. Es ersetzt keine Führung, aber es nimmt der Diskussion die Beliebigkeit. Ein Change Advisory Board muss dann nicht jeden Release gleich behandeln. Es kann fragen: Wie nah ist dieser Service an seiner Zuverlässigkeitsgrenze? Welche Nutzerpfade sind betroffen? Welche Rollback-Optionen gibt es? Welche Risiken wurden seit dem letzten Incident noch nicht abgearbeitet? So entsteht eine sichtbare Verbindung zwischen Produktroadmap und Betriebsrealität.

Incident Reviews bekommen eine belastbare Folie

Nach Störungen wird oft über Ursache, Kommunikation und einzelne Maßnahmen gesprochen. Das ist wichtig, greift aber zu kurz, wenn unklar bleibt, wie stark der Service seine Zuverlässigkeitsreserve wirklich verbraucht hat. Ein Error Budget macht den Schaden operativ sichtbar. Es zeigt, ob eine Störung ein isolierter Ausreißer war oder ob sich ein Service systematisch an seine Grenze bewegt.

Für Problem Management ist das wertvoll. Wiederkehrende kleine Fehler können zusammengenommen relevanter sein als ein spektakulärer Einzelincident. Wenn sie das Budget regelmäßig auffressen, braucht der Service nicht noch mehr punktuelle Workarounds, sondern strukturelle Verbesserung: bessere Tests, weniger manuelle Übergaben, klarere Ownership, gezielteres Monitoring oder eine Reduktion riskanter Abhängigkeiten. Das Budget übersetzt wiederholte Reibung in eine Priorität, die auch außerhalb des Technikteams verständlich ist.

Die Gefahr liegt im falschen Ziel

Error Budgets funktionieren nur, wenn das zugrunde liegende SLO brauchbar ist. Ein zu grobes Ziel führt zu Scheinsicherheit. Ein zu strenges Ziel blockiert Veränderung, obwohl Nutzer keinen zusätzlichen Nutzen spüren. Ein rein technisches Ziel belohnt möglicherweise die falsche Optimierung. Deshalb gehört die Definition nicht allein in ein Observability-Team. Service Owner, Betrieb, Produkt, Support und gegebenenfalls Compliance müssen gemeinsam klären, welche Nutzererfahrung geschäftlich relevant ist.

Auch die Messung braucht Pflege. Wenn Monitoring nur Infrastrukturzustände erfasst, aber keine erfolgreichen Nutzeraktionen, wird das Budget schnell zur technischen Innenansicht. Wenn geplante Wartung, Drittanbieterfehler oder regionale Teilausfälle unklar behandelt werden, entstehen Streitpunkte genau dann, wenn Entscheidungen schnell fallen müssen. Gute Regeln legen deshalb vorab fest, welche Ereignisse zählen, wie Zeitfenster geschnitten werden, wer Ausnahmen freigibt und wie das Ergebnis berichtet wird.

Was ITSM-Teams praktisch vorbereiten können

Der Einstieg muss nicht mit einem großen SRE-Programm beginnen. Sinnvoll ist ein Pilot auf einem sichtbaren, aber begrenzten Service. Zuerst wird geklärt, welcher Nutzerpfad wirklich kritisch ist. Danach wird ein einfacher Indikator gewählt, etwa erfolgreiche Anmeldungen, abgeschlossene Transaktionen oder Antwortzeiten für eine zentrale API. Anschließend wird ein SLO formuliert, das anspruchsvoll, aber nicht unrealistisch ist. Erst daraus entsteht das Error Budget.

Wichtig ist der Anschluss an bestehende ITSM-Prozesse. Im Change-Prozess kann der Budgetstand als Risikosignal erscheinen. Im Major-Incident-Review kann er zeigen, ob Stabilitätsarbeit priorisiert werden muss. Im Service Review kann er erklären, warum ein Team vorübergehend weniger Features liefert. Im Continual Improvement Register kann er helfen, Verbesserungen nicht nach Lautstärke, sondern nach Servicewirkung zu sortieren.

Eine Grenze ist nur nützlich, wenn sie Konsequenzen hat

Das größte Risiko ist ein Error Budget ohne Wirkung. Wenn ein Team das Budget verbraucht und trotzdem unverändert weiterliefert, wird die Metrik zur Dekoration. Wenn jede Grenzüberschreitung automatisch einen vollständigen Lieferstopp auslöst, wird sie zum Bürokratiehammer. Beides hilft nicht. Nützlich wird das Modell erst, wenn vorher abgestufte Konsequenzen vereinbart sind: zusätzliche Reviews, kleinere Releasepakete, mehr Tests, temporäre Feature-Pausen, gezielte Resilienzarbeit oder ein Managemententscheid über bewusst akzeptiertes Risiko.

Für ITSM- und IT-Management-Generalisten liegt genau darin der Wert. Error Budgets machen Zuverlässigkeit verhandelbar, ohne sie beliebig zu machen. Sie zeigen, wann Geschwindigkeit fachlich vertretbar ist und wann ein Service zuerst Stabilität zurückgewinnen muss. Damit wird aus einer SRE-Metrik ein gemeinsamer Betriebsvertrag zwischen Produktidee, Servicequalität und Verantwortung.

Quellen: Google SRE Book zu Service Level Objectives und Embracing Risk; Google SRE Workbook zu Implementing SLOs und Alerting on SLOs.