Infrastruktur & Security · Methode
„Warum ist das so eingestellt?“ — die teuerste Frage im Betrieb einer Anlage, die man allein verwaltet. Denn die Person, die es weiß, ist dieselbe, die fragt, nur ein halbes Jahr später.
Änderungsdokumentation gilt als Bürokratie für große Organisationen. Tatsächlich löst sie ein Problem, das im Kleinen genauso auftritt und dort sogar härter zuschlägt: Es gibt niemanden, den man fragen könnte.
Der eigentliche Zweck
Nicht Rechenschaft, sondern Rekonstruktion
In Unternehmen dient das Verfahren auch der Absicherung — wer hat was genehmigt. Allein betrieben entfällt dieser Teil vollständig, und mit ihm der Ruf der Bürokratie. Übrig bleibt der nützliche Kern: die Möglichkeit, einen Zustand später zu erklären.
Drei Situationen, in denen sich das auszahlt. Nach einer Störung: Was hat sich zuletzt geändert? Ohne Aufzeichnung beginnt jede Fehlersuche bei null. Bei einer Wiederherstellung: Der zurückgespielte Stand ist älter als die letzten Anpassungen — welche fehlen jetzt? Beim Wiedersehen mit alten Entscheidungen: Eine seltsame Einstellung ist entweder ein Fehler oder die Lösung eines Problems, das man vergessen hat. Ohne Notiz ist beides gleich wahrscheinlich, und man baut den alten Fehler nach.
Was hineingehört
Sechs Zeilen genügen
Ein Eintrag, der länger dauert als die Änderung selbst, wird nicht geschrieben. Deshalb kurz — aber mit diesen Feldern:
| Feld | Warum es zählt |
|---|---|
| Was geändert wurde | Der Zustand vorher und nachher, nicht der Befehl allein |
| Warum | Das einzige Feld, das man später nicht rekonstruieren kann |
| Wann | Erlaubt die Korrelation mit dem Beginn einer Störung |
| Betroffen | Welche Dienste hängen daran — die Liste überrascht oft |
| Rückweg | Wie man es rückgängig macht. Vor der Änderung notiert, nicht danach |
| Geprüft womit | Woran man erkannt hat, dass es funktioniert hat |
Das Feld „Warum“ trägt den ganzen Nutzen. Was geändert wurde, lässt sich notfalls aus der Versionsverwaltung ablesen. Die Begründung existiert nur im Kopf — und dort nicht lange.
Abstufung
Nicht jede Änderung braucht dasselbe Verfahren
Wer für jeden Handgriff ein Formular ausfüllt, hört nach zwei Wochen auf. Der Ausweg ist eine Staffelung nach Risiko — und ein Katalog wiederkehrender Arbeiten, die vorab freigegeben sind:
Wiederkehrende Routine
Anpassungen, die regelmäßig anfallen, ein bekanntes Ergebnis haben und einen erprobten Rückweg: Sicherheitsupdates in unkritischen Bereichen, Neustarts nach Anleitung, Erneuerung ohne geänderte Parameter, Dokumentationsänderungen ohne Systemwirkung. Kurz protokollieren, nicht abwägen.
Alles mit Wirkung
Konfigurationsänderungen, neue Dienste, Versionssprünge. Vorher aufschreiben, was passieren soll und wie der Rückweg aussieht — danach das Ergebnis. Der Aufwand liegt bei Minuten.
Erst handeln, dann schreiben
Bei einer laufenden Störung wird zuerst repariert. Der Eintrag folgt — aber verbindlich und mit Frist, nicht „bei Gelegenheit“. Sonst wird jede Änderung zum Notfall erklärt.
Beispiele
Wo sich der Eintrag garantiert auszahlt
Nicht jede Änderung ist gleich riskant. Diese hier haben eines gemeinsam: Sie wirken sofort, ihre Nebenwirkungen zeigen sich später, und die Ursache ist dann schwer zu finden.
| Änderung | Was später passiert | Was der Eintrag rettet |
|---|---|---|
| DNS-Eintrag angelegt oder geändert | Alles funktioniert — bis der zwischengespeicherte alte Wert an irgendeiner Stelle abläuft, oft Stunden später und nur für manche Geräte | Die Verbindung zwischen „seit heute Mittag geht Dienst X nicht“ und der Änderung von gestern Abend |
| Reverse-Proxy-Regel oder Zertifikat | Ein Tippfehler nimmt nicht einen Dienst vom Netz, sondern alle dahinterliegenden gleichzeitig | Der notierte Rückweg — im Ernstfall ist die Verwaltungsoberfläche mit betroffen |
| Firewall- oder Netzwerkregel | Der gewünschte Zugriff klappt; dass nebenbei ein anderer weggefallen ist, merkt man beim nächsten Sicherungslauf | Die Liste der betroffenen Dienste, die man vorher durchdacht hat |
| Container-Abbild aktualisiert | Die neue Fassung ändert stillschweigend ein Standardverhalten, eine Pfadangabe oder ein Datenbankschema | Die alte Versionsangabe — ohne sie ist der Rückweg Raten |
| Datenbank- oder Schema-Migration | Läuft durch, ist aber nicht ohne Weiteres umkehrbar; ältere Sicherungen passen danach nicht mehr zur Anwendung | Der Hinweis, dass hier ein Rückweg nur über die Sicherung führt — und welche das ist |
| Betriebssystem- oder Kernel-Upgrade | Ein Treiber, ein Dateisystem-Modul oder eine Container-Laufzeit verhält sich anders; die Störung zeigt sich erst beim nächsten Neustart, Wochen später | Die zeitliche Zuordnung — sonst sucht man den Fehler in der Anwendung |
| Berechtigung oder Zugangstoken erneuert | Nichts fällt aus, solange das alte noch gilt. Danach bricht eine Automatik ab, die niemand beobachtet | Die Erinnerung daran, dass es hier eine Frist gibt — und wo sie hinterlegt ist |
Auffällig ist das Muster: In fast allen Fällen liegt zwischen Änderung und Störung genug Zeit, dass der Zusammenhang nicht mehr auffällt. Genau diese Lücke schließt der Eintrag — er ist weniger Dokumentation als Zeitstempel.
Die Falle
Umgesetzt, ohne je freigegeben zu sein
Das häufigste Versagen ist nicht die fehlende Dokumentation, sondern die halbe: Ein Vorgang wird angelegt, die Arbeit passiert — und der Eintrag bleibt für immer im Zustand „geplant“. Nach einem halben Jahr steht in der Aufzeichnung eine Liste von Vorhaben, von denen niemand weiß, welche davon Wirklichkeit sind.
Das ist schlimmer als gar keine Aufzeichnung, weil sie Vertrauen beansprucht, das sie nicht verdient. Dagegen hilft nur eine harte Regel: Ein Vorgang wird geschlossen oder er wird zurückgenommen. Offene Einträge älter als eine gesetzte Frist sind selbst ein Befund und gehören durchgesehen.
Zwei weitere Muster, die dasselbe Ergebnis haben
- Rückweg erst hinterher notiert. Wer den Rückweg nach der Änderung aufschreibt, beschreibt eine Vermutung. Vorher aufgeschrieben zwingt er dazu, überhaupt einen zu haben.
- Prüfung ohne Kriterium. „Läuft“ ist kein Prüfergebnis. Ohne vorher festgelegtes Kriterium bestätigt man nach der Änderung genau das, was man sehen will.
Praktisch
Womit man das führt
Es gibt drei brauchbare Wege, alle quelloffen und alle richtig — je nachdem, was man sucht:
Git, neben der Konfiguration
Wenn die Konfiguration ohnehin versioniert ist, gehört die Begründung in die Commit-Nachricht. Änderung und Warum stehen dann untrennbar im selben Verlauf, und git log beantwortet die Frage „was hat sich zuletzt geändert“ ohne Zusatzsystem.
Obsidian oder schlichtes Markdown
Für alles, was mehr Fließtext braucht als eine Commit-Zeile: Entscheidungen, Alternativen, Überlegungen. Verlinkbar, durchsuchbar, ohne Server — und die Dateien bleiben lesbar, auch wenn das Programm einmal nicht mehr existiert.
GLPI und ähnliche
Lohnt sich, sobald man Vorgänge suchen, verknüpfen und ihren Zustand auswerten will — etwa „welche Änderungen betrafen diesen Dienst“ oder „was steht seit Monaten offen“. GLPI führt Inventar, Störungen und Änderungen in einem System, was die Verknüpfung erst möglich macht.
Die Kombination ist verbreiteter als die reine Lehre: Begründung im Commit, Entscheidung in einer Notiz, Vorgang im Ticketsystem — solange klar ist, welche Ebene wofür zuständig ist. Unklar wird es, wenn dieselbe Information an zwei Orten steht und einer davon veraltet.
Entscheidend ist nicht das System, sondern dass der Eintrag im selben Arbeitsgang entsteht wie die Änderung. Alles, was auf „später sauber nachtragen“ hinausläuft, geschieht nicht. Nicht aus Nachlässigkeit — sondern weil die Begründung bis dahin verblasst ist und der Eintrag dann tatsächlich nur noch Bürokratie wäre.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.