ITIL im Homelab: Standard-, Normal- und Notfalländerung klar getrennt

Wenn du im Homelab einen automatisierten Assistenten mit SSH- und API-Zugriff auf produktive Server arbeiten lässt, brauchst du eine klare Grenze zwischen Routinearbeit und Eingriffen mit Ausfallrisiko. Ohne feste Regeln fragt die Automatisierung entweder wegen jeder Konfigurationszeile nach oder startet zur falschen Zeit einen Host neu. Ich habe dafür das Change Enablement aus ITIL auf mein Homelab übertragen und alle Eingriffe in drei Änderungsarten aufgeteilt.

Drei Änderungsarten nach ITIL im Homelab

In großen IT-Abteilungen füllt Change Enablement ganze Handbücher und Gremien. Im Homelab reicht eine knappe Arbeitsanweisung, solange sie eindeutig trennt, was sofort passieren darf und wo ich als Administrator vorab draufschauen muss. Die Unterscheidung orientiert sich direkt an den drei klassischen ITIL-Kategorien Standard, Normal und Notfall.

Änderungsart	Voraussetzung	Beispiele aus dem Betrieb	Dokumentation und Freigabe
Standardänderung	Im Katalog der Dauerfreigaben enthalten	Dienstkonfiguration anpassen, Paket eines Dienstes pflegen, Checkmk per REST-API aktualisieren, Doku committen	Vorab dauerhaft freigegeben, Durchführung ohne Rückfrage
Normaländerung	Jeder andere Eingriff in ein produktives System	Host- oder Gast-Neustart, System-Update, Firewall-Regel, VLAN, DNS-Zone, Löschen von Daten oder Gästen	Aufgabe anlegen, Plan mit Rückfallweg vorlegen, Backup-Fenster beachten, Einzelfreigabe abwarten
Notfalländerung	Dienst ausgefallen oder Datenverlust droht und Administrator nicht erreichbar	Eigene letzte Änderung zurücknehmen, hängenden Dienst neu starten	Sofort melden, Logeintrag „Notfalländerung“ schreiben, Aufgabe nachträglich anlegen

Der Grundsatz hinter dieser Aufteilung ist simpel. Als Standardänderung gilt ausschließlich, was wörtlich im Katalog der Dauerfreigaben steht. Alles, was dort fehlt oder ausdrücklich ausgenommen ist, fällt automatisch unter die Normaländerung und wartet auf meine Freigabe.

Standardänderungen: Was ohne Rückfrage erlaubt ist

Damit der Assistent im Alltag selbstständig arbeiten kann, enthält die Betriebsdokumentation einen festen Katalog vorab freigegebener Standardänderungen. Grundlage für den Zugriff auf die Server ist die zentrale Inventardatei assets.yaml. Auf den dort hinterlegten Linux- und BSD-Systemen – konkret den drei Proxmox-Knoten, dem Management-Server, der Home-Assistant-Instanz, dem KI-Host, dem GitLab-Server und der OPNsense-Firewall – arbeitet der Assistent per Root-SSH. Auf Windows-Systemen nutzt er WinRM mit einem eigenen Dienstkonto über ein Python-Hilfsskript.

Innerhalb dieses Rahmens darf er Konfigurationen ändern, einzelne Dienste und deren Pakete einrichten oder pflegen sowie Dateien anlegen und anpassen. In den Arbeitsregeln steht dafür ein ausdrücklicher Hinweis: Der Assistent soll solche Standardaufgaben erst selbst versuchen, auch wenn eine ähnliche Aktion in einer früheren Sitzung abgelehnt wurde. Das verhindert, dass er nach einem einmaligen Fehler dauerhaft in einen passiven Fragemodus verfällt.

Netzwerk, DHCP und Monitoring

Wiederkehrende Infrastrukturaufgaben gehören ebenfalls in den Katalog. Wenn ich einen neuen Server im Subnetz 192.0.2.0/24 in Betrieb nehme, setzt der Assistent die Basiswerte ohne Rückfrage: Gateway 192.0.2.1, die beiden DNS-Server 192.0.2.12 und 192.0.2.13 sowie die Suchdomäne example.lan. Er fragt mich vorab nur nach der freien Host-IP, die das System bekommen soll.

