Mein erster On-Call-Dienst: Was mich kein Bootcamp vorbereitet hat

Ein befreundeter DevOps-Engineer rief mich letztes Jahr nach seiner ersten On-Call-Nacht an. 02:17 Uhr, Dienstag, Slack-Alert: “CRITICAL – API Gateway Response Time > 5s – Production”. Er starrte auf ein Grafana-Dashboard mit 14 Panels, verstand drei davon. Niemand hatte ihm erklärt, dass On-Call nicht bedeutet Probleme zu lösen – sondern zu wissen, welches Problem gerade das richtige ist. Drei Lektionen aus dieser Nacht, die jeder Cloud-Engineer vor seinem ersten Dienst kennen sollte.

Das Wichtigste in Kürze

• Alert Fatigue ist das eigentliche On-Call-Problem: Teams mit mehr als 100 Alerts pro Woche ignorieren im Schnitt 30 Prozent 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 dem letzten Update verändert haben.
• Postmortem-Kultur ist kein Bürokratie-Overhead, sondern die einzige Methode aus Incidents systematisch zu lernen statt sie zu wiederholen.

02:17 Uhr: Der Moment in dem nichts funktioniert wie im Tutorial

Mein Freund – nennen wir ihn Max – war seit sechs Monaten im Team. Er hatte Kubernetes-Cluster aufgesetzt, Helm Charts geschrieben und CI/CD-Pipelines gebaut. Er fühlte sich bereit. Was er nicht wusste: Alles was er gelernt hatte, war für den Normalbetrieb. On-Call beginnt da, wo der Normalbetrieb aufhört.

Der Alert kam über PagerDuty, wurde nach Slack geroutet und landete gleichzeitig als Push-Notification auf seinem Handy. In den nächsten vier Minuten folgten sieben weitere Alerts – drei davon CRITICAL, zwei WARNING, zwei INFO. Max hatte keine Ahnung welcher der sieben Alerts die Ursache war und welche Folgefehler. Sein Grafana-Dashboard zeigte rote Linien überall, aber er konnte nicht unterscheiden ob die CPU-Spitze die Ursache oder die Folge des Latenz-Problems war.

Nach 20 Minuten und einem panischen Slack-Call mit dem Senior Engineer war das Problem gelöst: Ein Pod hatte sein Memory-Limit erreicht und wurde in einer Restart-Loop gekillt. Die Lösung war ein Einzeiler. Aber die 20 Minuten Panik davor haben Max mehr über Cloud-Operations beigebracht als sechs Monate Normalbetrieb.

Lektion 1: Signal vs. Noise – die eigentliche Arbeit passiert VOR dem Incident

In dieser Nacht hatte Max 11 Alerts in 15 Minuten. Davon war genau einer relevant. Die anderen zehn waren Folgefehler oder Alerts mit zu niedrigen Schwellenwerten die bei jeder minimalen Last-Schwankung feuerten.

Was Max gerne vorher gewusst hätte: Alerting-Tuning ist keine Aufgabe die man einmal macht und dann vergisst. Es ist ein fortlaufender Prozess. Jeder Alert der nicht zu einer Handlung führt ist Rauschen. Jeder Alert der zu einer Handlung führen sollte aber untergegangen ist, ist ein Risiko. Die Signal-to-Noise-Ratio zu verbessern ist die wichtigste Arbeit vor dem ersten Incident – nicht das Einrichten von Dashboards.

Sein Tipp: Frag dein Team welche Alerts in den letzten 30 Tagen zu einer echten Handlung geführt haben. Alle anderen gehören auf den Prüfstand.

Lektion 2: Ein Runbook das niemand reviewed ist kein Runbook

Um 02:30 Uhr öffnete Max das Runbook. Es beschrieb eine Architektur die vor drei Monaten umgebaut worden war. Der Microservice der als “Single Point of Failure” markiert war existierte nicht mehr. Der Load Balancer der als “primärer Health-Check-Endpunkt” beschrieben war, war durch einen neuen ersetzt worden. Er hatte ein Dokument das aktiv irreführte.

Was Max daraus gelernt hat: Game Days sind keine Spielerei für Teams die zu viel Zeit haben. Sie sind der einzige Weg sicherzustellen, dass Runbooks funktionieren bevor man sie im Ernstfall braucht. Sein Team macht jetzt alle sechs Wochen einen simulierten Incident. Seitdem ist das Runbook aktuell – weil jeder Game Day die Stellen aufdeckt an denen die Dokumentation von der Realität abweicht.

Lektion 3: Postmortem-Kultur rettet Nerven und Reputation

Am Tag nach dem Incident passierte etwas das Max nicht erwartet hatte: ein strukturiertes Postmortem. Kein Finger-Pointing, keine Schuldzuweisungen. Stattdessen: Timeline, Root Cause, Contributing Factors, Action Items mit Owner und Deadline. Der Senior Engineer hatte eine Vorlage die er seit drei Jahren benutzte – fünf Abschnitte, eine Seite.

Das Postmortem deckte drei Dinge auf die niemand auf dem Schirm hatte: Erstens, der Memory-Leak existierte seit zwei Wochen, aber der zuständige Alert war als “low priority” konfiguriert. Zweitens, der Escalation-Pfad war unklar – Max wusste nicht wann er den Senior anrufen “darf” statt die Sache selbst zu lösen. Drittens, das Onboarding für neue On-Call-Mitglieder hatte keine Schattenschicht vorgesehen.

Alle drei Action Items wurden in der folgenden Woche umgesetzt. Seitdem macht jedes neue Teammitglied eine Woche “Shadow On-Call” mit bevor es alleine in die Rotation geht. Das kostet eine Woche pro Person. Es spart Monate an Frustration.

Was Max heute anders macht

Zwei Jahre und vermutlich 50 On-Call-Nächte später hat Max drei Gewohnheiten die geblieben sind: Er prüft seine Alerts einmal pro Sprint und löscht alles was in den letzten 30 Tagen nicht zu einer Handlung geführt hat. Er reviewed das Runbook nach jedem Architektur-Change – nicht nur nach Incidents. Er schreibt nach jedem Incident ein Postmortem, auch wenn der Incident “klein” war. Die kleinen Incidents sind die aus denen man am meisten lernt – weil sie die Vorboten der großen sind.

Wer vor seinem ersten On-Call steht: Du wirst Fehler machen. Das ist nicht das Problem. Das Problem ist wenn dein Team keine Struktur hat aus diesen Fehlern zu lernen. Frag nach Game Days, frag nach Incident-Response-Prozessen, frag nach Shadow On-Call. Wenn nichts davon existiert: Bau es auf. Das ist der schnellste Weg vom Junior zum Engineer den das Team nachts anruft – nicht weil du die beste Lösung kennst, sondern weil du den besten Prozess kennst.

Häufige Fragen

Image source: KI-generiertes Stimmungsbild (FLUX.2) – keine Produktabbildung

Translated from the German original using artificial intelligence. The German version is authoritative.