Ich habe im März 2024 versucht, Urlaub zu machen. Hat vier Tage gedauert.

Am zweiten Tag habe ich 'nur eine kurze Frage" auf Slack beantwortet. Am dritten Tag saß ich in der Hotellobby und debuggte ein Produktionsproblem — ein Fehler auf unseren Live-Servern, die echte Kunden bedienen. Am vierten Tag sagte meine bessere Hälfte: 'Fahr einfach zurück zur Arbeit. Das ist kein Urlaub." Recht hatte sie.

Das Problem war nicht mein Team. Die waren kompetent. Das Problem war, dass mein Kopf die einzige Kopie der halben Betriebsabläufe enthielt. Deploy-Prozedur? In meinem Kopf. Eskalationsprozess bei Kundenbeschwerden? In meinem Kopf. Wie man den Billing-Service neustartet, wenn er hängt? Auch in meinem Kopf. Ich war nicht unersetzlich, weil ich so brillant war. Ich war unersetzlich, weil ich nichts aufgeschrieben hatte.

Sechs Monate später, im September 2024, nahm ich zwei volle Wochen frei. Kein Laptop. Kein Slack. Keine 'kurzen Calls." Nichts ging kaputt.

Hier ist, was ich in diesen sechs Monaten gemacht habe.

Schritt 1: Finde deinen Bus-Faktor

'Bus-Faktor" — eine morbide, aber nützliche Kennzahl: Wie viele Leute in deinem Team müssten verschwinden, bevor ein Prozess komplett stillsteht? Wenn die Antwort 'eine Person" ist und diese Person du bist, hast du kein System. Du hast eine Geiselnahme.

Ich habe jede wiederkehrende Aufgabe aufgelistet, die bei mir lag, und eine einzige Frage gestellt: 'Wenn ich morgen vom Erdboden verschwinde — wer könnte das übernehmen?"

Aufgabe Bus-Faktor Wer weiß noch Bescheid?
Produktions-Deploys 1 (ich) Niemand
Billing-Probleme bei Kunden 1 (ich) Niemand
Reaktion auf Server-Monitoring 1 (ich) Niemand
Sprint-Planung 2 Co-Lead
Code Reviews 3 Jeder Senior Dev
Bewerbungsgespräche 2 Co-Lead

Drei kritische Prozesse mit Bus-Faktor 1. Drei Dinge, die komplett stillstehen würden, wenn ich mir eine Lebensmittelvergiftung einfange. Das ist kein Betrieb. Das ist eine One-Man-Show im Team-Kostüm.

Das Konzept stammt aus der Open-Source-Kultur, wo Projekte mit der Anzahl der Contributors stehen und fallen. Der Wikipedia-Artikel zum Bus-Faktor listet Beispiele aus großen Tech-Unternehmen — gleiches Problem, größerer Maßstab.

Schritt 2: Schreib Runbooks, keine Dokumentation

Der Unterschied ist wichtig. Dokumentation erklärt, wie etwas funktioniert. Ein Runbook — ein operatives Handbuch, eine Schritt-für-Schritt-Anleitung für eine bestimmte Situation — erklärt, was zu tun ist.

Dokumentation: 'Der Billing-Service nutzt Stripe Webhooks (automatische Benachrichtigungen, die Stripe bei Zahlungsereignissen sendet), um Zahlungen zu verarbeiten. Events werden in Redis gequeued und vom Billing Worker verarbeitet."

Runbook: 'Wenn Billing hängt: 1) Redis-Queue-Länge prüfen: redis-cli llen billing_queue. 2) Wenn Queue > 100, Billing Worker neustarten: systemctl restart billing-worker. 3) Wenn die Queue sich nicht innerhalb von 5 Minuten leert, Stripe Dashboard auf fehlgeschlagene Webhooks prüfen."

Siehst du den Unterschied? Dokumentation erfordert Verständnis. Ein Runbook erfordert das Befolgen von Anweisungen. Jeder, der Befehle in ein Terminal eintippen kann — die textbasierte Oberfläche, in der man Kommandos direkt eingibt — kann ein Runbook abarbeiten. Man muss nicht verstehen, warum Redis (eine schnelle In-Memory-Datenbank, die häufig als Message Queue eingesetzt wird) im Spiel ist. Man muss nur wissen, was man eintippen soll.

