Toil-Reduzierung nach SRE-Methoden: Wie Teams repetitive Betriebsarbeit systematisch durch Automatisierung ersetzen

Laptop mit Programmiercode auf dem Bildschirm – Bild von Kevin Ku via Pexels

In jedem IT-Team gibt es Aufgaben, die sich unaufhörlich wiederholen: manuelle Deployments, das Beantworten immer gleicher Infrastruktur-Anfragen über Ticket-Systeme, das händische Zurücksetzen von Fehlerzuständen, das Prüfen von Logs nach jedem nächtlichen Batch-Job. Diese Arbeit hat in der Welt des Site Reliability Engineering einen eigenen Namen: Toil.

Toil ist nicht einfach „Arbeit, die niemand mag". Es ist eine spezifische Kategorie von Aufgaben mit klaren Merkmalen – und SRE-Methoden bieten systematische Wege, diese Last sichtbar zu machen, zu messen und gezielt durch Automatisierung zu ersetzen.

Was Toil genau ist – und was nicht

Google definiert Toil in seinem SRE-Buch klar: Toil ist Arbeit, die mit dem Betrieb eines Produktionssystems zusammenhängt, manuell ausgeführt wird, wiederholbar ist, prinzipiell automatisierbar wäre, keinen dauerhaften Wert schafft und mit dem Wachstum des Systems linear skaliert.

Toil ist nicht dasselbe wie Overhead (Meetings, Planungsprozesse) oder Projektarbeit, die langfristigen technischen Wert schafft. Auch das Debuggen unbekannter Fehler ist kein Toil – das erfordert Urteilsvermögen und schafft Wissen. Toil ist die gut bekannte, schematische Aufgabe, die genauso läuft wie letztes Mal und das Mal davor.

Typische Toil-Situationen in IT-Teams

Manuelle Neustarts von Diensten nach bekanntem, immer gleichem Fehlermuster
Deployment-Checklisten, die Schritt für Schritt per Hand abgehakt werden
Benutzer-Onboarding mit immer gleichen Schritten: Account anlegen, Rechte vergeben, Einladung versenden
Wöchentliche Kapazitätsberichte manuell aus mehreren Systemen zusammenstellen
SSL-Zertifikate manuell prüfen, erneuern und Konfigurationen anpassen
Eskalationspfade beim On-Call-Rotationswechsel manuell einrichten
Log-Prüfung nach nächtlichen Batch-Jobs ohne automatisches Alerting

Toil messen: Der erste Schritt zur Reduktion

Was nicht gemessen wird, kann nicht systematisch reduziert werden. Toil zu messen ist ungewohnt – es erfordert, dass Teams ihre eigene Arbeitszeit kritisch analysieren. Eine einfache und bewährte Methode: Jede Aufgabe, die ein Teammitglied in einer Woche erledigt, wird einer von drei Kategorien zugeordnet:

Projektarbeit: Neue Funktionen, Systemverbesserungen, Kapazitätsplanung, Schuldenbehebung
Overhead: Meetings, Planungs- und Kommunikationsaufwand
Toil: Manuelle, wiederholbare Betriebsaufgaben ohne langfristigen Wert

Google empfiehlt, dass Toil maximal 50 % der Arbeitszeit eines SRE-Teams ausmachen sollte – mit dem expliziten Ziel, dauerhaft unter 20 % zu kommen. In vielen Teams liegt der tatsächliche Anteil deutlich höher, ohne dass das bewusst wahrgenommen wird. Die Erfassung über mehrere Wochen schafft Klarheit und gibt der Diskussion über Verbesserungen eine faktische Grundlage.

Priorisierung: Nicht alles Toil lohnt sofortige Automatisierung

Nicht jede Toil-Aufgabe sollte sofort automatisiert werden. Die Priorisierung richtet sich nach zwei Faktoren: Häufigkeit (wie oft tritt die Aufgabe auf?) und Aufwand pro Vorfall (wie viel Zeit kostet sie jedes Mal?). Eine einfache Matrix aus beiden Dimensionen zeigt schnell, wo Automatisierungsinvestitionen den größten Return bringen.

Hochfrequente, aufwendige Aufgaben sind die natürlichen ersten Kandidaten. Seltene, komplexe Aufgaben erfordern oft auch nach einer Automatisierung sorgfältige Prüfung – hier ist die Standardisierung und Dokumentation des manuellen Verfahrens oft der sinnvollere erste Schritt, bevor eine Automatisierung erstellt wird.

