Werkzeugbox Wissensmanagement & Innovation

Runbook

📌 Allgemeine Hinweise

Ein Runbook ist ein strukturiertes Werkzeug zur standardisierten Dokumentation von Arbeitsabläufen, Betriebsprozessen und Handlungsanweisungen. Es beschreibt detailliert, wer, wann, wie und womit bestimmte Tätigkeiten durchführt. Ziel ist die sichere, wiederholbare und nachvollziehbare Durchführung von Aufgaben – insbesondere bei komplexen, kritischen oder selten auftretenden Prozessen.

Im Wissensmanagement ist ein Runbook vergleichbar mit einem präzisen Betriebs- und Einsatzhandbuch, das sicherstellt, dass Wissen nicht nur gespeichert, sondern auch zuverlässig und reproduzierbar angewendet werden kann. Es bildet die Brücke zwischen dokumentiertem Wissen und operativer Handlungsausführung. Ein Runbook dient dazu, Erfahrungswissen, Expertenwissen und Prozesswissen so zu dokumentieren, dass auch andere Personen Aufgaben zuverlässig übernehmen können.

🎯 Bestimmungsgemäße Verwendung

Ein Runbook eignet sich insbesondere für:

  • Standardisierte Betriebsabläufe
  • Wiederkehrende Tätigkeiten
  • Notfallmaßnahmen
  • Incident-Management
  • Störungsbehebung
  • Wartungsarbeiten
  • Systemstarts und Systemabschaltungen
  • Übergaben zwischen Teams
  • Wissenssicherung bei Expertenwissen
  • Onboarding neuer Mitarbeitender

Typische Anwendungsfälle:

  • Neustart eines Servers
  • Durchführung eines Software-Updates
  • Wiederherstellung eines Backups
  • Bearbeitung von Kundeneskalationen
  • Monatliche Berichterstellung
  • Maschinenwartung

Nicht geeignet ist ein Runbook für:

  • Strategische Entscheidungen
  • Kreative Problemlösungen
  • Unstrukturierte Wissenssammlungen
  • Allgemeine Fachinformationen ohne Handlungsbezug

ℹ️ Hintergrundinformationen zu dem Werkzeug

Der Begriff „Runbook“ stammt ursprünglich aus dem IT-Betrieb. Früher wurden Betriebsanweisungen in physischen Ordnern („Operations Books“) dokumentiert, die bei Störungen oder Wartungsarbeiten verwendet wurden. Mit zunehmender Digitalisierung entwickelte sich daraus das Runbook als strukturierte Sammlung von Betriebswissen.

Runbooks verfolgen die Prinzipien der Eindeutigkeit (keine Interpretation notwendig), Wiederholbarkeit, Minimalprivilegien, Sicherheitshinweise, Zeit- und Erfolgsindikatoren.

🔁 Welche Werkzeuge alternativ verwendet werden können

🔧 Welche anderen Werkzeuge unterstützen können

  • Incident-Management-Systeme: (z. B. PagerDuty, Opsgenie) für Alarmierung und Eskalation.
  • Ticketing-Systeme: (Jira, ServiceNow) zur Dokumentation von Ausführung und Nachverfolgung.
  • Runbook-Automation-Tools: (z. B. Rundeck, StackStorm) zur teil- oder vollautomatischen Ausführung.
  • Versionsverwaltung: (Git) für Änderungsverfolgung.
  • Collaboration-Plattformen: (Confluence, Google Docs) für gemeinsame Pflege.

👥 Benötigte Personen

  • Runbook-Autor/in: dokumentiert Schritte, Voraussetzungen und Tests.
  • Fachexpert/in: prüft technische Korrektheit und Sicherheitsaspekte.
  • Operator/On-Call: führt das Runbook aus.
  • Reviewer/Compliance: genehmigt kritische Runbooks (bei sicherheitsrelevanten Prozessen).
  • Automation-Engineer (optional): implementiert Automationsschritte.

⏱️ Dauer

  • Erstellung eines einfachen Runbooks: 1–4 Stunden.
  • Komplexe Runbooks mit Tests/Automatisierung: mehrere Tage bis Wochen.
  • Ausführungsdauer: je nach Prozess wenige Minuten bis mehrere Stunden — in Runbook dokumentieren.

🗂️ Benötigtes Material

  • Zugangsdaten / Berechtigungen (minimal erforderliches Privileg).
  • Kontrollierte Testumgebung (für Validierung).
  • Monitoring-Dashboards und Logs.
  • Toolzugänge (SSH, Management-UI, Cloud-Konsole).
  • Template für Runbooks (Standardkopf, Schritte, Rollback).

🧩 Gerätebeschreibung / Bauplan

