Ein gutes Runbook ist der Unterschied zwischen einem reibungslosen On-Call-Shift und einem Desaster um 3 Uhr morgens. Mit Trupeer kannst du Stunden beim Schreiben von IT-Runbooks sparen, indem du mit einer kostenlosen Runbook-Vorlage startest, sie mit deinen Brand-Richtlinien anpasst und lange Runbooks in Video-Durchläufe umwandelst, die On-Call-Engineer in Sekunden überfliegen können.

Was ist eine kostenlose Runbook-Vorlage?

Eine kostenlose Runbook-Vorlage ist eine wiederverwendbare Struktur für die Abfolge von Schritten, mit der eine konkrete operative Aufgabe erledigt wird: ein Deployment, ein Failover, eine Migration, eine Wiederherstellung, ein geplantes Wartungsfenster.

Das Wort Runbook lohnt sich, wörtlich zu nehmen. Das ist ein Dokument, das ausgeführt wird – nicht eines, das man liest. Es ist auf dem Bildschirm geöffnet, während die Arbeit passiert, wird der Reihe nach abgearbeitet, und sein Wert liegt vollständig darin, was es während der Ausführung bewirkt – nicht darin, was es sagt, wenn es abgelegt wurde.

Diese eine Tatsache trennt ein gutes Runbook von einem guten Verfahrensdokument, und genau das übersehen die meisten Vorlagen. Sie liefern eine gut organisierte Beschreibung dessen, was zu tun ist – das ist notwendig und ungefähr die Hälfte dessen, was ein Runbook ausmacht.

Die andere Hälfte ist: Ein Runbook ist eine Form. Es wird beim Ausführen ausgefüllt, denn die Aufzeichnung dessen, was tatsächlich passiert ist, macht den Unterschied zwischen einer Operation, in die man später einsteigen kann, und einer, die neu gestartet oder geraten werden muss.

Das bestimmt das Format. Eine kostenlose Runbook-Vorlage als Excel-Datei passt zur Schritt-Tabelle mit Ergebnis- und Zeitstempel-Spalten und ist das, was die meisten Teams am Ende verwenden. Eine kostenlose Runbook-Vorlage als Word-Version eignet sich für Runbooks mit viel Kontext und Prosa rund um die Schritte, und eine kostenlose Runbook-Vorlage als Microsoft-Word-Datei ist dasselbe unter ihrem längeren Namen. Eine kostenlose Runbook-Vorlage als PDF ist ein archivierter Datensatz eines abgeschlossenen Runs – statt ein Arbeitsdokument.

Deployment-Runbook oder Incident-Runbook?

Zwei Dokumente teilen sich den Namen und werden auf entgegengesetzte Weise verwendet – also entscheide, was du schreibst.

Ein Deployment-Runbook-Template deckt geplante Arbeit ab. Ein Release, eine Migration, ein Cutover, ein geplantes Wartungsfenster. Es wird von Schritt eins bis zum Ende in der richtigen Reihenfolge ausgeführt, zu einem Zeitpunkt, den alle kannten – meist durch mehr als eine Person und oft über einen Schichtwechsel hinweg. Das Designproblem ist Reihenfolge, Zustand und Übergabe.

Ein Incident- oder On-Call-Runbook deckt ungeplante Arbeit ab. Etwas stimmt nicht und jemand diagnostiziert. Es wird zu einem unvorhersehbaren Zeitpunkt eingegeben – von der Person, die verfügbar ist – unter Druck, und es wird nicht der Reihe nach gelesen. Das Designproblem ist, den relevanten Abschnitt schnell zu finden, weshalb es eher wie ein Nachschlagewerk als wie ein Skript ist.

Die meisten veröffentlichten Vorlagen vermischen beides und dienen keinem davon wirklich gut. Ein diagnostisches Runbook, das in eine nummerierte Reihenfolge gezwungen wird, lässt sich nicht mitten drin eintragen, und ein Deployment-Runbook, das als Set aus Symptomen organisiert ist, verliert die Reihenfolge, die es sicher macht.

Diese Seite handelt in erster Linie vom ersten Fall. Geplante Arbeit, in Reihenfolge ausgeführt – bei der die teuren Fehler eher mit Zustand und Übergabe zu tun haben als mit Diagnose.