Konkrete Strategien zur Toil-Reduzierung

Automatisierung mit klar definiertem Scope

Automatisierung ist das wirksamste Mittel gegen Toil – aber nur wenn sie gut umgesetzt ist. Schlecht geschriebene Automatisierung erzeugt neues Toil: fehlerhafte Skripte, die gewartet werden müssen, ohne dass sie das ursprüngliche Problem verlässlich lösen. Bewährt ist ein schrittweises Vorgehen: zuerst das manuelle Verfahren klar dokumentieren, dann einzelne Schritte automatisieren, dann das Gesamtverfahren testen und validieren, und schließlich verantwortliche Ansprechpartner für die Automatisierung definieren.

Self-Service-Portale für Standardaufgaben

Viele Toil-Aufgaben entstehen, weil andere Teams das Betriebsteam als menschliches Interface für Infrastruktur-Operationen nutzen. Interne Entwicklerplattformen – auch bekannt als Internal Developer Portals – ermöglichen es, Standardaufgaben wie Umgebungsbereitstellung, Deployment-Auslösung oder Zugangsverwaltung in die Hände der anfragenden Teams zu legen. Das reduziert Toil beim Betriebsteam und beschleunigt Abläufe für alle Beteiligten erheblich.

Grundursachen beheben statt Symptome automatisieren

Wenn ein Dienst zweimal pro Woche manuell neugestartet werden muss, ist der Neustart Toil. Aber die eigentliche Lösung liegt im Beheben der Ursache, nicht im Automatisieren des Neustarts. Toil-Analyse deckt regelmäßig Probleme auf, die eigentlich technische Schulden sind und grundlegend behoben werden müssten. Die Automatisierung eines Workarounds verbirgt das zugrundeliegende Problem und macht es schwerer, es später zu adressieren.

Monitoring mit automatischer Selbstheilung

Modernes Monitoring ermöglicht automatisierte Reaktionen auf bekannte Fehlermuster: Wenn ein definierter Fehlerzustand erkannt wird, das Behebungsverfahren dokumentiert ist und die Aktion sicher und idempotent ausgeführt werden kann, lässt sich die Reaktion automatisch auslösen. Das ist kein Bereich für voreilende Automatisierung – es setzt voraus, dass das Heilungsverfahren erprobt, gut verstanden und sicher einzugrenzen ist. Der Umfang solcher automatischer Aktionen muss klar definiert und auditiert werden können.

Toil-Reduzierung als Kulturaufgabe

Toil-Reduzierung funktioniert nur, wenn das gesamte Team den Wert dahinter versteht und lebt. In Organisationen, die Aktivität mit Produktivität verwechseln, entstehen manchmal Bedenken: „Wenn wir alles automatisieren, was bleibt dann noch für uns zu tun?" Die Antwort ist klar: bessere Arbeit. Weniger Toil bedeutet mehr Zeit für Systemverbesserungen, Kapazitätsplanung, Resilienz-Engineering und die echte Auseinandersetzung mit technischer Schuld.

Teams, die regelmäßig analysieren, wie viel ihrer Arbeitszeit auf Toil entfällt, und diese Zahl aktiv reduzieren, sind zuverlässiger, entwickeln tieferes technisches Know-how und leiden weniger unter Burnout in On-Call-Rotationen. Toil-Tracking kann auch im Rahmen von Postmortem-Prozessen integriert werden: Welche Toil-Aufgaben wurden im Incident sichtbar? Welche davon lassen sich eliminieren?

Einstieg: Ein konkreter erster Schritt

Toil verschwindet nicht von selbst. Ohne aktive Auseinandersetzung wächst er mit dem System: mehr Dienste, mehr Deployments, mehr Nutzer – und damit mehr manuelle Betriebsaufgaben. Der Einstieg ist einfach: eine oder zwei Wochen lang aufschreiben, womit die eigene Arbeitszeit tatsächlich verbracht wird, und die Aufgaben kategorisieren. Die Erkenntnisse daraus setzen den ersten Hebel an – und liefern die Grundlage für eine rationale Priorisierung von Automatisierungsinvestitionen.

Toil-Reduzierung ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess, der in die normale Sprintplanung und retrospektive Betrachtung integriert werden sollte. SRE-Methoden geben dafür einen klaren Rahmen vor.

Bildquelle: Kevin Ku via Pexels