Am 20. Juni 2026 zeigte eine Übersichtsseite meiner Plattform jede Kachel mehrfach. In der Datenbank standen 195 templates. Hingehört hätten 44.
Ein Einrichtungsschritt kopiert diese Templates in den Bereich eines Kunden. Der Einrichtungsschritt war mehrfach gelaufen, und jeder Lauf hatte alle Vorlagen noch einmal angehängt.
Auf meinem eigenen Rechner war davon nichts zu sehen. Der Fehler zeigte sich erst auf der Instanz, die schon lange lief.
Die Ursache: ein Schritt, der sich nicht wiederholen ließ#
Die Datenbank hatte keinen Fehler gemacht. Jede Zeile trug eine eigene Kennung, also gab es für die Datenbank keinen Grund zu widersprechen.
Die Ursache war der Schritt selbst. Vergessen - “if exists - skip” Er fragte nicht, ob ein Teplate schon da ist. Er legte an.
Daraus folgt der Satz, um den es in diesem Beitrag geht:
Ein Einrichtungsschritt ist erst richtig, wenn ein zweiter Lauf nichts mehr ändert. Idempotenz
Für Daten hat die Abhilfe zwei Teile. Erstens wird die Kennung einer Kopie aus Kunde und Name berechnet. Ein zweiter Lauf trifft dann dieselbe Zeile, statt eine neue anzulegen. Zweitens lehnt eine Sperre in der Datenbank doppelte Namen je Kunde ab. Der erste Teil macht den Schritt richtig. Der zweite macht den nächsten fehlerhaften Schritt sofort laut. Aufräumen allein verhindert die Rückkehr nicht.
Für Server gilt derselbe Satz.
Derselbe Gedanke für Server#
Die vier Begriffe stammen aus dem ersten Beitrag dieser Reihe. Für einen Server bedeuten sie:
| Begriff | Beim Server |
|---|---|
| Auftrag | Der festgelegte Zustand. Er steht in einer Ablage mit Versionsgeschichte, dem Repository. Er steht nicht im Kopf und nicht nur auf dem Server. |
| Toleranz | Was sich unterscheiden darf, ohne dass es jemanden kümmert: Protokolle, Laufzeitdaten, Zwischenstände. |
| Wand | Wer den Server überhaupt ändern kann. |
| Rest | Jede Änderung, die möglich ist, aber nirgends festgelegt wurde. |
Ein Programm liest den festgelegten Zustand und stellt ihn auf dem Server her. Bei mir ist das Ansible. Läuft Ansible zweimal hintereinander und ändert beim zweiten Mal nichts, dann stimmen Soll und Ist überein. Das ist die ganze Prüfung. Sie kostet einen zweiten Lauf.
Drei Stellen, an denen der Rest entsteht#
Die Handänderung. Ein von Hand gepflegter Namenseintrag auf meinem Arbeitsrechner zeigte auf den falschen Server. Korrigiert wurde das am 21. September 2026. Ein Lauf, der den Eintrag gegen eine Festlegung prüft, hätte die Abweichung beim ersten Mal gemeldet.
Das Werkzeug, das selbst umschreibt. Für Zertifikate gibt es ein verbreitetes Werkzeug, das auf Wunsch die Einstellungen des Webservers gleich mit anpasst. Danach gibt es Duplikate == zwei Fassungen derselben Datei: Datei im Repository und Datei auf dem Server. Bei mir ist diese Betriebsart gesperrt. Das Werkzeug holt das Zertifikat und sonst nichts.
Die zweite Kopie. Beim Bauen meiner Anwendung wurde eine Kopie der Einstellungsdatei mit ins Ergebnis gelegt. Zur Laufzeit überstimmte diese alte Kopie die Einstellungen, die der Server vorgab. Seitdem gilt: Die Einstellungen des Servers sind die Wahrheit. Die Anwendung ergänzt nur dort, wo nichts gesetzt ist.
Auch die Messung kann falsch sein#
Ein Dienst ohne Überwachung existiert bei mir nicht. Aber eine Überwachung kann grün zeigen und trotzdem nichts messen.
Ein Beispiel ist die Datenbank PostgreSQL unter Debian. Dort gibt es einen Sammeldienst, der „aktiv“ meldet, auch wenn die eigentliche Datenbank nicht läuft. Wer den Sammeldienst abfragt, misst das Falsche. Richtig ist die Frage an die Datenbank selbst: Nimmst du Verbindungen an?
Das zweite Beispiel ist die Frage, welche Version gerade läuft. Nach jedem Deploy (Ausrollen) vergleicht mein Lauf die Kennung der laufenden Version mit der Kennung, die ausgerollt werden sollte. Stimmen beide nicht überein, gilt das Deploy als gescheitert.
Toleranz muss festgelegt sein#
Beim Deploy meiner Anwendung legt jeder Lauf absichtlich eine neue Version an und behält die letzten drei. Dort wäre „der zweite Lauf ändert nichts“ die falsche Prüfung.
Geprüft wird stattdessen: kein Fehler, und die Versionskennung stimmt. Diese Ausnahme steht in der Regel selbst.
So mache ich das#
So betreibe ich die Server von OTSM:
- Die Regel lautet: Jede Änderung an einem Server läuft über das Repository und einen Lauf. Anmelden, von Hand nachziehen, bauen und neu starten ist nicht vorgesehen. Fehlt der passende Baustein, wird zuerst der Baustein gebaut. Jegliche Ausnahme muss ausdrücklich und mit Grund benannt werden.
- Ein Lauf ändert nur den Baustein, um den es geht. Früher zog ein gezielter Lauf auch die Grundeinrichtung mit, und aus einer kleinen Korrektur wurde eine Sammeländerung. Seit dem 12. Mai 2026 trägt jeder Baustein eine eigene Marke, über die er einzeln aufgerufen wird.
- Eine Änderung gilt erst als fertig, wenn der Lauf zweimal hintereinander ohne Fehler durchgeht und der zweite Lauf nichts mehr ändert.
- Jeder neue Dienst schreibt in das Protokoll des Systems und bekommt einen Eintrag in der Überwachung.
- Versionen von Bausteinen sind fest angegeben, nicht als Bereich.
- Zugangsschlüssel kommen aus einer Quelle. Einzeln von Hand nachtragen ist verboten, weil der nächste Lauf die Liste vollständig ersetzt.
Der Test für Ihren Betrieb#
Dieser Abschnitt richtet sich an Sie, wenn Sie eigene Server verantworten, im Haus oder gemietet.
Die Behauptung: Wenn Störungen daher kommen, dass der Zustand Ihrer Server nirgends festgelegt ist und von Hand verändert wird, dann beseitigen die folgenden vier Schritte die Störungen, deren Suche mit der Frage beginnt: Was ist auf diesem Server eigentlich eingestellt?
- Einen Server auswählen und seinen Zustand festlegen. Im Repository, hergestellt durch ein Programm. (Ich weiß Ansible ist nicht Jedermanns sache, aber es gibt da in der Zwischenzeit richtig gute User Interfaces um den Preis der Exposition durch die UI)
- Zweimal laufen lassen. Der zweite Lauf darf keine Änderungen melden.
- Jede Woche einen Prüflauf ohne Änderungsauftrag. Das Programm meldet, was es ändern würde, und ändert nichts. Ansible kennt dafür eine eigene Betriebsart.
- Je Dienst eine Frage an den Dienst selbst als Überwachung, nicht an eine Sammelanzeige.
Gemessen wird so:
- Messgröße: die Zahl der Abweichungen, die der wöchentliche Prüflauf meldet.
- Zielwert (mein Vorschlag): vier Wochen in Folge null unerklärte Abweichungen.
- Was der Befund bedeutet: Meldet der Prüflauf eine Abweichung, die gewollt ist, dann fehlt eine Toleranz in der Festlegung. Meldet er eine, die niemand erklären kann, dann gibt es einen Änderungsweg am Repository vorbei. Prüfen Sie in diesem Fall die Wand: Wer kann sich auf dem Server anmelden?
- Abbruchkriterium: Bleiben die Störungen, obwohl der Prüflauf vier Wochen lang null meldet, dann liegt die Ursache nicht im Zustand des Servers. Suchen Sie dann in der Anwendung und in den Daten. Mein Beispiel vom Anfang war ein solcher Fall.
Der Preis, wenn Sie nichts tun: Ein Server, dessen Zustand nirgends steht, lässt sich nach einem Ausfall nur aus dem Gedächtnis wieder aufbauen. Und jede Fehlersuche beginnt damit, den Server zu erkunden.
Wo die Methode aufhört#
Sie vergleicht nur, was festgelegt ist. Was das Programm nicht kennt, prüft es nicht: Inhalte der Datenbank, Dateien, die jemand außerhalb der Festlegung angelegt hat.
Zwischen zwei Läufen misst niemand. Die Grafik zeigt es zwischen Punkt 4 und Punkt 5. Wie oft Sie prüfen, legt fest, wie lange eine Abweichung unbemerkt bleibt.
Der Doppellauf zeigt Übereinstimmung, nicht Richtigkeit. Ein falsch festgelegter Zustand wird zuverlässig falsch hergestellt.
Wie es weitergeht#
Der dritte Beitrag wendet dieselben Begriffe auf Programmierregeln an: Jede Regel trägt einen Grund und entweder eine Prüfung oder einen Namen.