So passt du diese Vorlage in Trupeer an

Schritt 1: Öffne den Bereich „Templates“

Gehe im Hauptmenü zum Bereich „Templates“.

Schritt 2: Wähle eine Vorlage aus und öffne sie

Klicke auf eine beliebige Vorlage, mit der du arbeiten möchtest, um sie zu öffnen.

Schritt 3: Erweitere die Vorlagenansicht

Wenn nötig, erweitere die Vorlagenansicht, um das vollständige Layout und die Details klar zu sehen.

Schritt 4: Bearbeite die Vorlage

Klicke auf „Edit“, um mit der Anpassung der ausgewählten Vorlage zu beginnen.

Im Editor kannst du:

• Neue Abschnitte hinzufügen

• Formatierungsregeln definieren oder aktualisieren

• Ein Logo hinzufügen und Position sowie zugehörige Einstellungen anpassen

Schritt 5: Speichere deine angepasste Vorlage

Nachdem du alle notwendigen Änderungen vorgenommen hast, klicke auf „Save“, um die aktualisierte Vorlage als deine eigene zu speichern.

Schritt 6: Vorschau ansehen und die Vorlage feinjustieren

Wenn du sehen möchtest, wie deine angepasste Vorlage aussieht, öffne die Vorschau.

Du kannst direkt aus dem Vorschau-Bildschirm heraus bei Bedarf weitere Anpassungen vornehmen – so stellst du sicher, dass die Vorlage genau so erscheint, wie du es möchtest.

Mit einer Runbook-Vorlage kannst du:

• Stunden beim Schreiben sparen: Überspringe die leere Seite – mit einer Struktur, die für Ops-Verfahren gebaut ist.

• MTTR reduzieren: Klare Runbooks helfen On-Call-Engineer, Incidents schneller zu lösen.

• Im Brand bleiben: Nutze dein Logo, deine Schriften und Farben mit Trupeer’s Brand Kit.

• Neue Engineer schulen: Kombiniere Runbooks mit Video-Durchläufen, um Ops-Teams schneller einzuarbeiten.

• Über Teams hinweg standardisieren: Verwende für jede Incident-Art dasselbe Runbook-Format.

• Globale Teams erreichen: Übersetze Runbooks mit einem Klick in 65+ Sprachen.

Schreibe das Runbook so, dass es zur Hälfte übergeben werden kann

Hier ist die Design-Einschränkung, um die es sich lohnt, herumzubauen. Irgendwann während der Ausführung hört die Person, die das Runbook ausführt, auf, die Person zu sein, die es gestartet hat.

Ein Shift endet. Jemand wird weggerufen. Ein Zeitfenster läuft länger als geplant. Bei jeder Operation, die länger als ein paar Stunden dauert, ist das eher die Regel als die Ausnahme – und genau in diesem Moment scheitern Runbooks teuer.

Die Frage, gegen die man designen muss, ist präzise. Kann eine zweite Person das bei Schritt siebenunddreißig übernehmen – ohne mündliches Briefing – und sicher weitermachen?

„Ja“ zu beantworten, erfordert vier Dinge, die die meisten Vorlagen nicht haben.

Ein aufgezeichnetes tatsächliches Ergebnis pro Schritt, nicht nur ein erwartetes. Ein Häkchen bedeutet, dass jemand etwas angeklickt hat. Es sagt der nächsten Person nicht, was passiert ist.

Einen Zeitstempel pro Schritt, denn wie lange her ein Schritt ausgeführt wurde, ist häufig die aussagekräftigste Diagnose-Information.

Eine explizite Markierung, welche Schritte sicher erneut ausgeführt werden können. Die erste Frage jeder Person, die übernimmt, lautet, ob der vorherige Schritt tatsächlich fertig geworden ist. Wenn der Schritt sicher wiederholbar ist, verliert diese Frage an Bedeutung – und das ist deutlich mehr wert als die Kosten, um das aufzuzeichnen.

Ein klar benannter Punkt ohne Rückkehr. Ab wann Rollback nicht mehr verfügbar ist. Jemand, der mitten in der Ausführung ankommt, muss wissen, auf welcher Seite dieser Linie er steht, bevor er irgendetwas anfasst.

