On-Call skaliert nicht über Cleverness, sondern über langweilige Disziplin. Nach einem Jahrzehnt Pager, drei Kontinenten und einem denkwürdigen Vorfall mit einem entgleisten Cron-Job in Ismailia ist das die Kurzliste, die ich neuen Rotationspartnern tatsächlich in die Hand drücke. Sie passt absichtlich auf eine Seite — sonst schreibt man ein Handbuch, das um 03:00 Uhr niemand liest.

Regel Nr. 1: Niemand liest

Um 03:00 Uhr liest du nicht. Du pattern-matchst. Runbooks, die davon ausgehen, dass du eine Textwand ruhig aufnimmst, schreiben Belletristik. Die Seiten, die ich geschrieben habe und die überlebt haben, haben drei Dinge: ein Symptom in einem Satz, den exakten Befehl, den man ausführt, und die exakte nächste Sache, die man prüft. Die Prosa-Variante landet innerhalb von sechs Monaten im Archiv, weil sie im Ernstfall niemand öffnet.

Wenn dein Runbook einen “Hintergrund”-Abschnitt hat, ist der für das zukünftige Du, nicht für das On-Call-Du. Ans Ende damit.

Regel Nr. 2: Die erste Handlung heißt “Leuten Bescheid geben”

Bevor du irgendetwas anfasst — bevor du rollbackst, bevor du den Pool skalierst, bevor du eine Node neustartest — postest du im Incident-Kanal. Zwei Zeilen: was du siehst und was du gleich tust. Mehr nicht.

Das fühlt sich nach Reibung an. Es ist Reibung. Es ist die billigste Reibung, die du je in dein On-Call einbauen wirst. Sie verhindert Drei-Engineers-Diagnosen, bei denen sich widersprechende Kommandos laufen und die Datenbank in vier Minuten zweimal neu gestartet wurde. Frag mich, woher ich das weiß.

Sortierte Liste, was du zuerst prüfst

Die Reihenfolge zählt. Wenn dein Dashboard diese fünf Dinge nicht binnen zweier Klicks zeigt, hast du ein Pre-Incident-Problem, das du ignorierst.

  1. Haben wir in der letzten Stunde deployed? 60 % deiner Pages sind das, und du weißt es. Rollback, dann debugge. Debug-dann-Rollback ist, wie man bei einem dreistündigen Ausfall und einem auffällig höflichen Slack-Thread über die Frage endet, wessen Change es denn nun war.
  2. Ist die Datenbank okay? CPU, Connection-Pool-Sättigung, Replication Lag. Die Datenbank ist fast immer das langsamste Glied im Request-Pfad und das, was am längsten zum Erholen braucht, wenn du sie verletzt.
  3. Ist es nur eine Region / AZ / Partition? Wenn das Ding kaputt aussieht, aber nur in eu-central-1 kaputt ist, dann liegt der Fehler vermutlich beim Load-Balancer, nicht im Code.
  4. Hat sich eine Upstream-API geändert? Anbieter deployen Breaking Changes werktags um 10 Uhr und tun so, als stünde es im Changelog.
  5. Hat sich das Traffic-Profil geändert? Irgendjemandes Integration ging live, und du nimmst jetzt das 40-fache an Requests entgegen. Prüf die Source-IP-Verteilung, bevor du einen Service umschreibst.

Findest du den Grund in diesen fünf Punkten nicht, verlangsam dich. Der nächste Schritt ist immer “Logs lesen, langsam, von außen nach innen” — nicht “raten und Dinge neustarten”.

Heldentaten sind ein Smell

Beim ersten Mal, als ich einen 14-Stunden-Incident allein durchstand und alle applaudierten, dachte ich, das sei der Job. Beim zehnten Mal merkte ich, dass ich ein System trug, das mehr Leute, schneller hätte pagen müssen.

Zeichen, dass du gerade Held statt Engineer bist:

  • Du bist der Einzige, der das Runbook versteht.
  • Deine Dashboards gibt es nur in deinen Bookmarks.
  • Du kennst den Fix aus dem Muskelgedächtnis — und hast ihn nie niedergeschrieben.
  • Du hast entschieden, nicht zu eskalieren, weil “ich mach’s eh schneller”.

