Platform On-Call, Runbooks und Toil-Reduktion

Lernziele

Nach dieser Lektion kannst du erklären, warum On-Call für ein Platform-Team anders funktioniert als für ein Produkt-Team, wie ein Runbook aussehen muss, damit es um 3 Uhr nachts tatsächlich hilft, und wie du Toil definierst, misst und systematisch abbaust. Du kennst die Automatisierungsleiter vom dokumentierten Handgriff bis zur Self-Healing-Automation und kannst begründen, ab welcher Teamgröße eine eigene Rotation tragfähig ist.

Das Problem: Wenn die Plattform piept, piepen alle

Ein Stream-Team, das On-Call für seinen eigenen Service macht, hat einen begrenzten Blast Radius: Fällt der Checkout aus, ist der Checkout kaputt. Beim Platform-Team ist es umgekehrt. Fällt ingress-nginx, der GitOps-Controller oder die Container-Registry aus, sind alle Teams gleichzeitig betroffen — und alle melden sich gleichzeitig. Ein Platform-Incident ist fast immer ein Multi-Team-Incident.

Das hat zwei Konsequenzen. Erstens: Die Alert-Logik muss auf den Platform-SLOs aus Lektion 36 aufsetzen, nicht auf Maschinenmetriken. „Node-CPU bei 92 %” ist kein Page-Grund; „Sync-Latenz der GitOps-Pipeline verletzt das SLO und Deployments stauen sich” schon. Zweitens: Das Routing muss von Anfang an klären, wann das Platform-Team geweckt wird und wann ein Stream-Team. Sonst wird die Plattform-Rotation zum Auffangbecken für jeden Alert, den niemand zuordnen kann — der schnellste Weg, ein Platform-Team auszubrennen.

Eine bewährte Routing-Regel: Der Alert geht an das Team, das die Remediation ausführen kann. Pod-Crashloop einer Team-Anwendung → Stream-Team, auch wenn die Plattform den Alert technisch erzeugt. Degradierter Shared Ingress → Platform-Team, auch wenn ihn ein Stream-Team zuerst bemerkt. Diese Grenze ist genau die Shared-Responsibility-Frage, die in Lektion 41 systematisch behandelt wird.

Runbooks, die im Incident funktionieren

Die meisten Runbooks scheitern nicht an fehlendem Inhalt, sondern an falscher Form: Prosa-Wikiseiten, geschrieben von der Person, die das Problem ohnehin im Kopf hat. Ein brauchbares Runbook ist für die Person geschrieben, die das System nicht gebaut hat, und folgt einer festen Struktur:

1. Trigger: Welcher Alert führt hierher? (Verlinkt aus dem Alert selbst — ein Alert ohne Runbook-Link ist unvollständig.)
2. Impact: Wer ist betroffen, was sehen die Nutzer? Entscheidet über Eskalation und Kommunikation.
3. Diagnose: Konkrete, kopierbare Befehle mit erwartetem Output. Nicht „prüfe den Controller”, sondern kubectl -n ingress-nginx logs deploy/ingress-nginx-controller --since=15m | grep -i error.
4. Remediation: Die wahrscheinlichsten Ursachen mit je einer Gegenmaßnahme, geordnet nach Häufigkeit. Inklusive der Angabe, was davon gefahrlos wiederholbar ist.
5. Eskalation: Ab wann und an wen, mit Erreichbarkeit — nicht „im Zweifel Team X fragen”.

Zwei Betriebsregeln dazu: Jedes Runbook hat ein Review-Datum und einen Owner, sonst veraltet es leise — der dokumentierte Befehl funktioniert nach dem nächsten Upgrade (Lektion 38) nicht mehr, und das fällt erst im Incident auf. Und jedes Runbook wird mindestens einmal von jemandem durchgespielt, der es nicht geschrieben hat. Was diese Person stolpern lässt, lässt nachts um 3 Uhr alle stolpern.

Toil: definieren, messen, deckeln

Toil ist im SRE-Sinn Arbeit, die manuell, wiederkehrend, automatisierbar und ohne dauerhaften Wert ist — und die linear mit dem Wachstum der Plattform skaliert. Das Namespace-Anlegen per Ticket ist Toil. Das Schreiben des Controllers, der das automatisiert, ist es nicht, obwohl beides Arbeit ist. Die Unterscheidung ist wichtig, weil Toil bei Plattformen besonders gefährlich ist: Jedes neue Team bringt neue Tickets, und ohne Gegensteuern frisst der Betrieb irgendwann die gesamte Engineering-Kapazität.

Messen ist unspektakulär, aber notwendig: Ticket-Kategorien auswerten, Interrupts in der Rotation protokollieren, und in Retros schätzen lassen, wie viel Prozent der Woche auf wiederkehrende Handarbeit entfiel. Das SRE-Modell setzt eine Obergrenze von 50 % — wer dauerhaft darüber liegt, baut keine Plattform mehr, sondern betreibt nur noch.

Beim Abbauen hilft die Automatisierungsleiter: dokumentieren (Runbook) → skripten (ein Befehl statt zwölf) → Self-Service (das anfragende Team löst es selbst aus, z. B. über einen Golden Path aus Lektion 15/16) → autonom (das System remediert ohne Mensch, etwa ein Controller, der vollgelaufene PVCs erweitert). Wichtig: erst verstehen, dann automatisieren. Eine Automation, die eine halbverstandene Remediation blind ausführt, verwandelt einen kleinen Incident zuverlässig in einen großen.

Die Rotation: Mathematik gegen Burnout