Füge diese vier hinzu, und die mündliche Übergabe hört auf, das Mechanismus zu sein. Das Dokument wird zur Übergabe – und das ist die einzige Version, die überlebt, wenn jemand müde, im Stress oder nicht verfügbar ist.

Was eine Runbook-Vorlage enthalten muss

Neun Komponenten. Die mittleren vier sind die, die ein Runbook von einem Verfahrensdokument trennen.

Der letzte Punkt verdient besondere Aufmerksamkeit. Verifizierungsschritte, die als „bestätige, dass die Website online ist“ formuliert sind, bestehen, wenn die Website online ist – und auch dann, wenn sie kaputt ist, was der Fehler ist, der unten beschrieben wird.

Kostenlose Runbook-Vorlage: die Struktur zum Kopieren

Mit einem echten Beispiel statt Platzhaltern ausgefüllt. Das ist ein Auszug aus einer Migration eines Order-Management-Systems.

Kopiere von hier.

Header und Zeitfenster. Name des Runs, Datum, geplantes Zeitfenster, Abbruchfrist und die Version dieses Runbooks.

Order-Management-Migration. Samstag, 14. Juni. Zeitfenster 06:00 bis 20:00. Abbruchfrist 16:00, danach rollen wir unabhängig vom Fortschritt zurück. Runbook v9.

Rollen für diesen Run. Mit Zahlen im Dokument.

Ausführend: K Ferreira 06:00 bis 14:00, dann D Attwood 14:00 bis 20:00. Punkt ohne Rückkehr freigegeben von: Head of Engineering, 07700 900xxx. Eskalation: On-Call-Plattform-Lead, 07700 900xxx. Business-Kontakt für die Go-Entscheidung: Trading Director.

Voraussetzungen. Alle bestätigt vor Schritt eins.

Vollständiges Datenbank-Backup erstellt und Restore auf der Standby-Instanz getestet. Code-Freeze aktiv seit Donnerstag. Beide Ausführenden haben heute verifizierten Produktionszugriff, nicht angenommen. Rollback auf Staging am 7. Juni geprobt.

Statuszeile. Wird fortlaufend aktualisiert, oben beibehalten.

Aktuell bei Schritt 37. Läuft seit 13:48. Ausführender: K Ferreira. Punkt ohne Rückkehr noch nicht überschritten.

Schritt-Tabelle.

Rollback. Verfügbar bis einschließlich Schritt 37. Restore aus dem Pre-Run-Backup, DNS umzeigen, Intake-Workers neu starten. Auf Staging am 7. Juni von D Attwood geprobt.

Übergabe-Abschnitt. Wird ausgefüllt, bevor jemand geht.

Abgeschlossen bis Schritt 35. Schritt 34 ist beim ersten Versuch still fehlgeschlagen – mit einer Abweichung bei der Anzahl – und wurde erfolgreich erneut ausgeführt; die Anzahlen stimmen jetzt bei 84,120 überein. Beobachte die Indexanzahl erneut nach Schritt 36, da sie einmal fehlgeschlagen ist. Nichts läuft noch im Hintergrund. Punkt ohne Rückkehr noch nicht überschritten, Rollback ist weiterhin verfügbar.

Verifizierung. Spezifisch genug, um zu scheitern.

Website lädt. Produktanzahl auf den Kategorieseiten summiert sich auf 84,120. Zehn Beispielbestellungen, Ende-zu-Ende platziert. Bestellhistorie sichtbar für fünf bekannte Konten. Payment-Reconciliation-Report läuft und stimmt.

Kopiere von hier.

Runbook-Beispiel: einundsechzig Schritte und eine zehnminütige Übergabe

Tamworth Retail Group, ein Online-Händler, migrierte sein Order-Management-System während eines geplanten vierzehnstündigen Zeitfensters an einem Samstag.

Das Runbook hatte einundsechzig Schritte. Es wurde geprüft, auf Staging geprobt und war tatsächlich ein sorgfältiges Dokument. Seine Schritt-Tabelle hatte drei Spalten: Schritt-Nummer, Aktion und ein Kontrollkästchen.

Der erste Engineer führte die Schritte eins bis siebenunddreißig aus, übergab mündlich in etwa zehn Minuten beim Schichtwechsel und ging nach einem langen Tag nach Hause.