Jedes davon ist ein Post-Incident-Action-Item. “Runbook dokumentieren”, “Dashboard in den gemeinsamen Ordner schieben”, “einen Abschnitt ins Training-Deck einfügen”. Deine Heldentaten sind Technical Debt. Zahl sie ab, bevor deine Rotation das ererbte Trauma einer anderen Person wird.

Der Pager ist keine Leistungsbeurteilung

Wenn du eine einzige Sache aus diesem Post mitnimmst: Der Pager feuert, weil Systeme versagen. Systeme versagen, weil Engineering schwer ist. Du bist nicht langsamer, schlechter oder weniger senior, nur weil der Pager dich geweckt hat. Du bist die Person, die aufgetaucht ist.

Das Anti-Muster sind Post-Incident-Reviews, die fragen: “Wer hätte das fangen müssen?” Die Antwort ist immer “das System” — das CI, der Test, der Alarm, das Guardrail, das Design-Review, das die richtige Frage nicht gestellt hat. Die “Wer”-Frage ist Scham-Theater, und sie macht den nächsten Incident schwieriger, weil Leute das Pagen hinauszögern, um nicht Namen-Benannt zu werden.

Konkrete Gewohnheiten, die mich bei Verstand halten

Das sind die langweiligen Dinge, die sich summieren:

  • Ich führe ein persönliches Pager-Logbuch. Zeit, Seite, was ich zuerst geprüft habe, was die tatsächliche Ursache war, was ich geprüft hätte, wenn ich’s gewusst hätte. Fünf Zeilen pro Incident. Nach einem Jahr zeigen sich Muster, die der offizielle Post-Mortem-Prozess verpasst.
  • Ich silence den Pager bewusst, nicht reflexhaft. Ist der Alert falsch, fixe ich den Alert in derselben Nacht. Silence ich ihn und vergesse es, wird er mich um 04:00 Uhr erneut wecken, und das habe ich dann verdient.
  • Ich behandle “gepaged, aber kein Incident” als Bug. Falsch-Pager sind ein P0-Operationsproblem, keine Volksabgabe. Normalisiert dein Team das Aufwachen für Non-Events, zerfällt deine Rotation langsam.
  • Ich mache die Übergabe schriftlich. Immer. “Nichts zu berichten” ist ein Satz. “Ich hab die 03:00-Page ignoriert, löst sich vermutlich selbst auf” ist eine Übergabe; “gute Nacht” ist Aufgeben.

Das Runbook-Template, das tatsächlich benutzt wird

## Symptom
<ein Satz, das, was der Pager gesagt hat>

## Sofortmaßnahme
<der Befehl, die Dashboard-URL oder das "eskaliere an X">

## Verifikation
<wie du weißt, dass es funktioniert hat>

## Nächste Schritte, falls es nicht funktioniert
<maximal drei Punkte, sortiert>

## Hintergrund
<alles andere — das Warum, die Historie, die Links>

Passen die oberen vier Abschnitte nicht auf einen Bildschirm, sind es zwei Runbooks, die vorgeben, eines zu sein. Teil sie.

Und zum Schluss: Schlaf

Du kannst dich nicht aus dem Schlafmangel herausengineeren. Weckt dich die Rotation öfter als einmal pro Quartal, ist das ein technisches Problem — kein persönliches Resilienz-Problem — und dein Job ist, es zu lösen, indem du das System leiser machst, nicht härter wirst.

Ich betreibe eine local-first Agent-Control-Plane (Fulcrum) teils deshalb, weil ich’s leid bin, zuzusehen, wie Teams dieselben Incident-Response-Gewohnheiten neu erfinden, die ich vor einem Jahrzehnt aufgeschrieben habe. Pager sind nicht der Feind. Der Feind ist die Organisation, die einen lauten Pager wie eine Persönlichkeitseigenschaft der Leute behandelt, die ihn tragen.