Ähnlich geregelt ist die Pflege von DHCP-Reservierungen und Bereichen. Da zwei Windows-Domain-Controller auf .12 und .13 den Dienst bereitstellen, führt der Assistent jede DHCP-Änderung einzeln auf beiden Systemen aus und vergleicht direkt danach den Stand beider Server. Im Monitoring darf er Checkmk über die REST-API pflegen. Auch Artikel und Seiten in der Dokumentation und im Intranet darf er direkt bearbeiten und veröffentlichen.

Dateiserver: Softwarearchiv und Betrieb

Der Katalog wächst mit den Aufgaben im Homelab. Am 2. November 2026 habe ich eine Dauerfreigabe für das Softwarearchiv auf dem zentralen Dateiserver ergänzt. Dort liegen Installationspakete und Firmware für die Umgebung. Der Assistent darf per SSH ausschließlich in den beiden Pfaden /srv/daten-pool/Software und /srv/daten-pool/Betrieb lesen und schreiben. Andere Verzeichnisse im Storage-Pool sind tabu.

ssh dateiserver "su -s /bin/sh daten-benutzer -c 'umask 007 && sha256sum firmware.bin > firmware.bin.sha256'"

Damit die Dateirechte im Pool konsistent bleiben, wechselt der Aufruf auf dem Dateiserver immer auf den Besitzer des Archivs, einen eigenen Benutzer, und setzt umask 007. Berechtigungen bestehender Ordner oder Dateien darf der Assistent nicht verändern. Legt er einen neuen Installer oder ein Firmware-Abbild ab, muss er zwingend eine .sha256-Prüfsummendatei und eine .txt-Beschreibung danebenlegen. Vorhandene Dateien im Archiv zu löschen oder zu überschreiben ist keine Standardänderung; dafür braucht er meine Einzelfreigabe.

Git-Repositories und Merge Requests

Auch bei der Versionsverwaltung unterscheidet der Katalog genau nach Projekt und Herkunft der Änderung:

• Im zentralen Dokumentations-Repository sind Commit und Push auf den lokalen Branch master über ein Synchronisationsskript direkt freigegeben.
• In allen anderen Projekten auf dem lokalen GitLab-Server läuft jede Änderung über einen Merge Request.
• Eigene Merge Requests darf der Assistent mit einem Hilfsskript unter Angabe von Projekt und interner ID selbst zusammenführen.
• Merge Requests von Menschen oder von Renovate lasse ich ausschließlich durch mich als Administrator zusammenführen; das gilt genauso für die automatisch erzeugten Änderungen am Skript-Repository.

Ebenfalls in den Katalog fällt die Pflege der eigenen Steuerdateien des Assistenten. Er darf seine Anweisungsdateien, Rollenbeschreibungen und Gedächtniseinträge kürzen, Tippfehler korrigieren und Widersprüche auflösen, solange er sich damit keine neuen Befugnisse einräumt. Vor jeder Änderung legt er eine Sicherungskopie in einem lokalen Rückfallordner ab. Automatische Vorabprüfungen darf er nachschärfen oder um Fehlalarme bereinigen, wenn er dafür passende Testfälle anlegt und die Änderung durch ein zweites Sprachmodell gegenprüfen lässt. Die zentrale Laufzeitkonfiguration selbst bleibt davon ausgenommen und erfordert immer meine Freigabe.

Warum „Erst selbst versuchen“ im Katalog steht

Ein Punkt im Katalog der Standardänderungen ist direkt aus der täglichen Praxis mit Sprachmodellen entstanden. Wenn ein Befehl einmal an einer technischen Sperre scheitert oder ich in einer Sitzung einen Vorschlag ablehne, merkt sich der Assistent diesen Kontext oft zu gründlich. Beim nächsten Mal fragt er dann selbst bei harmlosen Routineaufgaben um Erlaubnis, obwohl die Aktion im Katalog längst freigegeben ist.

