Ein Betriebshandbuch, das im Notfall funktioniert – die Struktur, die wir seit Jahren verwenden

Ein Betriebshandbuch ist kein Architekturkonzept mit einem anderen Dateinamen, und es ist auch keine Sammlung aus Screenshots, Installationsprotokollen und Herstellerlinks, die irgendwann während des Projekts zusammengetragen wurde. Die Frage, an der sich entscheidet, ob ein Betriebshandbuch etwas taugt, ist deutlich einfacher: Kann ein Administrator, der das System nicht selbst aufgebaut hat, damit um drei Uhr nachts eine Störung beurteilen und die richtigen Schritte einleiten? Wenn die Antwort Nein lautet, ist die Dokumentation vielleicht vollständig – betriebsfähig ist sie damit noch lange nicht.

Das Problem begegnet mir in Reviews ständig. Technisch sind die Systeme meistens sauber aufgebaut, es gibt Konzepte, Projektunterlagen, vielleicht sogar eine ordentliche Übergabepräsentation. Nur die Informationen, die ein Betriebsteam später tatsächlich braucht, sind über mehrere Ablagen verstreut oder stecken schlicht im Kopf der Leute, die das System eingeführt haben. Genau diese Lücke soll ein Betriebshandbuch schließen, und genau daran scheitern die meisten.

Erst muss klar sein, was da überhaupt beschrieben wird

Jedes Betriebshandbuch sollte mit einer knappen Einordnung anfangen – nicht mit zehn Seiten Projektgeschichte, sondern mit ein paar einfachen Antworten: Welche Aufgabe erfüllt das System, welche Komponenten gehören dazu, wo läuft es, was hängt davon ab, und wovon hängt es selbst ab? Wer betreibt es, wer darf Änderungen vornehmen, und was passiert eigentlich, wenn es ausfällt?

Gerade die Abhängigkeiten werden gern unterschätzt. Ich habe genug Fälle gesehen, in denen ein Active-Directory-naher Dienst technisch kerngesund aussah und trotzdem nicht funktionierte, weil DNS, PKI, das Netzwerk, der Storage oder ein vorgeschalteter Dienst gerade Probleme machte. Ein Betriebshandbuch muss deshalb nicht nur beschreiben, was da ist, sondern auch, wie es zusammenhängt – und eine einfache Architekturübersicht leistet dabei meistens mehr als drei Seiten Fließtext.

Sollzustand statt Installationsgeschichte

Ein Fehler, der mir regelmäßig unterkommt: Dokumentation wird chronologisch geschrieben. Zuerst wurde Server A installiert, dann eine Einstellung geändert, später kam Server C dazu. Für ein Projekttagebuch ist das in Ordnung. Für den Betrieb interessiert aber fast ausschließlich eine Frage – wie muss die Umgebung heute aussehen –, und genau diesen Sollzustand sollte das Handbuch dokumentieren: Server und Rollen, Netzwerke und Ports, Dienste, Clusterrollen, Speicher, Zertifikate, Service Accounts, Berechtigungen, Gruppen, geplante Tasks, Monitoring, Backup, Schnittstellen und die relevanten Gruppenrichtlinien.

Bei sicherheitskritischen Systemen gehört dazu auch, welche Einstellungen bewusst so gesetzt wurden und warum. Denn irgendwann, meistens zwei Jahre später, stellt jemand die Frage, ob diese eine Einstellung noch gebraucht wird – und an dem Punkt hilft ein dokumentiertes Warum erheblich mehr als ein Screenshot des ursprünglichen Dialogfensters, das ohnehin niemand mehr wiedererkennt.

Der tägliche Betrieb braucht eigene Anweisungen

Sobald der technische Aufbau steht, beginnt der eigentliche Betriebsteil, und hier muss ein Administrator erkennen können, was regelmäßig zu prüfen ist. Dienststatus, Replikationszustand, Zertifikatslaufzeiten, Backupstatus, Eventlogs, Kapazitäten – wobei es nicht darum geht, möglichst viele Kontrollpunkte zu produzieren. Eine Prüfliste mit achtzig Punkten, die ohnehin niemand abarbeitet, ist schlechter als zehn Kontrollen, deren Sinn jeder versteht.

Für jede dieser Aufgaben sollten vier Dinge klar sein: was geprüft wird, wie es geprüft wird, wie ein gültiges Ergebnis aussieht – und was zu tun ist, wenn das Ergebnis abweicht. Der letzte Punkt fehlt erstaunlich oft, dabei ist er der eigentliche Grund, warum die Prüfung überhaupt dokumentiert wird.

Runbooks müssen ausführbar sein, nicht nur beschreibend