PagerDuty, ein Unternehmen, das sein gesamtes Geschäftsmodell um Incident Response aufgebaut hat, hat einen soliden Leitfaden zum Schreiben von Runbooks veröffentlicht, der genau dieses Prinzip beschreibt: Optimiere für Handlung, nicht für Verständnis.

Ich habe für alle drei Bus-Faktor-1-Prozesse Runbooks geschrieben. Jedes hat 30–60 Minuten gedauert. Hier ist das Format:

Runbook: Produktions-Deploy

Wann verwenden:
Beim Merge in main und Deploy auf Produktion.

Voraussetzungen:
- SSH-Zugang zum Prod-Server (bei der IT anfragen, falls nicht vorhanden)
- Zugang zum #deploys Slack-Channel

Schritte:
1. PR in main mergen
2. Warten, bis CI-Checks durchlaufen (GitHub Actions, ~5 Min)
3. SSH zum Server: ssh [email protected]
4. Ausführen: bash /srv/app/deploy.sh
5. Health-Check: curl -s http://localhost:8080/health | jq .
6. Wenn Health-Check fehlschlägt: bash /srv/app/rollback.sh
7. Ergebnis in #deploys posten

Wenn etwas schiefgeht:
- Deploy-Script schlägt fehl → Logs prüfen unter /var/log/deploys/
- Health-Check liefert 503 → in der JSON-Antwort prüfen, welches Subsystem ausgefallen ist
- SSH geht nicht → IT kontaktieren, VPN prüfen
- Rollback schlägt fehl → Capitan anrufen. Nicht Slack. Telefon.

Eskalation:
Wenn man länger als 15 Minuten feststeckt, Capitan anrufen. Telefon, nicht Slack.

Keine Theorie. Keine Architekturdiagramme. Einfach nur: 'Wenn das passiert, mach das."

Schritt 3: Die Schatten-Woche

Runbooks schreiben reicht nicht. Du musst sie an echten Menschen testen.

Ich habe eine 'Schatten-Woche" durchgeführt — eine Woche, in der ich erreichbar blieb, aber keinen der drei Prozesse selbst angefasst habe. Jemand anderes hat das Runbook befolgt. Ich habe zugeschaut.

Ergebnisse:

  • Deploy-Runbook: Funktionierte beim ersten Versuch. Der Kollege fand einen Tippfehler in Schritt 4 (falscher Dateipfad). In zwei Minuten gefixt.
  • Billing-Runbook: Scheiterte bei Schritt 3. Ich hatte 'Stripe Dashboard prüfen" geschrieben, aber nie erklärt, wie man sich einloggt. Die Zugangsdaten lagen in meinem persönlichen Passwort-Manager, nicht im geteilten. Shared Access eingerichtet — Problem gelöst.
  • Monitoring-Runbook: Funktionierte teilweise. Die Schritte stimmten, aber die UI des Monitoring-Tools hatte sich geändert, seit ich das Dokument geschrieben hatte. Screenshots aktualisiert.

Jedes einzelne Runbook brauchte mindestens eine Korrektur. Das ist normal. Wenn du aus dem Gedächtnis schreibst, überspringst du Schritte, die dir 'offensichtlich" vorkommen, weil du sie schon 500-mal gemacht hast. Die Schatten-Woche deckt diese Lücken auf, bevor sie um 3 Uhr morgens am Samstag relevant werden.

Googles SRE-Team — die Gruppe, die dafür verantwortlich ist, Googles Infrastruktur am Laufen zu halten — beschreibt dieses Prinzip in ihrem kostenlosen Site Reliability Engineering Buch: Dokumentation, die nicht unter realen Bedingungen getestet wurde, ist Fiktion.

Schritt 4: Das Wissenstransfer-Meeting

Für jedes Runbook habe ich eine 30-minütige Wissenstransfer-Sitzung abgehalten. Kein Training — Transfer. Training vermittelt Fähigkeiten. Transfer vermittelt Kontext.