Schritt vierunddreißig war das Re-Indexing des Produktkatalogs – ein Job, der etwa vierzig Minuten dauerte. Er hatte damit begonnen, keine Fehler gesehen und es abgehakt. Tatsächlich war er etwa zu achtzig Prozent fehlgeschlagen und hatte nichts gemeldet.

Der zweite Engineer kam zu einer Liste mit einundsechzig Schritten, bei denen die ersten siebenunddreißig abgehakt waren. Es gab keine Aufzeichnung darüber, was irgendein Schritt produziert hatte, keine Zeitstempel und keinen Hinweis darauf, welche Schritte man sicher wiederholen konnte. Alles vor Schritt achtunddreißig war – soweit das Dokument es betrifft – einfach erledigt.

Sie machte weiter. Der Katalog war teilweise indexiert, was bedeutete, dass ungefähr zwölf Prozent der Produkte auf der Website unsichtbar waren, als sie wieder geöffnet wurde.

Der abschließende Smoke-Test bestätigte, dass die Website geladen wurde. Er verglich jedoch nicht die Produktanzahl mit der Kataloganzahl, also bestand er.

Niemand bemerkte es, bis Montagmorgen, einunddreißig Stunden später, über das geschäftigste Handelswochenende des Quartals hinweg. Die geschätzten verlorenen Bestellungen gegenüber demselben Wochenende im Vorjahr beliefen sich auf rund zweihundertvierzigtausend Pfund.

Sie konnten nicht zurückrollen. Der Punkt ohne Rückkehr war bei Schritt einundvierzig überschritten, und obwohl alle Beteiligten es grundsätzlich wussten, war es in einem Absatz auf Seite eins festgehalten – statt in dem Schritt, in dem es passiert ist.

Die Neufassung fügte keine Schritte hinzu. Sie fügte Spalten hinzu: tatsächliches Ergebnis, Zeitstempel und eine Markierung „sicher erneut auszuführen“ für jeden Schritt. Eine Statuszeile oben. Der Punkt ohne Rückkehr wechselte von der Einleitung zum Schritt selbst – fett. Und ein Übergabe-Abschnitt, der vor dem Weggehen fertiggestellt werden muss – so wurde aus einem zehnminütigen Gespräch vier schriftliche Zeilen.

Bei der nächsten Migration passierte der Schichtwechsel in Stunde neun. Die Übergabe dauerte vier Minuten. Der Engineer, der übernahm, führte drei Schritte erneut aus, bei denen sie sich nicht sicher war – speziell, weil sie als „sicher erneut auszuführen“ markiert waren – und das Runbook endete innerhalb des Zeitfensters.

Drei Schritte aus Vorsicht erneut auszuführen kostet ein paar Minuten. Nicht dazu in der Lage zu sein kostet ein Wochenende.

So schreibst du ein Runbook in sechs Schritten

1. Schreibe die Schritte, indem du die Aufgabe ausführst, nicht aus dem Gedächtnis. Ein Runbook, das am Schreibtisch geschrieben wird, enthält die Schritte, an die sich der Autor erinnert, und lässt die aus, die die Hände automatisch erledigen.

2. Gib jedem Schritt ein erwartetes Ergebnis. Was du sehen wirst, das bedeutet, dass es funktioniert hat. Ein Schritt ohne erwartetes Ergebnis kann nur vom Autor verifiziert werden.

3. Markiere jeden Schritt als sicher erneut auszuführen oder nicht. Wird unten behandelt. Das ist die günstigste Spalte, die man hinzufügen kann, und die wertvollste während einer Übergabe.

4. Setze den Punkt ohne Rückkehr in den Schritt, fett. Nicht in die Einleitung – dort wird er nur einmal von jemandem gelesen, der nicht die Person ist, die ihn braucht.

5. Füge die Spalten hinzu, die du während des Runs ausfüllst. Tatsächliches Ergebnis und Zeitstempel. Wenn sie nicht im Dokument stehen, werden sie nirgendwo aufgezeichnet.

6. Probiere es durch, inklusive Rollback. Ein Rollback, das nur aufgeschrieben wurde, ist eine Annahme. Probiere es auf Staging mit der Person, die es ausführt, statt mit der Person, die es geschrieben hat.