Das wichtigste Kapitel eines guten Betriebshandbuchs sind aus meiner Sicht die Runbooks. Ein Runbook beschreibt eine konkrete Betriebssituation – der Dienst startet nicht, ein Zertifikat läuft ab, ein Domain Controller ist nicht erreichbar, ein Clusterknoten fällt aus, ein Storagepfad fehlt, ein Server muss neu aufgebaut oder ein Restore durchgeführt werden – und führt durch die nötigen Schritte. Eine Anweisung wie „Replikation prüfen" reicht dafür nicht aus.

Ein Runbook, das seinen Zweck erfüllt, braucht deutlich mehr: welche Voraussetzungen und Berechtigungen nötig sind, mit welchem Befehl oder Werkzeug geprüft wird, woran man das erwartete Ergebnis erkennt, was bei welchem Ergebnis zu tun ist, welche Änderung konkret ausgeführt wird, wie man anschließend kontrolliert, ob sie funktioniert hat, wie man sie im Zweifel zurücknimmt, und ab welchem Punkt eine andere Rolle oder der Hersteller eingebunden werden muss. Erst mit all dem wird aus einer Beschreibung ein Werkzeug, das jemand unter Druck tatsächlich benutzen kann.

Der Ernstfall braucht ein eigenes Kapitel

Normalbetrieb und Notfallbetrieb sollte man nicht miteinander vermischen. Wenn ein ganzer Dienst ausgefallen ist, will niemand erst hundertzwanzig Seiten Betriebsdokumentation durchsuchen, um die relevante Stelle zu finden. Ein Betriebshandbuch sollte deshalb eindeutig auf ein separates Notfallhandbuch mit belastbarem Wiederanlaufplan verweisen oder zumindest einen klar abgegrenzten Notfallteil haben, der die Kriterien für einen Notfall, Prioritäten, Ansprechpartner und Rollen, die Wiederanlaufreihenfolge, technische Abhängigkeiten, verfügbare Backups, den sicheren Ablageort benötigter Zugangsdaten, Kommunikationswege, Entscheidungsbefugnisse, die Wiederherstellungsprozeduren selbst und die Prüfungen danach enthält.

Es geht dabei nicht darum, jede denkbare Katastrophe im Voraus durchzuspielen. Es geht darum, dass im Ernstfall möglichst wenige Entscheidungen zum ersten Mal unter Zeitdruck getroffen werden müssen.

Der Drei-Uhr-nachts-Test

Bei Reviews von Betriebsdokumentation nutze ich gern eine simple Vorstellung: Ein Administrator wird nachts wegen einer Störung angerufen. Er kennt die Plattform grundsätzlich, hat dieses konkrete System aber nicht selbst aufgebaut. Reicht die Dokumentation, damit er die Lage einschätzen kann, ohne den ursprünglichen Architekten aus dem Bett zu klingeln?

Wenn die Antwort Nein lautet, fehlen meistens keine hundert Seiten. Es fehlen typischerweise nur eine Handvoll entscheidender Informationen – die Abhängigkeiten, der Sollzustand, die Prüfbefehle samt erwarteten Ergebnissen, die Entscheidungswege, die Wiederanlaufreihenfolge, der Rollback, die Eskalation, die Ansprechpartner und die Begründungen der wichtigsten Designentscheidungen. Ich habe selten erlebt, dass mehr fehlte – meistens genau diese Handvoll.

Dokumentation ist Teil der Änderung, nicht ihr Anhang

Das größte organisatorische Problem bei Betriebshandbüchern ist gar nicht, sie zu schreiben. Es ist, sie aktuell zu halten. Sobald Server hinzukommen, Namen sich ändern, Zertifikate ausgetauscht, Netzwerkpfade angepasst oder Betriebsverfahren geändert werden, muss die Dokumentation Teil derselben Änderung sein – nicht ein Punkt, den man sich für später vornimmt und dann doch nie umsetzt. Die einzige Formulierung, die in der Praxis funktioniert, ist eine, die keinen Spielraum lässt: Eine technische Änderung gilt erst dann als abgeschlossen, wenn die betroffene Betriebsdokumentation angepasst wurde. Damit wird Dokumentation vom Projektartefakt zum Bestandteil des Systems selbst.

Fazit

Ein gutes Betriebshandbuch muss nicht besonders lang sein, es muss zuverlässig Antworten liefern. Es beschreibt den Sollzustand, macht Abhängigkeiten sichtbar, erklärt die wiederkehrenden Betriebsaufgaben und enthält Runbooks, die im Ernstfall wirklich funktionieren. Der Maßstab dafür ist am Ende nicht die Seitenzahl, sondern eine einzige Frage: Kann jemand anderes das System betreiben, ohne mich anzurufen? Bei uns ist ein System erst dann übergeben, wenn diese Frage mit Ja beantwortet ist.