Aufbau:

  1. Runbook gemeinsam durchgehen (10 Min) — die Person folgt jedem Schritt, während ich zuschaue. Keine Hilfe, solange sie nicht feststeckt.
  2. Das 'Warum" hinter kritischen Schritten erklären (10 Min) — nicht nötig für die Ausführung, aber hilft bei Ermessensentscheidungen. 'Wir starten den Billing Worker zuerst neu, bevor wir untersuchen, weil Downtime X Euro pro Minute kostet. Erst Geschwindigkeit, dann Ursachenforschung."
  3. Fragen und Antworten (10 Min) — ihre Fragen zeigen dir exakt, was du vergessen hast zu dokumentieren.

Nach dem Meeting gehört ihnen der Prozess. Nicht 'bei dem Prozess helfen." Ihnen gehört er. Ich werde zum Backup, nicht zum Primärkontakt.

Schritt 5: Der Urlaubstest

Zwei Monate nach der Schatten-Woche nahm ich ein verlängertes Wochenende ohne Laptop. Keine Notfälle. Keine 'kurzen Fragen." Die Runbooks hielten.

Einen Monat später: eine volle Woche frei. Ein kleines Problem: Das Monitoring-Runbook deckte einen bestimmten Randfall nicht ab — Festplatte voll auf einer nicht-standardmäßigen Partition. Die Person im Bereitschaftsdienst improvisierte richtig und ergänzte den Fall anschließend im Runbook. Das System verbesserte sich ohne mich. Das ist das Zeichen, dass es funktioniert.

Einen Monat danach: zwei volle Wochen. Null Vorfälle, die mein Eingreifen erforderten. Das Team schickte mir ein Foto von einem Whiteboard: 'Tag 9: Capitan hat nicht angerufen. Wir glauben, das System funktioniert."

Der Teil, über den niemand spricht

Sich selbst aus Prozessen herauszuschreiben fühlt sich an, als würde man sich entbehrlich machen. Genau das ist es. Das ist der Punkt.

Aber es triggert etwas Unbequemes — den Teil deiner Identität, der an 'die Person, die alles weiß" gekoppelt ist. Die Person, die alle anrufen. Die Person, die den Tag rettet.

Ich bin ehrlich: Es fühlte sich seltsam an, als Deploys ohne mich liefen. Als Billing-Probleme ohne eine Nachricht an mich gelöst wurden. Als der Server-Alert feuerte und jemand anderes das in 8 Minuten erledigt hatte. Ein Teil von mir wollte gebraucht werden.

Hier ist, was ich stattdessen bekam: Freiheit. Nicht nur Urlaubsfreiheit — tägliche Freiheit. Ich war kein Bottleneck mehr — nicht mehr der einzelne Punkt, an dem sich alle Entscheidungen aufstauten und warteten. Arbeit, die sich vorher hinter mir ansammelte, passierte jetzt in Echtzeit. Das Team wurde schneller. Ich konzentrierte mich auf Entscheidungen, die tatsächlich mein Urteilsvermögen erforderten, statt auf Aufgaben, die nur mein Gedächtnis erforderten.

Deine Aktionsliste

Stand März 2026 habe ich diesen Prozess bei drei verschiedenen Organisationen wiederholt. Das Muster funktioniert jedes Mal. Wenn du keine zwei Wochen frei nehmen kannst, ohne dass alles zusammenbricht, hast du kein System — du hast die Angewohnheit, beschäftigt zu sein.

Hier ist deine Checkliste:

  1. Bus-Faktor auditieren — jede wiederkehrende Aufgabe auflisten, markieren, wer sie sonst noch kann
  2. Runbooks schreiben für alles mit Bus-Faktor = 1 (plane 30–60 Minuten pro Runbook ein)
  3. Schatten-Woche durchführen — jemand anderes führt aus, du schaust zu und korrigierst die Docs
  4. Wissenstransfer-Meetings abhalten — 30 Minuten pro Prozess, strukturiert
  5. Mit echtem Urlaub testen — erst verlängertes Wochenende, dann eine Woche, dann zwei

Schreib das Runbook. Mach die Schatten-Woche. Nimm den Urlaub.

Du kommst erholt zurück, und das Team ist leistungsfähiger als vorher. Das ist nicht entbehrlich. Das ist gutes Engineering.