Schritt eins ist der, der nützliche Runbooks von plausiblen trennt. Schreiben während des Ausführens fängt den nicht dokumentierten Klick ab, die Anmeldedaten, die schon in der Zwischenablage lagen, und den Tab, der offen sein musste.

Schritte als sicher erneut auszuführen markieren – und den Punkt ohne Rückkehr

Diese beiden Markierungen leisten die meiste Arbeit in einer Übergabe, und keine davon taucht in einer typischen Vorlage auf.

Sicher erneut auszuführen. Kann jeder Schritt zweimal ausgeführt werden, ohne Schaden anzurichten. Einen gestoppten Dienst neu starten, ein Index erneut ausführen, eine Konfiguration erneut anwenden, die bereits angewendet ist: normalerweise ja. Eine Kunden-E-Mail senden, einen Zähler erhöhen, Zeilen in eine Tabelle migrieren, die nicht dedupliziert: normalerweise nein.

Der Wert liegt darin, dass dadurch die Frage entfällt, die eine übernehmende Person nicht beantworten kann. Hat der vorherige Schritt fertiggestellt. Wenn die Antwort keine Rolle spielt, weil das Wiederholen harmlos ist, muss niemand sie unter Druck mit unvollständigen Informationen feststellen.

Wenn ein Schritt nicht sicher erneut auszuführen ist, sag, was zuerst zu prüfen ist. „Nein, prüfe die Zeilenanzahl, bevor du es wiederholst“ ist viel nützlicher als „Nein“, weil die Person, die es liest, bereits entschieden hat, dass sie etwas tun muss.

Der Punkt ohne Rückkehr. Jeder Run, der den Zustand verändert, hat einen. Das ist der Schritt, nach dem Rollback nicht mehr verfügbar ist – oder nicht mehr günstiger ist als der weitere Verlauf.

Markiere ihn im Schritt, visuell klar unterscheidbar, damit jemand beim Scrollen sofort sieht, auf welcher Seite er sich befindet. Nenne die Person, die das Überschreiten autorisiert, und halte die Zeit fest, zu der es tatsächlich überschritten wurde – in der Spalte „Tatsächliches Ergebnis“. Viele Runs haben mehr als einen, dann markiere jeden und sage, was er jeweils abschließt.

Der Grund, das Überschreiten zu dokumentieren statt nur den Schritt zu markieren, ist: Nach einem Incident wird gefragt, wann die Entscheidung unumkehrbar wurde – und niemand erinnert sich.

Varianten von Runbook-Vorlagen

Die Struktur bleibt, der Fokus verschiebt sich.

Deployment-Runbook-Template. Das Beispiel oben. Sequenziell, geplant, häufig über einen Schichtwechsel hinweg – und die Variante, bei der das Übergabe-Design am wichtigsten ist.

Runbook für Disaster Recovery. Wird selten und unter den schlimmsten Bedingungen ausgeführt, daher veraltet es zwischen den Einsätzen unsichtbar. Die unterscheidende Anforderung ist die geplante Wiederholung: Ein DR-Runbook, das in einem Jahr nicht ausgeführt wurde, sollte als falsch angenommen werden.

On-Call- und Incident-Runbook. Wird zu einem unvorhersehbaren Zeitpunkt eingegeben, statt in Reihenfolge abgearbeitet. Organisiere nach Symptomen statt nach Sequenz, halte jeden Eintrag kurz und verlinke auf tiefergehendes Material, statt es selbst zu enthalten.

Runbook für geplante Wartung. Wird regelmäßig wiederholt, wodurch es die einzige Variante ist, die sich durch die Nutzung tatsächlich verbessert – vorausgesetzt, jemand aktualisiert es während des Runs, statt es erst danach vornehmen zu wollen.

Onboarding- und Offboarding-Runbook. Oft das erste Runbook, das ein Team schreibt, weil die Reihenfolge stabil ist und die Kosten, einen Schritt zu verpassen – insbesondere beim Offboarding – ein Sicherheitsproblem sind, nicht nur eine Unannehmlichkeit.

Für alles, was regulierte Systeme, finanzielle Verarbeitung oder sicherheitsbezogene Kontrollen abdeckt, liegt ein Runbook normalerweise innerhalb eines Change-Management-Prozesses mit eigenen Anforderungen an Freigaben und Dokumentation – und diese Regeln gelten, statt alles auf dieser Seite.