Deshalb enthält der Abschnitt zu Schreibaktionen per SSH und WinRM die ausdrückliche Vorgabe, erlaubte Schritte zuerst selbst auszuführen, auch wenn eine ähnliche Aktion zuvor abgelehnt wurde. Erst wenn ein Eingriff unter die genannten Ausnahmen fällt oder technisch blockiert wird, hält der Assistent an und legt den Fall zur Entscheidung vor. Auf diese Weise bleibt die Grenze zwischen Standard- und Normaländerung stabil und verschiebt sich nicht schleichend durch vergangene Sitzungen.

Normaländerungen: Wann ein Plan und meine Freigabe Pflicht sind

Sobald ein Eingriff über das Einrichten eines einzelnen Dienstes hinausgeht oder den laufenden Betrieb unterbrechen kann, greift die Normaländerung. Im Katalog sind die wichtigsten Ausnahmen explizit aufgezählt, damit es bei SSH- und WinRM-Zugriffen keinen Interpretationsspielraum gibt.

Folgende Arbeiten sind von den Dauerfreigaben ausgenommen und erfordern immer meine Einzelfreigabe:

• Neustart produktiver Systeme, Hypervisoren, virtueller Maschinen und Container
• Löschen von virtuellen Gästen, Datenträgern oder vorhandenen Nutzdaten
• Löschen oder Überschreiben vorhandener Dateien im Softwarearchiv und Betriebsverzeichnis des Dateiservers
• System-Updates auf Hosts und Gästen
• Änderungen an Firewall-Regeln, VLAN-Zuweisungen und DNS-Zonen
• Zusammenführen fremder Merge Requests (das macht nur der Administrator) sowie Änderungen an den Einstellungen des Assistenten selbst

Für jede Normaländerung legt der Assistent vorab eine eigene, als freigabepflichtig markierte Aufgabe an. Darin beschreibt er den geplanten Eingriff und den konkreten Rückfallweg, falls nach einem Paket-Update oder einer geänderten Firewall-Regel ein Dienst nicht mehr sauber startet. Ebenso prüft er vorab das Backup-Fenster und den Betriebskalender. Im nächtlichen Backup-Fenster oder bei einer Wartung im Betriebskalender bleibt das produktive System unangetastet.

Notfalländerungen: Nur das Kleinste, das den Schaden stoppt

Eine Notfalländerung greift nur unter zwei Bedingungen, die gleichzeitig erfüllt sein müssen: Ein Dienst ist akut ausgefallen oder es droht Datenverlust, und ich bin als Administrator nicht erreichbar. Ist nur eine der beiden Bedingungen erfüllt – klemmt also ein unkritischer Dienst, während ich am Schreibtisch sitze –, bleibt es eine reguläre Abstimmung.

Tritt der Ernstfall ein, ist der Spielraum absichtlich extrem eng gefasst. Der Assistent darf ausschließlich das Kleinste tun, was den unmittelbaren Schaden stoppt. In der Praxis sind das genau zwei Handgriffe: die eigene letzte Änderung wieder zurücknehmen oder einen hängenden Dienst neu starten. Größere Umbauten, Paket-Upgrades auf Verdacht oder das Löschen vermeintlich defekter Datenbestände sind auch im Notfall verboten.

Wichtig für die Betriebssicherheit ist, dass ein Notfall keine technischen Sicherungen außer Kraft setzt. Die technischen Schutzmechanismen und das Backup-Fenster bleiben auch im Notfall in Kraft. Wenn eine Aktion blockiert wird, darf der Assistent die Sperre nicht umgehen.

Unmittelbar nach dem Eingriff folgt die Nacharbeit. Der Assistent schickt mir sofort eine Meldung, schreibt einen Logeintrag mit dem Vermerk „Notfalländerung“ und zieht die zugehörige Aufgabe in der Dokumentation nach. So sehe ich beim nächsten Blick ins System sofort, welcher Dienst wann neu gestartet oder auf welchen Stand zurückgerollt wurde, und kann die eigentliche Ursache in Ruhe als reguläre Aufgabe beheben.