Meine erste On-Call-Schicht: Was kein Bootcamp lehrt

Letztes Jahr rief mich ein befreundeter DevOps-Engineer um 2:17 Uhr morgens an einem Dienstag an – direkt nach seiner ersten On-Call-Nacht. Slack-Alert: „KRITISCH – API-Gateway-Antwortzeit > 5 s – Produktion.“ Er starrte auf ein Grafana-Dashboard mit 14 Panels – und verstand nur drei. Niemand hatte ihm gesagt, dass On-Call nicht bedeutet, Probleme zu lösen. Es geht darum zu wissen, welches Problem man zuerst löst. Hier sind drei Lektionen aus dieser Nacht – Lektionen, die jeder Cloud-Engineer vor seiner ersten Schicht kennen sollte.

TL;DR

• Alert-Ermüdung ist die eigentliche On-Call-Herausforderung: Teams mit mehr als 100 Alerts pro Woche ignorieren rund 30 % der kritischen Benachrichtigungen (PagerDuty State of Digital Operations, 2025).
• Runbooks ohne regelmäßige Reviews und Game Days sind wertlos – sie beschreiben Systeme, die sich seit der letzten Aktualisierung verändert haben.
• Eine Postmortem-Kultur ist kein bürokratischer Mehraufwand – sie ist der einzige Weg, systematisch aus Vorfällen zu lernen, statt sie zu wiederholen.

2:17 Uhr: Der Moment, in dem nichts mehr wie im Tutorial funktioniert

Nennen wir meinen Freund Max. Er war seit sechs Monaten im Team. Er hatte Kubernetes-Cluster deployt, Helm-Charts geschrieben und CI/CD-Pipelines gebaut. Er fühlte sich bereit. Was er nicht wusste? Alles, was er gelernt hatte, galt für den Normalbetrieb. On-call beginnt genau dort, wo der Normalbetrieb endet.

Der Alert kam über PagerDuty, wurde nach Slack geroutet und gleichzeitig auf sein Telefon gepusht. Innerhalb von vier Minuten folgten sieben weitere Alerts – drei KRITISCH, zwei WARNUNG, zwei INFO. Max wusste nicht, welcher dieser sieben die Ursache war – und welche Kaskadeneffekte. Sein Grafana-Dashboard zeigte überall rote Linien, aber er konnte nicht sagen, ob der CPU-Spike die Latenz verursachte – oder nur ein Symptom davon war.

Nach 20 Minuten – und einem panischen Slack-Call mit dem Senior Engineer – war das Problem behoben: Ein Pod hatte sein Speicherlimit erreicht und befand sich in einer Restart-Schleife. Die Lösung? Eine einzeilige Änderung. Aber diese 20 Minuten Panik brachten Max mehr über Cloud-Operations bei als sechs Monate Routinearbeit je könnten.

Lektion 1: Signal vs. Rauschen – die eigentliche Arbeit passiert vor dem Vorfall

In dieser Nacht empfing Max 11 Alerts in 15 Minuten. Genau einer war relevant. Die anderen zehn waren entweder Downstream-Fehler – oder Alerts, die durch so niedrige Schwellwerte ausgelöst wurden, dass sie bei jeder kleinen Lastschwankung feuerten.

Was Max früher gewusst hätte: Alert-Tuning ist keine einmalige Setup-Aufgabe. Es ist ein fortlaufender Prozess. Jeder Alert, der nicht zu einer Aktion führt, ist Rauschen. Jeder Alert, der eine Aktion sollte – aber übersehen wird – ist ein Risiko. Das Signal-Rausch-Verhältnis zu verbessern, ist die wichtigste Arbeit vor dem ersten Vorfall – nicht der Bau von Dashboards.

Sein Tipp: Fragen Sie Ihr Team, welche Alerts der vergangenen 30 Tage tatsächlich zu einer konkreten Aktion geführt haben. Alle anderen gehören unter Review.

Lektion 2: Ein Runbook, das niemand geprüft hat, ist kein Runbook

Um 2:30 Uhr öffnete Max das Runbook. Es beschrieb eine Architektur, die drei Monate zuvor überarbeitet worden war. Der als „Single Point of Failure“ markierte Microservice existierte nicht mehr. Der als „primärer Health-Check-Endpunkt“ zitierte Load Balancer war vollständig ersetzt worden. Er folgte einer Dokumentation, die ihn aktiv in die Irre führte.

Was Max lernte: Game Days sind nicht nur nette Extras für Teams mit Zeit übrig. Sie sind der einzige Weg, um zu verifizieren, dass Runbooks funktionieren – bevor man sie im Krisenfall braucht. Sein Team führt jetzt alle sechs Wochen einen simulierten Vorfall durch. Seitdem bleibt das Runbook aktuell – weil jeder Game Day genau aufdeckt, wo die Dokumentation von der Realität abweicht.

Lektion 3: Eine Postmortem-Kultur spart Nerven – und Reputation

Am Tag nach dem Vorfall passierte etwas Unerwartetes: ein strukturiertes Postmortem. Kein Fingerpointing. Keine Schuldzuweisungen. Nur eine klare Timeline, Root Cause, Contributing Factors und Action Items – mit Eigentümern und Deadlines. Der Senior Engineer nutzte eine einseitige Vorlage mit fünf Abschnitten, die er über drei Jahre verfeinert hatte.

Das Postmortem deckte drei blinde Flecken auf, die niemand bemerkt hatte:
Erstens: Das Memory Leak bestand seit zwei Wochen – aber der zugehörige Alert war als „niedrige Priorität“ konfiguriert.
Zweitens: Der Eskalationspfad war unklar: Max wusste nicht, wann er den Senior Engineer anrufen durfte – oder sollte – statt zu versuchen, das Problem selbst zu lösen.
Drittens: Dem Onboarding-Prozess für neue On-Call-Mitglieder fehlte eine Shadowing-Phase.

Alle drei Action Items wurden in der folgenden Woche umgesetzt. Seitdem verbringt jedes neue Teammitglied eine Woche mit „Shadow-On-Call“, bevor es alleine in die Rotation eintritt. Das ist eine Woche pro Person. Sie spart Monate an Frustration.

Was Max heute anders macht

Zwei Jahre – und rund 50 On-Call-Nächte – später pflegt Max drei Gewohnheiten:
Er überprüft seine Alerts einmal pro Sprint – und löscht alle, die in den vergangenen 30 Tagen keine sinnvolle Aktion ausgelöst haben.
Er aktualisiert das Runbook nach jeder Architekturänderung – nicht nur nach Vorfällen.
Er schreibt nach jedem Vorfall ein Postmortem – auch wenn er „klein“ ist. Denn aus kleinen Vorfällen lernt man am meisten: Sie sind oft frühe Warnungen vor größeren.

Wenn Sie vor Ihrer ersten On-Call-Schicht stehen: Sie werden Fehler machen. Das ist nicht das Problem. Das Problem ist, wenn Ihrem Team die Struktur fehlt, um daraus zu lernen. Fragen Sie nach Game Days. Fragen Sie nach Incident-Response-Prozessen. Fragen Sie nach Shadow-On-Call. Wenn es nichts davon gibt? Bauen Sie es auf. Das ist der schnellste Weg vom Junior Engineer zur Person, die Ihr Team nachts anruft – nicht, weil Sie die beste Lösung kennen, sondern weil Sie den besten Prozess kennen.

Häufig gestellte Fragen

Header-Bildquelle: KI-generiertes Stimmungsbild (FLUX.2) – keine Produktdarstellung