Runbook, Arbeitsanweisung oder SOP?

Drei Dokumente überschneiden sich und lohnen sich, getrennt zu betrachten, denn wenn man falsch auswählt, entsteht der richtige Inhalt in einer nicht nutzbaren Form.

Eine Standard Operating Procedure deckt einen Prozess auf Ebene dessen ab, wer was in welcher Reihenfolge macht – meist über Rollen hinweg und oft über mehrere Tage. Sie wird zum Verständnis gelesen.

Eine Arbeitsanweisung deckt eine Aufgabe im Detail für die Person ab, die sie ausführt, und ist so geschrieben, dass sie von jemandem befolgt werden kann, der damit möglicherweise nicht vertraut ist. Das Template für Arbeitsanweisungen deckt dieses Dokument ab.

Ein Runbook ist eine Arbeitsanweisung, die auch ein Ausführungsprotokoll ist. Es wird gleichzeitig befolgt und ausgefüllt, umfasst in der Regel mehrere Aufgaben in einer definierten Reihenfolge, und seine Spalten existieren, um eine Spur zu hinterlassen.

Wenn dein Dokument vor der Arbeit gelesen und danach abgelegt wird, ist es ein Verfahrensdokument. Wenn es während der Arbeit geöffnet ist und sich am Ende von dem unterscheidet, was es am Anfang war, ist es ein Runbook.

Runbooks aktuell halten

Runbooks veralten schneller als die meisten anderen Dokumentationen, weil sie Systeme beschreiben, die sich ändern – und diese Veraltung ist unsichtbar, bis der Run, der scheitert, passiert.

Der Mechanismus, der tatsächlich funktioniert, ist das Aktualisieren während der Ausführung – nicht danach. Wer das Runbook ausführt, hat das Dokument offen, entdeckt gerade, dass Schritt zwölf jetzt eine zusätzliche Bestätigung erfordert, und ist die einzige Person, die das jemals so günstig wissen wird. Zehn Sekunden später – oder eine Stunde Verwirrung beim nächsten Run.

Mach das legitim, indem du es ganz explizit oben im Dokument sagst, und indem du ein unverändertes Runbook nach einer echten Ausführung als leicht verdächtig behandelst – statt als Zeichen von Qualität.

Automatisierung ist der andere Weg, und auch dabei lohnt es sich, klar zu sein. Das Automatisieren eines Runbook-Schritts entfernt sowohl menschliche Fehler als auch das Dokumentationsproblem – und das ist dort wirklich besser, wo es zutrifft. Was es nicht entfernt, ist die Notwendigkeit des umgebenden Dokuments, denn jemand muss immer noch wissen, was zu tun ist, wenn die Automatisierung fehlschlägt – und diese Person ist jetzt weniger geübt als früher. Automatisiere die Schritte, halte das Runbook, und stelle sicher, dass das Runbook den automatisierten Teil abdeckt, wenn er ausfällt.

Was eine kostenlose Runbook-Vorlage nicht beheben kann

Ein Runbook, das aus dem Gedächtnis geschrieben wurde. Keine Vorlage macht die Schritte sichtbar, die der Autor tut, ohne nachzudenken. Nur das Schreiben während der Ausführung.

Ein nicht geprobtes Rollback. Ein Rollback-Plan, der nie ausgeführt wurde, ist eine Hypothese – und die Mitte einer fehlgeschlagenen Migration ist ein schlechter Ort, um ihn zu testen.

Eine Checkliste, die den Namen trägt. Der Großteil dessen, was als kostenlose Runbook-Vorlage zum kostenlosen Download herumgeht, ist eine nummerierte Prozedur mit Häkchen, also ein anderes und schwächeres Dokument.

Verifizierung, die nicht scheitern kann. „Bestätige, dass die Website online ist“ besteht, wenn die Website online ist – und falsch ist. Jeder Verifizierungsschritt sollte so spezifisch sein, dass du dir vorstellen kannst, wie er fehlschlägt.

