Ein Betriebshandbuch, das Ihre IT wirklich benutzt

Nach jedem Projekt frage ich mich, ob dieses Handbuch in sechs Monaten noch funktioniert, wenn jemand anderes nachts darauf zugreift. Die Antworten, die tragen, entstehen aus Störungsfällen, nicht aus Strukturwunsch.

Was rein gehört

Ein Handbuch ist ein Ablaufkatalog. Alles andere ist Anhang.

• Wo läuft was. Host, Port, Pfad, Version. Eine Tabelle, kein Fließtext.
• Wie prüfe ich, ob es läuft. Ein Befehl, eine erwartete Ausgabe.
• Was tue ich, wenn nicht. Reihenfolge mit Abbruchbedingung.
• Wen rufe ich, wenn diese Liste durch ist. Name, Nummer, letzte Änderung dran.

Beispiel: Prüfschritt als Code

Ein Prüfschritt ist ausführbar oder er ist keiner.

# läuft der Dienst und antwortet das Modell?
systemctl is-active ollama
curl -s localhost:11434/api/tags | head -c 200

Erwartete Ausgabe daneben, nicht "Siehe Dokumentation".

Was nicht rein gehört

Begründungen. Die Begründung einer Entscheidung gehört in die Entscheidung, also in einen kurzen ADR-Ordner, der im Handbuch verlinkt ist. Wer nachts liest, braucht Anweisungen. Wer am Montag aufräumt, braucht Gründe. Zwei Dokumente, zwei Leser.

Wartung als Vertrag

Ein Handbuch ohne Verfallsdatum ist ein Text, dem niemand glaubt. Deshalb:

1. Letzte Prüfung oben auf Seite eins, mit Datum.
2. Ein Terminkalender-Eintrag pro Quartal, 30 Minuten, zwei Prüfschritte nachfahren.
3. Wer prüft, trägt das Datum ein. Nicht derjenige, der geschrieben hat.

Das ist die ganze Mechanik. Sie hält ein Handbuch zwei Jahre aktuell, weil sie weniger kostet als das Nachschlagen im Projektchat von damals.