Startseite / Blog / Runbook-Leitfaden

Betrieb

Was ist ein Runbook und wie schreibt man eines, das das Team nutzt?

Ein Runbook ist eine Schritt-für-Schritt-Anleitung für wiederkehrende Aufgaben oder Störungen. Unterschied zur SOP, Inhalt und wie es dauerhaft nützlich bleibt.

5. Oktober 2026 · 6 Min. Lesezeit

Es ist zwei Uhr nachts, etwas ist ausgefallen, und die einzige Person, die die Lösung kennt, sitzt im Flugzeug. Ob ein fehlgeschlagener Zahlungslauf, ein toter Server oder eine hängende Bestellwarteschlange: Die nächste Stunde hängt an einer Frage. Ist das Wissen aufgeschrieben oder nur in einem Kopf? Ein Runbook ist die Art, es aufzuschreiben. Dieser Leitfaden erklärt, was ein Runbook ist, wie es sich von einer SOP unterscheidet und wie Sie eines schreiben, das Menschen unter Druck tatsächlich öffnen.

Was ist ein Runbook?

Ein Runbook ist eine kurze, praktische Anleitung für eine bestimmte Situation: eine wiederkehrende Aufgabe, eine bekannte Störung oder einen Vorfall. Es sagt der diensthabenden Person, was die Situation ausgelöst hat, wer dafür zuständig ist, was genau zu tun ist, wie man bei Verschlimmerung zurückrollt und wen man anruft. Der Test für ein gutes Runbook ist einfach: Könnte ein fähiger Kollege, der die Aufgabe noch nie gemacht hat, es nachts allein befolgen, ohne Sie anzurufen?

Runbook oder SOP: Wo liegt der Unterschied?

Beide überschneiden sich, und viele Teams verwenden die Begriffe gleichbedeutend. Eine nützliche Unterscheidung:

• Eine SOP (Standardarbeitsanweisung) beschreibt, wie Routinearbeit immer erledigt werden soll, etwa einen Lieferanten anlegen oder den Monat abschließen. Es geht um Einheitlichkeit und Compliance, und man liest sie meist vorab.
• Ein Runbook beschreibt, wie man auf ein bestimmtes Ereignis reagiert oder eine konkrete Betriebsaufgabe ausführt, oft unter Zeitdruck. Es geht um Tempo und Sicherheit, und man liest es im Moment.

Eine SOP darf ausführlich und etwas förmlich sein. Ein Runbook sollte unverblümt sein: kurze Sätze, exakte Befehle, keine Hintergrundaufsätze. Verlinken Sie vom Runbook auf die SOP, wenn jemand das „Warum“ braucht.

Wann sollten Sie ein Runbook schreiben?

Man kann nicht alles dokumentieren, also beginnen Sie dort, wo es wehtut. Schreiben Sie ein Runbook, wenn:

• eine Aufgabe wiederholt anfällt und Fehler teuer sind, etwa der monatliche Gehaltsexport oder ein Release.
• ein Vorfall zweimal passiert ist. Das zweite Mal ist das Signal.
• nur eine Person etwas kann. Das ist ein Risiko, kein Vorteil.
• eine Aufgabe selten, aber kritisch ist, etwa die Wiederherstellung aus einem Backup. An seltene Abläufe erinnert sich niemand.
• neue Kolleginnen und Kollegen immer wieder dieselben Fragen stellen.

Was gehört in ein Runbook?

Behalten Sie in jedem Runbook dieselben fünf Teile bei, damit jeder weiß, wo er nachsehen muss.

• Auslöser. Wann dieses Runbook gilt: der Alarm, das Symptom oder das Kalenderdatum. „Fehlerquote im Checkout über 5 % seit zehn Minuten“ ist ein Auslöser. „Wenn es schlecht aussieht“ nicht.
• Verantwortliche Person. Eine benannte Person oder Rolle, die es aktuell hält, plus Datum der letzten Überprüfung.
• Schritte. Eine nummerierte Liste, eine Aktion pro Schritt, in der richtigen Reihenfolge, jeweils mit dem erwarteten Ergebnis, damit der Leser merkt, dass es geklappt hat.
• Rollback. Wie man in den vorherigen Zustand zurückkehrt, wenn ein Schritt scheitert oder alles verschlimmert. Schreiben Sie es, bevor Sie es brauchen.
• Eskalation. Wen man kontaktiert, wenn die Schritte das Problem nicht lösen, in welcher Reihenfolge, wie und nach wie vielen Minuten Versuch.

Wie schreibt man Schritte, denen Menschen folgen?

Eine Aktion pro Schritt

„Dienst neu starten und Logs prüfen“ sind zwei Schritte. Trennen Sie sie, damit eine gestresste Person nicht die Hälfte überspringt.

Seien Sie exakt

Geben Sie den echten Befehl, den genauen Menüpfad oder den tatsächlichen Link an. „Öffnen Sie das Admin-Panel“ zwingt zum Raten. Um zwei Uhr nachts schlägt Kopieren und Einfügen jede Interpretation.