Ein Zeitfenster ohne Abbruchfrist. Ohne eine Abbruchfrist läuft ein Run, der schlecht läuft, weiter – weil Stoppen sich immer teurer anfühlt als der nächste Schritt. Setze die Deadline, bevor du startest, wenn niemand investiert ist.

Zeig das Runbook statt es zu beschreiben

Runbooks werden von Menschen ausgeführt, die sie selten ausführen. Eine Migration passiert zweimal im Jahr. Ein DR-Test passiert jährlich. Die Person, die es ausführt, hat es einmal zuvor gemacht – möglicherweise nie.

Genau das ist der Fall, den eine schriftliche Prozedur am schlechtesten abdeckt: Der Leser muss sich eine Abfolge von Screens und Konsolen-Zuständen aus Prosa rekonstruieren, und die Lücke zwischen dem, was der Autor gemeint hat, und dem, was der Leser sich vorstellt, ist genau dort, wo der undokumentierte Schritt versteckt ist.

Trupeer AI schließt das. Jemand führt den Run einmal auf Staging aus – während er aufzeichnet – und das Ergebnis ist ein schriftlicher Schritt-für-Schritt-Durchlauf mit Screenshots, die bereits erfasst und platziert wurden, zusammen mit einem Video, in deinem eigenen Branding. Die schriftliche Version wird zum Runbook. Das Video ist das, was die ausführende Person am Tag davor ansieht – die Vorbereitung, die im Moment niemand Zeit hat zu produzieren.

Dokumentiere es. Marke es. Übersetze es. Trupeer es.

Zwei Dinge folgen daraus, die speziell für Runbooks wichtig sind. Wiederholung erzeugt die Dokumentation als Nebeneffekt statt als zusätzliche Aufgabe – und das ist die einzige Version von Dokumentation, die zuverlässig entsteht. Und wenn sich die Infrastruktur ändert, ist das erneute Aufzeichnen der Wiederholung schneller als das Bearbeiten von Screenshots – daher ist das Runbook mit höherer Wahrscheinlichkeit im entscheidenden Moment aktuell.

Das Material liegt in deiner Knowledge Base und dient gleichzeitig als Training für die Person, die als Nächstes in der Rotation dran ist. Nachweise zur Verifizierung und Quality Gates rund um das Run gehören in den QA-Plan. Konsistenz mit deinen anderen Dokumenten ist eine Frage, das Brand Kit einmal festzulegen – und das Setup wird im Guide zum Setup der Dokumentvorlage abgedeckt.

Häufig gestellte Fragen

Gibt es eine kostenlose Runbook-Vorlage als Excel-Version?

Excel ist das, was die meisten Teams am Ende verwenden, und es passt gut zum Dokument, weil das Herzstück eines Runbooks eine Tabelle ist, die man beim Arbeiten ausfüllt. Eine kostenlose Runbook-Vorlage als Excel-Datei verarbeitet die Spalten für Schritt, erwartetes Ergebnis, tatsächliches Ergebnis, Zeitstempel und sicher erneut auszuführen ganz natürlich und ermöglicht es mehreren Personen, während eines Runs dieselbe Tabelle zu sehen.

Zwei praktische Einstellungen. Friere die Kopfzeile ein und setze die Statuszeile in die ersten beiden Zeilen darüber, damit sie beim Scrollen sichtbar bleibt. Eine kostenlose Runbook-Vorlage als Excel-Datei, bei der der aktuelle Schritt aus dem Sichtbereich scrollt, verliert den Großteil ihres Übergabe-Werts.

Gibt es eine kostenlose Runbook-Vorlage als Word-Version?

Word eignet sich für Runbooks mit umfangreichem Kontext rund um die Schritte: Architektur-Notizen, Entscheidungsverlauf, Eskalationsdetails. Erstelle die kostenlose Runbook-Vorlage als Word-Datei zuerst mit den narrativen Abschnitten und danach mit der Schritt-Tabelle.

Die Einschränkung ist das Ausfüllen während eines Runs. Eine Word-Tabelle ist langsamer zu aktualisieren als eine Spreadsheet-Zelle, und während einer Live-Migration reicht diese Reibung aus, um Menschen davon abzuhalten, tatsächliche Ergebnisse aufzuzeichnen. Viele Teams halten den Kontext in einem Word-Runbook-Vorlagen-Dokument und die Schritt-Tabelle in einer verlinkten Tabelle (Spreadsheet) vor.

