Infrastruktur ist ein versioniertes Produkt
Einführung · 6 Abschnitte · ~11 Min Lesezeit · Stand
Deklarativ statt Erinnerung
Infrastructure as Code macht gewünschte Zustände überprüfbar, wiederholbar und reviewbar. Es ersetzt nicht die Architekturentscheidung, aber es reduziert Drift und schafft einen nachvollziehbaren Wiederherstellungsweg.
Deklarativ heißt: du beschreibst den Zielzustand, das Werkzeug ermittelt den Weg dorthin. Der Nutzen entsteht aber erst im Regelkreis — beschreiben, prüfen, begrenzt anwenden, den tatsächlich erreichten Zustand mit dem beschriebenen vergleichen und Abweichungen zurückführen.
- Zielzustand beschreiben
- Diff reviewen
- Begrenzt anwenden
- Erreichten Zustand vergleichen
- Wirkung gegen Erfolgskriterium prüfen
- Abweichung zurückführen
Die beiden Prüfschritte beantworten verschiedene Fragen, und beide müssen gestellt werden. Der Zustandsabgleich fragt: Stimmt die Konfiguration? — deckt sich das Laufende mit dem Beschriebenen. Die Wirkungsprüfung fragt: Verhält sich das System wie erwartet? — treffen Kommunikation, Fehlerraten und Ressourcenwirkung das vorher festgelegte Erfolgskriterium. Eine sauber angewandte Änderung kann trotzdem die falsche gewesen sein, und nur die zweite Frage bemerkt das.
Plattformgrenzen
| Grenze | Frage |
|---|---|
| Identity | Wer darf welche Änderung oder Laufzeitaktion ausführen? |
| Netzwerk | Welche Kommunikationswege sind ausdrücklich erlaubt? |
| Ressourcen | Welche Anfrage darf wie viel Kapazität beanspruchen? |
| Mandant | Welche Daten und Ausfälle dürfen sich niemals kreuzen? |
Diese vier Grenzen fallen selten zusammen — jede ist eine eigene Entwurfsfrage mit eigener Antwort und einem eigenen Instrument. Wer sie mit einem einzigen groben Instrument beantwortet, etwa indem er zwei Workloads schlicht in dieselbe Umgebung legt, löst eine Frage und öffnet drei andere.
- Identity — eine Rolle im Umfang der Aufgabe, nicht die vorhandene Adminrolle.
- Netzwerk — ein Pfad zum benötigten Ziel und Port, nicht ein gemeinsames Netz.
- Ressourcen — geprüfte Kapazität und ein Kontingent für die zusätzliche Last.
- Mandant — getrennte Daten und getrennte Ausfälle, nicht dieselbe Umgebung.
Die Mandantengrenze hat zwei Seiten. Daten: eine Kopie von Produktionsdaten in einer schwächer geschützten Umgebung ist eine zweite Produktionsdatenhaltung — mit denselben Pflichten bei Zugriff, Aufbewahrung und Löschung. Ausfälle: jede Komponente, die zwei Mandanten oder zwei Umgebungen gemeinsam nutzen, verbindet ihre Ausfälle. Ein Wartungsfenster, ein Versionswechsel oder eine Überlast trifft dann beide zugleich. Kontingente dämpfen die Lastkopplung, sie heben den gemeinsamen Ausfall aber nicht auf.
Drift und die Richtung der Rückführung
Drift ist die Differenz zwischen dem beschriebenen und dem laufenden Zustand. Sie entsteht fast immer legitim: jemand behebt um drei Uhr nachts eine Störung direkt in der Konsole. Ein solcher Notfalleingriff ist erlaubt — er ist nur noch nicht fertig.
- Der Eingriff war richtig und eng geschnitten: in die Beschreibung übernehmen, reviewen, anwenden.
- Der Eingriff war absichtlich grob, weil unter Zeitdruck niemand die genaue Grenze kannte: die minimal ausreichende Variante bestimmen, diese beschreiben, anwenden — und den zu weiten Rest entfernen.
- Der Eingriff war falsch oder ist nicht mehr nötig: zurückbauen und den Rückbau ebenfalls verifizieren.
- Was nie trägt: die Ressource dauerhaft von der Automatisierung ausnehmen. Das macht die Abweichung dauerhaft und unsichtbar, statt sie aufzulösen.
Der Notfallzustand ist also nicht automatisch der gewünschte Zustand. Ihn ungeprüft in Code zu gießen führt eine Ausnahme über den Review-Pfad in die Dauerregel ein.
Nachweis statt Annahme
Eine Beschreibung ist keine Messung. Die Frage „läuft alles so, wie es beschrieben ist?“ lässt sich nur mit einem Vergleich beantworten — nicht mit einem Verweis auf den Prozess.
| Artefakt | Was es tatsächlich belegt |
|---|---|
| Beschreibung im Repository | Absicht und Freigabe — nicht die Wirklichkeit. |
| Grüner Lauf der Automatisierung | Dass zu diesem Zeitpunkt angewendet wurde — nicht, dass seither nichts verändert wurde. |
| Abgleich laufender Zustand gegen Beschreibung | Dass heute keine Abweichung besteht. |
| Änderungsprotokoll der Plattform-API | Wer wann außerhalb des vorgesehenen Wegs geändert hat. |
Die beiden tragenden Artefakte ergänzen sich: der Abgleich zeigt dass etwas abweicht, das Änderungsprotokoll zeigt wie es dazu kam. Wer nur eines hat, kann entweder nicht handeln oder nicht lernen.
Recovery ist ein Produktmerkmal
Verfügbarkeit und Wiederherstellung beginnen mit Anforderungen: Wie lange darf Ausfall dauern und wie viel Datenverlust ist akzeptabel? Daraus folgen Architektur, Backups, Replikation und getestete Wiederanläufe.
| RTO — Recovery Time Objective | Maximal zulässige Dauer, die eine Funktion offline sein darf. |
|---|---|
| RPO — Recovery Point Objective | Maximal zulässiger Zeitraum, aus dem Daten verloren gehen dürfen. |
Beide Werte sind Geschäftsentscheidungen, keine Messwerte des Ist-Betriebs. Erst wenn sie je Funktion feststehen, lässt sich begründet zwischen den Mustern wählen: Sicherung und Wiederherstellung, vorgehaltene Minimalumgebung, mitlaufendes Standby oder mehrere aktive Regionen. In dieser Reihenfolge sinkt die erwartete Ausfalldauer, und Kosten wie Betriebsaufwand steigen.
Nächste Checks
Gleich entscheidest du diese Achsen selbst. Achte jeweils darauf, welche Grenze wirklich gefragt ist und welcher Beleg die Aussage trägt.
- Den gewünschten Zustand statt einen manuellen Hotfix wählen
- Eine Plattformänderung von der Absicht bis zum Rückweg ordnen
- Identität, Netz, Ressourcen und Mandant als getrennte Entwurfsfragen behandeln
- Einen Notfalleingriff aus der Konsole in die richtige Richtung zurückführen
- Recovery-Ziele vor der Architekturwahl festlegen statt danach
- Den laufenden Zustand belegen statt ihn anzunehmen
- Datenkreuzung und Ausfallkopplung zwischen Umgebungen getrennt schließen
- Einen zugesagten Wiederanlauf messbar nachweisen