Site Reliability Engineers verbringen einen erheblichen Teil ihrer Zeit mit Arbeit, die keinen dauerhaften Mehrwert schafft: manuelle Deployments, wiederkehrende Ueberpruefungen, das Zuruecksetzen von Flags, das Anpassen von Konfigurationen nach jedem Release. Diese Art von Arbeit hat einen Namen: Toil. Und im SRE-Kontext ist Toil nicht einfach ein Aergernis, sondern ein messbares Problem mit klaren Konsequenzen.
Was Toil im SRE-Kontext bedeutet
Der Begriff wurde durch das Google SRE Book gepraegte und beschreibt eine ganz bestimmte Art von Arbeit: Sie ist manuell, repetitiv, automatisierbar und skaliert linear mit dem Wachstum des Systems. Was sie von sonstiger Betriebsarbeit unterscheidet, ist das Fehlen nachhaltigen Werts. Toil muss immer wieder gemacht werden, ohne dass das System dadurch dauerhaft besser wird.
Beispiele fuer typischen Toil:
- Manuelles Neustarten von Diensten nach bestimmten Fehlern
- Regelmaessige, manuelle Rotationen von Credentials oder Zertifikaten ohne automatisierten Prozess
- Antworten auf immer gleiche Monitoring-Alerts, die keine wirkliche Untersuchung erfordern
- Deployment-Schritte, die nicht vollstaendig automatisiert sind und menschliche Eingriffe benoetigen
- Datenbankabfragen oder -korrekturen, die nach jedem Release manuell ausgefuehrt werden
Warum Toil ein messbares Problem ist
Google empfiehlt, dass SREs nicht mehr als 50 Prozent ihrer Arbeitszeit mit Toil verbringen sollten. Wer dauerhaft darueber liegt, verliert Kapazitaet fuer die eigentliche Aufgabe: die Zuverlaessigkeit von Systemen durch technische Arbeit nachhaltig zu verbessern.
Toil hat eine problematische Eigenschaft: Er skaliert mit dem System. Je mehr Services, Nutzer und Deployments, desto mehr manueller Aufwand entsteht – ausser, er wird systematisch adressiert. Teams, die Toil nicht aktiv reduzieren, wachsen in eine Situation hinein, in der sie immer mehr Zeit mit Betrieb verbringen und immer weniger mit Verbesserung.
Toil ist nicht dasselbe wie schwere Arbeit. Es ist die Arbeit, die immer gleich ist – und genau deshalb automatisiert werden kann.
Toil erkennen: Eine ehrliche Bestandsaufnahme
Bevor Toil reduziert werden kann, muss er erkannt werden. Viele Teams haben Toil so normalisiert, dass er nicht mehr als Problem wahrgenommen wird, sondern als selbstverstaendlicher Teil des Betriebs.
Eine einfache Methode zur Bestandsaufnahme: Fuer zwei bis vier Wochen protokollieren, wie viel Zeit fuer welche Aufgaben aufgewendet wird. Dabei gezielt nach folgenden Mustern suchen:
- Aufgaben, die jede Woche oder bei jedem Release wiederholt werden
- Schritte, fuer die ein Runbook existiert – und die immer exakt nach Runbook ausgefuehrt werden
- Alerts, die regelmaessig ausgeloest werden und immer mit denselben Handlungen beantwortet werden
- Anfragen aus anderen Teams, die immer gleich beantwortet werden
Strategien zur Toil-Reduktion
Toil kann auf verschiedenen Wegen reduziert werden. Welche Strategie passt, haengt von der Art des Toil und den verfuegbaren Ressourcen ab.
Automatisierung
Die naheliegendste Strategie: Manuelle Schritte durch automatisierte Prozesse ersetzen. Das kann eine Skriptloesung sein, ein CI/CD-Pipeline-Schritt oder eine Scheduler-Aufgabe. Der Schluessel liegt darin, nicht jeden Toil sofort perfekt zu automatisieren, sondern mit den haeufigsten und zeitintensivsten zu beginnen.
Alert-Bereinigung
Viele Teams haben Alerts, die regelmaessig feuern, aber keine nuetzliche Information liefern – oder immer mit denselben Schritten beantwortet werden. Solche Alerts sind Toil. Die richtige Reaktion ist nicht, sie weiter zu beantworten, sondern entweder die Ursache dauerhaft zu beheben oder den Alert zu entfernen, wenn er keinen Mehrwert hat.
Runbooks automatisierbar machen
Wenn ein Runbook so praezise ist, dass jeder Schritt exakt vorhersehbar ist, ist das ein klares Signal: Dieser Prozess kann automatisiert werden. Runbooks sind kein Ziel, sondern ein Zwischenschritt. Gut gepflegte Runbooks machen Automatisierung einfacher, weil der Prozess bereits dokumentiert ist.
Self-Service fuer andere Teams
Wiederkehrende Anfragen aus anderen Teams – etwa das Anlegen von Ressourcen oder das Zuruecksetzen von Zugangsdaten – koennen durch Self-Service-Prozesse adressiert werden. Statt manuell jede Anfrage zu bearbeiten, werden Werkzeuge bereitgestellt, die Teams unabhaengig machen.
KI als Toil-Reduzierer
Sprachmodelle und KI-gestuetzte Tools bieten neue Moeglichkeiten, Toil zu reduzieren – vor allem im Bereich Diagnose und Dokumentation. KI kann helfen bei:
- Der automatischen Analyse von Logs und Fehlermustern
- Dem Vorschlagen von Massnahmen auf Basis bekannter Runbooks
- Der Erstellung von Incident-Zusammenfassungen und Handoffs
- Dem Beantworten einfacher, wiederkehrender Anfragen in Self-Service-Workflows
KI ersetzt dabei keine Verantwortung, aber sie kann die Zeit, die fuer repetitive kognitive Arbeit aufgewendet wird, deutlich senken. Wenn ein Alert ausgeloest wird, der in der Vergangenheit immer auf dasselbe Muster zurueckging, kann ein KI-System direkt eine vorgeschlagene Diagnose und erste Schritte liefern – ohne dass jemand manuell in Dashboards navigieren muss.
Toil und Error Budgets
Im SRE-Modell haengt Toil eng mit Error Budgets zusammen. Wenn ein Team dauerhaft ueber 50 Prozent seiner Zeit mit Toil verbringt, ist weniger Kapazitaet fuer Zuverlaessigkeitsarbeit vorhanden. Das erhoeht das Risiko, dass Reliability-Probleme laenger unbehandelt bleiben, was wiederum das Error Budget schneller aufbraucht.
Eine pragmatische Sichtweise: Hoher Toil-Anteil ist ein Signal dafuer, dass das System nicht gut genug automatisiert ist, um nachhaltigen Betrieb zu ermoeglichen. Die Reduktion von Toil ist deshalb keine Optimierung – sie ist eine Voraussetzung fuer stabile SLOs.
Praktisch anfangen: Ein kleiner Schritt genuegt
Der haeufigste Fehler bei der Toil-Reduktion ist der Anspruch, alles auf einmal zu automatisieren. Das fuehrt zu aufwaendigen Projekten, die nie abgeschlossen werden. Besser: Pro Sprint einen konkreten Toil identifizieren, der viel Zeit kostet und vergleichsweise einfach zu automatisieren ist. Nach drei bis vier Sprints ergibt sich bereits eine messbare Verbesserung.
Wer automatisierte Prozesse einsetzt, um manuellen Toil zu ersetzen, sollte diese Prozesse selbst beobachtbar machen. Mit FreshCore lassen sich Heartbeat-Monitore einrichten: Wenn ein Cronjob oder Skript, das Toil-Aufgaben uebernimmt, nicht mehr laeuft, schlaegt der Heartbeat-Monitor Alarm. So bleibt Automatisierung sichtbar – auch ohne manuellen Eingriff.
Fazit
Toil ist unvermeidlich, aber nicht unbegrenzt. Teams, die ihn aktiv messen, priorisieren und systematisch reduzieren, schaffen Kapazitaet fuer Arbeit, die das System dauerhaft besser macht. Das ist der Kern von Site Reliability Engineering: nicht nur Braende loeschen, sondern verhindern, dass sie entstehen.
Quellen: Google SRE Book (O Reilly), Kapitel Eliminating Toil; Google SRE Workbook, Kapitel On-Call; Niall Murphy, Betsy Beyer et al.