Eine 24/7-Rotation braucht realistisch mindestens sechs bis acht Personen, sonst ist jede Person mehr als jede sechste Woche dran — auf Dauer nicht haltbar, und Urlaub oder Krankheit kippen den Plan sofort. Kleinere Platform-Teams haben drei ehrliche Optionen: Bereitschaft nur zu Geschäftszeiten plus dokumentiertes Best-Effort nachts, eine geteilte Rotation mit einem benachbarten Infrastruktur-Team, oder Follow-the-Sun, falls es Standorte in mehreren Zeitzonen gibt. Was nicht funktioniert: eine 24/7-Rotation mit drei Leuten auf dem Papier beschließen und hoffen.

Zur Hygiene gehört außerdem: Wer On-Call ist, ist in dieser Woche nicht voll im Feature-Plan verplant — Interrupts sind der Job, nicht die Störung. Und jeder Page wird hinterher klassifiziert: actionable oder nicht? Ein Alert, der dreimal hintereinander nicht actionable war, wird gelöscht oder umgebaut, nicht stummgeschaltet.

Praxis

Schreibe ein vollständiges Runbook für dieses Szenario: Argo CD meldet für mehrere Applications dauerhaft den Status Degraded, betroffene Teams berichten, dass Deployments nicht ankommen. Halte dich an die fünfteilige Struktur von oben. Vorgaben:

• Der Diagnose-Teil enthält mindestens vier kopierbare Befehle, darunter argocd app list --output wide, kubectl -n argocd get pods und einen Log-Befehl für den Application-Controller — jeweils mit einem Satz, was im Output gut bzw. schlecht aussieht.
• Der Remediation-Teil unterscheidet mindestens drei Ursachenklassen (Controller selbst ungesund; Ziel-Cluster nicht erreichbar; fehlerhaftes Manifest eines einzelnen Teams) und markiert, welche davon das Platform-Team löst und welche zurück ans Stream-Team gehen.
• Eskalationsteil mit konkretem Zeitlimit (z. B. „nach 20 Minuten ohne Hypothese → Secondary dazuholen”).

Lass das Runbook anschließend von jemandem (oder einem zweiten Blick mit Abstand) gegenlesen mit der Frage: Könnte ich das ohne Vorwissen ausführen?

Typische Stolperfallen

Alerts auf Ursachen statt Symptome: Wer auf CPU, Disk und Restarts pagt, weckt Menschen für Zustände, die niemand spürt — und übersieht den Ausfall, der sich in keiner Maschinenmetrik zeigt. Pages gehören auf SLO-Verletzungen, der Rest ist Dashboard-Material.

Runbooks ohne Verfallsdatum: Ein Runbook, das seit zwei Upgrades nicht angefasst wurde, ist im Incident gefährlicher als gar keins, weil es falsche Sicherheit gibt. Review-Datum und Owner sind Pflichtfelder.

Die Plattform-Rotation als Default-Empfänger: Jeder unklare Alert landet beim Platform-Team, „weil die das System kennen”. Nach drei Monaten besteht die Rotation nur noch aus Triage fremder Probleme. Routing-Regeln gehören explizit aufgeschrieben und durchgesetzt.

Automatisieren als Reflex: Ein Flaky-Verhalten per Cronjob „wegrestarten” beseitigt das Symptom und konserviert die Ursache — und irgendwann maskiert der Restart einen echten Ausfall. Automation gehört ans Ende der Leiter, nicht an den Anfang.

Interview-Vorbereitung

Auf die Standardfrage „Wie würdest du On-Call für ein Platform-Team aufsetzen?” antwortest du am stärksten entlang von vier Bausteinen: Besonderheit benennen (Plattform-Incident = Multi-Team-Incident, daher SLO-basierte Alerts und klares Routing) → Runbook-Disziplin (feste Struktur, Alert verlinkt Runbook, Reviews) → Toil-Management (Definition, Messung, 50-%-Deckel, Automatisierungsleiter) → Rotation realistisch dimensionieren (6–8 Personen für 24/7, sonst ehrliche Alternativen).

Typische Follow-ups:

• „Was ist Toil — und was ist es nicht?” — Manuell, wiederkehrend, automatisierbar, ohne dauerhaften Wert, skaliert mit der Plattform. Projektarbeit und Incident-Analyse sind kein Toil.
• „Wie bekämpfst du Alert Fatigue?” — Pages nur auf SLO-Verletzungen, jeder Page wird auf Actionability geprüft, nicht-actionable Alerts werden umgebaut oder gelöscht.
• „Wann automatisierst du eine Remediation?” — Wenn sie verstanden, dokumentiert und mehrfach manuell sicher ausgeführt wurde; vorher ist Automation Risikoverstärkung.
• „Page bei einem kaputten Deployment eines Teams — wer wird geweckt?” — Das Team, das remedieren kann: App-Problem → Stream-Team, Shared-Component → Platform-Team; die Grenze steht dokumentiert.

Zusammenfassung

Platform-On-Call unterscheidet sich vom Produkt-On-Call durch den Blast Radius: Ein Incident trifft alle Mandanten gleichzeitig, deshalb pagst du auf SLO-Verletzungen und routest Alerts an das Team, das handeln kann. Runbooks folgen einer festen Struktur mit kopierbaren Befehlen, Owner und Review-Datum. Toil misst du aktiv, deckelst du und baust ihn über die Leiter Dokumentation → Skript → Self-Service → Autonomie ab — in dieser Reihenfolge. Eine 24/7-Rotation braucht sechs bis acht Personen oder eine ehrliche Alternative.

Damit kannst du den Normalbetrieb. Die nächste Lektion behandelt den Ausnahmefall: Disaster Recovery — was passiert, wenn nicht eine Komponente ausfällt, sondern die Plattform selbst wiederhergestellt werden muss.