Struktur (empfohlenes Layout, von oben nach unten):

  1. Titel, ID, Version, Autor, Letzte Aktualisierung, Kritikalität, Geltungsbereich
  2. Zweck / Ziel (kurz)
  3. Voraussetzungen / Zugriffsrechte / Abhängigkeiten
  4. Sicherheits- und Compliance-Hinweise (z. B. Wartungsfenster, Backup erforderlich)
  5. Voraussetzungen prüfen (Checkliste vor Start)
  6. Schritt-für-Schritt-Anweisungen (nummeriert, klar, bedingte Pfade)
  7. Erwartetes Ergebnis / Prüfungen (wie prüfen, dass Schritt erfolgreich war)
  8. Rollback- / Mitigationsschritte (falls etwas schiefgeht)
  9. Eskalationspfad (Kontakte, SLAs, Kommunikationskanäle)
  10. Nachbereitungsaufgaben (Dokumentation im Ticket, Lessons Learned)
  11. Test-/Validierungsprotokoll (wie wurde das Runbook getestet)
  12. Referenzen / Links zu tiefergehenden Docs
  • Format: Klarer, monospace-freundlicher Text für Copy-Paste von Befehlen, optionale Codeblöcke für Kommandozeilen.

🚀 Inbetriebnahme

  1. Template auswählen oder anlegen (inkl. Metadatenfelder).
  2. Verantwortliche Person benennen.
  3. Zugangsvoraussetzungen sicherstellen (Schlüssel, Rollen).
  4. Prozedur in Testumgebung vollständig durchspielen und dokumentieren.
  5. Sicherheits- und Compliance-Review durchführen.
  6. Version veröffentlichen (mit Versionsnummer und Änderungslog) und in Wissensdatenbank verlinken.
  7. Operators informieren und Training/Walkthrough anbieten.

⚙️ Bedienung (Ausführung)

Schritt-für-Schritt-Standard für Betreiber:

  1. Bestätige Metadaten: Runbook-ID, Version, Autor, Gültigkeit.
  2. Prüfe Voraussetzungen: Zugänge, Backups, Wartungsfenster.
  3. Beginne Ausführung der nummerierten Schritte genau in der dokumentierten Reihenfolge.
  4. Nach jedem Schritt: Erfolg prüfen (Logs, Monitoring-Checks), Ergebnis dokumentieren.
  5. Bei Abweichung: sofort Rollback- oder Mitigationsanweisung ausführen.
  6. Bei kritischen oder unklaren Fällen: Eskalationspfad folgen (Kontakte anrufen/benachrichtigen).
  7. Abschließen: Ergebnis in Ticket eintragen, Zeitpunkt, beteiligte Personen, beobachtete Nebenwirkungen.
  8. Feedback/Verbesserungsvorschläge direkt im Runbook-Review-Feld ergänzen.

🔄️ Wartung & Pflege

  • Review-Zyklus: mindestens alle 3–6 Monate oder nach jedem relevanten Incident/Change.
  • Änderungsmanagement: jede Modifikation mit Versionsnummer, Diff-Notiz und Reviewer dokumentieren.
  • Testing: nach jeder Änderung in Staging erneut durchspielen.
  • Berechtigungen: Zugriffsrechte periodisch auditieren.
  • Archiv: veraltete Runbooks archivieren, mit Verweis auf aktuelle Verfahren.

🌟 Expertentipps

  • Klarer Stil: Schreibe für die Person, die das Runbook im Stressfall liest — kurz, eindeutig, ohne unnötige Theorie.
  • Nummerierungen: Nutze nummerierte Schritte + erwartete Prüfung nach jedem Schritt.
  • Visualisierung: Hebe Befehle, Zeitlimits und Warnungen visuell hervor (z. B. Codeblöcke, WARN:).
  • Automatisierung: Automatisiere repetitive, fehleranfällige Schritte, halte aber menschliche Kontrollpunkte.
  • Zeitplanung: Füge „Zeitabschätzung pro Schritt“ hinzu, damit Operatoren Prioritäten setzen können.
  • Berechtigungen: Dokumentiere, wer autorisiert ist, von Standardpfad abzuweichen.
  • Retro: Sammle nach jedem Incident ein kurzes „What went well / What went wrong“ und aktualisiere das Runbook sofort.

📝 Beispiel

Runbook: Wiederherstellung einer gelöschten Datei aus dem Backup-System

Zweck: Wiederherstellung versehentlich gelöschter Dateien.

Voraussetzungen:

  • Administratorrechte vorhanden
  • Backup-System erreichbar
  • Dateiname bekannt

Verantwortlich:

  • Service Desk
  • Systemadministrator

Durchführung

  • Schritt 1: Anmeldung am Backup-System.
  • Schritt 2: Suchfunktion öffnen.
  • Schritt 3: Dateiname eingeben.
  • Schritt 4: Gewünschten Sicherungszeitpunkt auswählen.
  • Schritt 5: Wiederherstellungsort festlegen.
  • Schritt 6: Wiederherstellung starten.
  • Schritt 7: Ergebnis kontrollieren.

Kontrollpunkt

  • Datei erfolgreich geöffnet und lesbar.

Fehlerbehebung

  • Fehler: Datei nicht auffindbar
  • Maßnahme:
    • Vorherige Sicherung prüfen
    • Administrator informieren

Eskalation:
Falls Wiederherstellung fehlschlägt:

  1. Backup-Administrator kontaktieren
  2. Teamleiter informieren
  3. Incident-Ticket eröffnen

Dokumentation:

  • Ticketnummer
  • Datum
  • Bearbeiter
  • Wiederhergestellte Datei
  • Ergebnis
, , ,