Betriebshandbuch erstellen
Wenn Strategie-Doku die „Why"-Ebene ist und Architektur-Doku das „What", dann ist das Betriebshandbuch das „How": die operative Bibel der IT. Es beantwortet die Fragen, die in jedem produktiven Setup täglich anfallen: Welche Server haben wir? Wer betreibt sie? Wie startet/stoppt man sie sauber? Welche Backups laufen wann? Wie reagiert man auf welchen Alarm? Bei kleinen Setups ist das ein 30-Seiten-PDF, bei Konzern-IT eine ganze Wiki-Welt mit Hunderten Seiten und CMDB-Integration. Beiden ist gemein: das Betriebshandbuch muss im Notfall in unter 60 Sekunden auffindbar sein, sonst hilft es nicht. Diese Lektion zeigt dir den typischen Aufbau eines IT-Betriebshandbuchs (10 Kapitel-Standard), die wichtigsten Inhalte pro Kapitel (Service-Steckbrief, Verantwortlichkeiten, Notfallpläne), wie es im CMDB-Kontext verzahnt wird, und eine Beispiel-Vorlage für einen Service-Steckbrief, der dir das Kapitel-für-Kapitel-Schreiben erleichtert.
1) Standard-Aufbau eines Betriebshandbuchs
Klick die Kapitel an, um Inhalte und Hinweise zu sehen:
2) Service-Steckbrief – Kernelement des Betriebshandbuchs
Pro Service gibt es einen Steckbrief: kompakt, auffindbar, identisch strukturiert. Beispiel:
Service-Steckbrief: ERP-System „Navision"
1. Service-Identifikation
2. Technische Komponenten
3. Verantwortlichkeiten (RACI)
4. Betriebs-Routinen
- Start / Stop: SOP-OPS-014 (Wiki-Link)
- Backup: täglich 22:00 Vollsicherung + stündlich Tx-Log → Tape rotierend, 30 T retention
- Patching: Patch Tuesday +14 Tage (Welle „Standard")
- Wartungsfenster: jeden 3. Sonntag im Monat, 04:00-08:00
5. Monitoring & Alerts
6. Wichtige Kontakte / Eskalationspfad
- L1: IT-Service-Desk (Mo-Fr 7-19)
- L2: K. Wagner / M. Schmidt
- L3: SoftwareCo Hersteller-Support (24/7)
- Eskalation: IT-Leitung F. Müller (Tel -2900)
7. Bekannte Risiken & Workarounds
- Bei hoher Last (Monatsabschluss) DB-Backup nach 22:00 verzögert → Backup-Fenster auf 23:30 vorschieben
- Outlook-Add-In bricht alle 3 Monate bei Updates → SOP-OPS-015 (Reset-Verfahren)
3) Welche Inhalte sind unverzichtbar?
Wenn dein Betriebshandbuch nichts anderes hätte als diese Punkte, wäre es schon brauchbar:
| Inhalt | Warum kritisch |
|---|---|
| Aktueller Kontakt (Owner, On-Call) | Bei Incident weiß man, wen man wecken muss. |
| Notfall-Eskalationspfad | L1 → L2 → L3 → Geschäftsführung – mit Telefonnummern. |
| Backup / Restore-Verfahren | Bei Datenverlust überlebenswichtig. |
| Architektur-Diagramm | Visualisierung sagt mehr als Text. |
| Service-Abhängigkeiten | Was passiert, wenn AD/DNS/Netzwerk weg ist? |
| Start-/Stop-Reihenfolge | Bei Cluster-Restart oder DR-Wiederaufbau. |
| Lieferanten-Kontakte mit Vertragsnummern | Hersteller-Support sofort kontaktieren können. |
4) Verknüpfung mit CMDB
Idealerweise lebt der Betriebshandbuch-Steckbrief nicht doppelt – einmal im Word und einmal in der CMDB. Praxis-orientierte Lösungen:
- CMDB als Single Source of Truth – das Wiki zeigt nur Auszüge per API/Embed.
- Wiki als Single Source – CMDB wird nicht für „menschen-orientierte" Felder verwendet, nur für strukturierte Tech-Daten (IPs, Patches).
- Beide synchronisiert – mit klarer Regel: Wer ist primär? Etwa: Wiki bei narrativen Texten (Risiken, Workarounds), CMDB bei strukturierten Feldern (IP, OS, Owner-ID).
5) Pflegeprozess
Das Schwierigste am Betriebshandbuch ist nicht das Schreiben, sondern das Aktuell-Halten. Bewährte Mechanismen:
- Definition of Done für Changes: kein Change ist abgeschlossen, bevor die Doku aktualisiert ist.
- Quarterly Review: Service Owner liest seinen Steckbrief alle 3 Monate durch und bestätigt „aktuell" (Datum hinterlegen).
- Veraltungs-Marker: Doku ohne Bestätigung > 6 Monate wird automatisch markiert „veraltet, bitte prüfen".
- Rollen-Klarheit: jeder Service hat einen Steckbrief-Owner – ohne klare Verantwortlichkeit verwaist die Doku.
- Audit: interne Revision prüft regelmäßig die Doku-Aktualität.
6) Antipatterns
- Heroes-Pattern. „Wenn was kaputt geht, ruf den Müller an" – Müller geht in Rente, niemand weiß mehr was. Lösung: Dokumentation nicht-personenabhängig.
- 200-Seiten-Word-Dokument. Unleserlich, im Notfall keine Hilfe. Lösung: kurze Steckbriefe pro Service, mit Verlinkungen.
- Doku liegt nur lokal. Bei Server-Ausfall ist die Doku selbst auf demselben Server. Lösung: separate Ablage, idealerweise auch offline verfügbar.
- Veraltete Telefonnummern. Mitarbeiter X ist seit 6 Monaten weg, steht noch als On-Call. Lösung: regelmäßiges Update.
- Passwörter im Wiki. Sicherheitsproblem. Lösung: Passwort-Manager (Bitwarden, KeePass) separat, im Wiki nur Hinweis „im Vault unter ‚ERP-Admin'".
- Doku ohne Versionierung. Wer hat wann was geändert? Bei Wiki-Systemen idealerweise eingebaut, bei Word-Doku oft fehlend.
- Doku „nur für interne Verwendung". Externer Dienstleister wird beauftragt – kennt das Setup nicht, fragt 20 mal nach. Lösung: relevante Auszüge für externe Dienstleister bereitstellen (mit angemessenem Datenschutz).
- Doku im Tool, das niemand nutzt. Wiki existiert, aber alle arbeiten mit OneNote. Lösung: Tool-Entscheidung treffen und durchsetzen.
Zusammenfassung
Das Betriebshandbuch ist die operative Bibel der IT – typisch in 10 Kapiteln strukturiert (Einleitung, Service-Übersicht, Architektur, Betriebsabläufe, Backup, Wartung, Notfall/DR, Sicherheit, Schnittstellen, Anhang). Kernelement ist der Service-Steckbrief pro System mit Identifikation, Komponenten, Verantwortlichkeiten, Routinen, Monitoring und Eskalation. Im Notfall unverzichtbar: aktuelle Kontakte, Backup/Restore-Verfahren, Start-/Stop-Reihenfolgen, Lieferanten-Daten. Mit der CMDB verzahnen (Single Source of Truth festlegen) und über klaren Pflegeprozess (DoD bei Changes, Quartals-Review) aktuell halten – sonst wird die Doku gefährlicher als gar keine.
Verwandte Lektionen: Warum Doku · Server-Doku · Netzwerk-Doku · und mehrWeitere relevante LektionenProzess-DokuWiki-SystemeCMDBIncident ManagementChange ManagementBackup 3-2-1Failover