Gibt es eine kostenlose Runbook-Vorlage als Microsoft-Word-Version?

Ja, und der gleiche Trade-off gilt. Eine kostenlose Runbook-Vorlage als Microsoft-Word-Datei ist die richtige Wahl, wenn das Runbook im Rahmen eines Change-Prozesses geprüft und freigegeben wird, da Dokumente sich besser in Freigabe-Workflows einfügen als Spreadsheets.

Wenn du diesen Weg gehst, füge die Spalten für tatsächliches Ergebnis und Zeitstempel trotzdem hinzu. Ein Runbook, das ohne diese Spalten freigegeben wurde, wird ohne sie ausgeführt – und der Datensatz, den du gebraucht hättest, existiert dann nicht.

Gibt es eine Deployment-Runbook-Vorlage?

Eine Deployment-Runbook-Vorlage ist die sequenzielle Variante, die auf dieser Seite durchgehend behandelt wird: geplante Arbeit, in Reihenfolge ausgeführt, meist über einen Schichtwechsel hinweg.

Vier Dinge unterscheiden eine gute von einer generischen Vorlage. Ein Punkt ohne Rückkehr, der im Schritt markiert ist – nicht in der Einleitung. Eine Markierung „sicher erneut auszuführen“ für jeden Schritt. Spalten für tatsächliches Ergebnis und Zeitstempel. Und ein Übergabe-Abschnitt, der fertiggestellt wird, bevor jemand geht. Fast keine veröffentlichte Vorlage hat eines dieser vier Merkmale.

Gibt es eine kostenlose Runbook-Vorlage als PDF?

PDF ist das Archiv – nicht das Arbeitsdokument. Sobald ein Run abgeschlossen ist, exportiere das ausgefüllte Runbook als kostenlose Runbook-Vorlage im PDF-Format und hänge es an den Change-Datensatz an, denn ein abgeschlossenes Runbook mit Zeitstempeln und tatsächlichen Ergebnissen ist der beste Nachweis dafür, was passiert ist.

Führe kein Runbook aus einem PDF heraus aus. Das Dokument muss während des Runs geschrieben werden, und alles, was du nicht eintippen kannst, wird nicht aufgezeichnet.

Gibt es eine kostenlose Runbook-Vorlage zum kostenlosen Download, die sich lohnt?

Die Tabelle selbst dauert zehn Minuten zum Erstellen, daher spart ein kostenloser Runbook-Template-Download nur wenig – und die meisten veröffentlichten Vorlagen sind Verfahrensdokumente mit einem Runbook-Label.

Prüfe eine Sache, bevor du eine davon übernimmst. Sieh dir an, ob die Schritt-Tabelle eine Spalte dafür hat, was tatsächlich passiert ist. Wenn sie nur ein Kontrollkästchen hat, hast du eine Checkliste – und das gesamte Argument dieser Seite ist, dass der Unterschied zwischen diesen beiden Dingen davon abhängt, worauf eine Übergabe angewiesen ist.

Wie lang sollte ein Runbook sein?

So lang wie der Run – und bei einer umfangreichen Migration sind das tatsächlich Dutzende Schritte. Die Länge ist bei Runbooks nicht das Problem.

Das, was du kontrollieren solltest, ist die Schrittgröße. Ein Schritt sollte eine Aktion mit einem beobachtbaren Ergebnis sein. Schritte, die mehrere Aktionen bündeln, können nicht teilweise übergeben werden, weil die nächste Person nicht erkennen kann, wie viel von dem Bündel passiert ist – und genau diese Situation soll das Dokument verhindern.

Wer sollte das Runbook schreiben?

Die Person, die es ausführt, indem sie während der Ausführung in einer Nicht-Produktionsumgebung schreibt. Ein Runbook, das von einem Architekten geschrieben und von einem Engineer ausgeführt wird, wird genau die Schritte vermissen, die der Architekt nicht persönlich ausführt.

Lass dann eine zweite Person den Entwurf auf Staging ausführen – ohne Hilfe vom Autor. Jede Frage, die sie stellen müssen, ist ein Mangel, und die Lösung ist, ihn aufzuschreiben, statt ihn zu beantworten.