Beschreiben Sie, wie Erfolg aussieht

Schreiben Sie nach jedem wichtigen Schritt, was der Leser sehen sollte: „Die Statusseite zeigt Läuft.“ Wenn nicht, weiß er, dass er anhalten und eskalieren soll, statt blind weiterzumachen.

Ein kurzes Beispiel

Hier die Gliederung eines Runbooks für eine hängende Bestellwarteschlange:

• Auslöser: mehr als 50 Bestellungen warten seit über 15 Minuten.
• Verantwortlich: die Betriebsleitung; zuletzt im September geprüft.
• Schritte: Statusseite des Zahlungsanbieters prüfen; Queue-Worker neu starten; bestätigen, dass die Zahl der wartenden Bestellungen innerhalb von fünf Minuten sinkt.
• Rollback: Erzeugt der Neustart doppelte Bestellungen, den Worker anhalten und der Anleitung zur Bereinigung von Dubletten folgen.
• Eskalation: Bewegt sich die Warteschlange nach 20 Minuten nicht, die Bereitschaftsingenieurin anrufen, danach die Betriebsdirektion.

Wie testet man ein Runbook?

Ein ungetestetes Runbook ist eine Vermutung. Geben Sie es jemandem, der es nicht geschrieben hat, und lassen Sie die Person es befolgen, am besten in einer sicheren Umgebung oder bei einer Übung, während Sie schweigend zusehen. Jede Stelle, an der sie zögert, nachfragt oder improvisiert, ist eine Lücke. Führen Sie diese Übungen für kritische Runbooks ein- bis zweimal im Jahr durch. Stellen Sie nach jedem echten Vorfall in der Nachbesprechung eine weitere Frage: Hat das Runbook geholfen, und was hätte es besser gemacht?

Wie hält man ein Runbook aktuell?

• Geben Sie jedem Runbook eine verantwortliche Person und ein Prüfdatum. Vierteljährlich für kritische, halbjährlich für die übrigen.
• Aktualisieren Sie nach jeder Nutzung. Wer es gerade befolgt hat, weiß am besten, was falsch war oder fehlte. Machen Sie die Korrektur zum Teil des Vorfallabschlusses.
• Koppeln Sie es an Änderungen. Ändert sich ein System, ein Werkzeug oder ein Lieferant, gehört die Aktualisierung der zugehörigen Runbooks auf dieselbe Checkliste.
• Halten Sie es auffindbar. Ein perfektes Runbook in einem vergessenen Ordner nützt nichts. Bewahren Sie alle an einem Ort auf, mit klaren Namen, und verlinken Sie sie nach Möglichkeit im Alarm selbst.

Wo bewahrt man Runbooks auf?

Für den Anfang genügt ein geteiltes Dokument oder ein Wiki. Wichtiger als das Werkzeug ist, dass Runbooks nah an der Arbeit liegen. Wenn Sie Abläufe, Aufgaben und KPIs bereits in FulcrumGrid Command Center verfolgen, können Sie jedes Runbook mit dem Projekt oder der Kennzahl verknüpfen, die es schützt, und Prüftermine wie jede andere Aufgabe den Verantwortlichen zuweisen, damit sie nicht unbemerkt ablaufen. Beginnen Sie aber mit dem, was Ihr Team wirklich öffnet.

Wählen Sie den Vorfall, der im letzten Quartal am meisten wehgetan hat, schreiben Sie diese Woche sein Runbook und testen Sie es mit jemand Neuem. Ein einziges gutes Runbook nützt Ihrem Team mehr als ein Ordner voll ungetesteter.

Häufige Fragen

Ist ein Runbook dasselbe wie ein Playbook?

Die Begriffe überschneiden sich. Viele Teams nutzen ein Runbook für exakte, schrittweise technische oder operative Handlungen und ein Playbook für die breitere Strategie, etwa den Umgang mit einem Großvorfall oder einer Kundeneskalation, das auf mehrere Runbooks verweisen kann.

Wie lang sollte ein Runbook sein?

So kurz wie möglich, idealerweise ein bis zwei Seiten. Braucht es mehr, teilen Sie es in kleinere Runbooks auf oder verlinken Sie Hintergrundmaterial, statt die Schritte zu vergraben.

Wer sollte das Runbook schreiben?

Wer die Aufgabe heute erledigt, sollte den Entwurf schreiben, denn diese Person kennt die Details. Danach sollte jemand, der sie nie gemacht hat, es testen und überarbeiten, denn er erkennt fehlende Annahmen.

Wie oft sollten Runbooks überprüft werden?

Prüfen Sie kritische Runbooks vierteljährlich und die übrigen halbjährlich. Aktualisieren Sie jedes Runbook direkt nach dem Einsatz bei einem echten Vorfall oder wenn sich das abgedeckte System ändert.

← Zurück zum Blog