Die Regel klingt einfach: Ein SRE verbringt weniger als die Hälfte seiner Zeit mit Toil, den Rest mit Engineering-Arbeit. Im selben Kapitel steht eine zweite Zahl, die selten zitiert wird. Quartalsweise Umfragen bei Google ergaben durchschnittlich rund 33% Toil — die Organisation lebt deutlich unter ihrem eigenen Limit. Die 50% sind dort kein Budget zum Ausschöpfen, sondern eine Grenze, ab der man nachsieht, was kaputt ist.
Und dann gibt es eine dritte Zahl, die unbequemste.
Die Obergrenze hat einen Boden
Rufbereitschaft erzeugt Toil, der sich nicht wegautomatisieren lässt, weil er aus Anwesenheit besteht. Das Buch rechnet es direkt vor: Bei einer Rotation aus sechs Personen übernimmt jede zwei von sechs Wochen — primary und secondary —, womit die Untergrenze bei 2/6 liegt, etwa 33%. Bei acht Personen sind es 2/8, 25%.
Aus derselben Formel folgt, was im Buch nicht steht. Vier Personen in Rufbereitschaft bei gleicher Schichtstruktur ergeben 2/4, exakt 50%. Das Team steht an der Obergrenze, bevor jemand die Ticket-Queue öffnet. Drei Personen ergeben 67%, und das ist kein Automatisierungsproblem mehr.
Die Einschränkung ist wesentlich: Die Rechnung zählt primary plus secondary. Wo keine zweite Linie existiert und eine Person die Schicht allein trägt, liegt die Grenze halb so hoch — 1/N. Trotzdem heißt 25% bei vier Personen, dass der Dienstplan die Hälfte des erlaubten Budgets bereits aufbraucht.
Für ein kleines Plattform-Team ist der Schluss unangenehm: „Wir haben zu viel Routine“ beschreibt oft die Größe der Rotation und nicht die Qualität der Werkzeuge. Kein Agent ändert 2/4.
Was ein KI-Agent wirklich abnimmt
Derselbe Text ordnet die Toil-Quellen. Ganz oben stehen nicht Incidents, sondern Unterbrechungen: nicht dringende Rückfragen zum Service, Mails und Nachrichten. Danach folgen dringende Reaktionen aus der Rufbereitschaft, und erst dann Releases und Rollouts.
Platz eins ist genau die Arbeit, die mit einer Untersuchung ohne Änderung endet. „Ist diese Version in Produktion angekommen?“, „warum startet der Pod neu“, „was hat sich in der letzten Stunde geändert“, „besteht der Drift auf diesem Cluster noch“. Die Antwort liegt bereits im Cluster, in den Metriken und in der Deployment-Historie; ein Mensch investiert Minuten plus einen Kontextwechsel, und das System bleibt danach im selben Zustand — die Toil-Definition ist vollständig erfüllt.
Ein Read-only-Agent passt hier: Er antwortet, ohne etwas zu verändern, und die Entscheidung bleibt beim Menschen. Die Mechanik dieses Zugriffs ist ein eigenes Thema; interessant ist hier die Buchhaltung.
Die Falle: „hier braucht es Urteilsvermögen“
Der übliche Weg, Arbeit aus dem Toil-Budget zu nehmen, lautet: Sie erfordert menschliches Urteilsvermögen. Das Buch schließt dieses Schlupfloch in einer Fußnote: Zu prüfen ist, ob das Urteil der Aufgabe innewohnt — oder ob es nötig wird, weil das System schlecht entworfen wurde. Ein Service, der mehrmals täglich jemanden für eine komplexe Reaktion aus der Rufbereitschaft holt, gilt dort als schlecht entworfen, und die Reaktion bleibt Toil, bis der Redesign ausgeliefert ist.
Daraus ergibt sich ein Risiko, das man besser vor der Einführung abwägt als danach. Ein Agent, der diese Analyse täglich anstelle eines Menschen ausführt, macht ein schlecht entworfenes System bequem. Der in Personenminuten gemessene Toil sinkt. Die Ursache bleibt, wo sie war, und der Druck zum Redesign verschwindet zusammen mit dem Schmerz.
Die praktische Folge steckt darin, was gezählt wird. Minuten zeigen eine Verbesserung, weil Minuten genau das sind, was der Agent übernommen hat. Zählen Sie die Anzahl der Untersuchungen: wie oft pro Woche jemand — Mensch oder Agent — herausfinden musste, warum das System in diesem Zustand ist. Diese Zahl bewegt sich nicht durch die Installation eines Agenten, wohl aber durch das Beheben der Ursache. Wie eine Metrik zum Ziel wird und aufhört zu funktionieren, habe ich separat behandelt.
Read-only ist kein Synonym für sicher
An einem Detail scheitern selbstgebaute Rollen. Die in Kubernetes eingebaute ClusterRole view verweigert Secrets bewusst: Wer den Inhalt eines Secrets liest, erhält ServiceAccount-Credentials und damit die Möglichkeit, die API unter dieser Identität aufzurufen. Die Dokumentation ordnet das der Privilege Escalation zu, nicht dem Lesen.
Eine handgebaute Rolle nach dem Muster „get, list, watch auf alles“ schließt Secrets ein. Auf dem Papier ist sie read-only, tatsächlich liefert sie dem Agenten Material, um unter fremder Identität zu handeln. Alles Gelesene landet zudem im Kontext des Modells — Logs, Umgebungsvariablen, Configs —, weshalb laute Alerts vor dem Anschluss eines Agenten repariert gehören und nicht danach (zu den Auslösemodi).
Was daraus folgt
Rechnen Sie Ihren eigenen Boden aus: Größe der Rotation, ob es eine secondary gibt. Liegt er nahe bei 50%, ist das Gespräch über Agenten verfrüht — zuerst der Dienstplan. Ist Luft vorhanden, geben Sie dem Agenten die Unterbrechungen: die größte einzelne Toil-Quelle und die einzige, bei der Lesen die Aufgabe vollständig löst. Und führen Sie eine eigene Zählung der Untersuchungen, damit eine behobene Ursache von einer sauber versteckten unterscheidbar bleibt.