Infrastrukturänderungen testen ohne die Produktion zu gefährden
Ein Entwickler ändert eine kleine Firewall-Regel. „Nur ein kleiner Konfigurationstweak“, denkt er. Minuten später kann niemand mehr auf die Anwendung zugreifen. Nutzer melden Fehler. Das Team sucht hektisch nach der Ursache.
Dieses Szenario passiert häufiger, als den meisten Teams lieb ist. Infrastrukturänderungen bergen versteckte Risiken. Ein Fehler in der Datenbankkonfiguration kann Daten korrumpieren. Eine Änderung der Netzwerkrichtlinie kann ganze Dienste isolieren. Und anders als Anwendungscode betreffen Infrastrukturprobleme oft alles auf einmal.
Die Frage, die jedes Team beantworten muss: Wo testen Sie Infrastrukturänderungen, bevor sie in die Produktion gelangen?
Das Umgebungsproblem für Infrastruktur
Als Teams Server manuell verwalteten, war die Antwort meist vage. Manche hatten einen Testserver. Andere änderten die Produktion direkt, weil „es ja nur eine kleine Konfigurationsänderung ist“. Kleine Änderungen in der Infrastruktur bleiben selten klein in ihrer Auswirkung.
Anwendungen haben eine natürliche Antwort auf dieses Problem: Staging-Umgebungen. Sie testen die neue Funktion im Staging, verifizieren sie und deployen dann in die Produktion. Infrastruktur braucht denselben Ansatz, aber mit einer Besonderheit.
Man kann Infrastruktur nicht immer exakt kopieren. Das Hochziehen duplizierter Server, Netzwerke und Datenbanken kostet echtes Geld. Eine Staging-Umgebung, die eine Produktionsumgebung mit Dutzenden Servern, Load-Balancern und Datenbank-Clustern spiegelt, kann die Infrastrukturrechnung vervielfachen. Die Herausforderung ist, die Balance zwischen gründlichem Testen und Kostenkontrolle zu finden.
Das Kernprinzip: Isolieren vor dem Testen
Jede Infrastrukturänderung muss vor dem Produktionseinsatz eine isolierte Umgebung durchlaufen. Isolation bedeutet hier strikt: Die Staging-Umgebung darf keine Ressourcen mit der Produktion teilen. Keine gemeinsame Datenbank. Kein gemeinsames Netzwerk. Kein Zugriff auf echte Nutzerdaten.
Wenn Ihr Staging und Ihre Produktion noch einen Server teilen oder im selben VPC liegen, ist das keine Isolation. Ein Fehler im Staging kann in die Produktion übergreifen. Eine falsch konfigurierte Staging-Datenbank kann Produktionsdaten überschreiben. Gemeinsame Netzwerkregeln können Staging-Dienste für Produktionstraffic exponieren.
Isolation allein reicht nicht. Die Staging-Umgebung muss die Produktionskonfiguration so genau wie möglich abbilden. Wenn die Produktion drei Server hinter einem Load-Balancer betreibt, sollte Staging denselben Aufbau haben. Wenn die Produktion eine bestimmte Datenbankversion verwendet, muss Staging diese ebenfalls nutzen.
Das Ziel ist nicht, Staging so leistungsfähig wie die Produktion zu machen. Das Ziel ist, Probleme zu finden, die nur mit bestimmten Konfigurationen auftreten. Eine Datenbankabfrage, die auf einer kleinen Staging-Instanz einwandfrei funktioniert, kann in der Produktion unter Last ein Timeout verursachen. Eine Netzwerkregel, die in einer vereinfachten Umgebung funktioniert, kann in der realen Topologie legitimen Traffic blockieren.
Praktische Umgebungsebenen
Die meisten Teams landen bei mehreren Infrastruktur-Umgebungsebenen. Jede Ebene dient einem anderen Zweck und hat unterschiedliche Kompromisse zwischen Kosten und Genauigkeit.
Entwicklungsumgebung ist für Entwickler, die kleine Änderungen testen. Sie kann minimale Ressourcen und vereinfachte Konfigurationen nutzen. Ein einzelner kleiner Server statt eines Clusters. Eine lokale Datenbank statt einer replizierten Umgebung. Die Hauptanforderung ist die Isolation von Staging und Produktion. Entwicklungsumgebungen sollten niemals, auch nicht versehentlich, auf Produktionsressourcen zugreifen.
Staging-Umgebung ist für integrierte Tests. Sie sollte die Produktionskonfiguration so genau wie möglich abbilden, auch wenn der Maßstab kleiner ist. Gleiche Betriebssystemversion. Gleiche Laufzeitversionen. Gleiche Netzwerktopologie. Der Unterschied liegt meist in der Kapazität: weniger Server, kleinere Instanzen, weniger Speicher. Aber die Konfigurationsmuster müssen übereinstimmen.
Produktionsumgebung betreibt den eigentlichen Dienst. Änderungen gelangen hierher erst, nachdem sie erfolgreich Entwicklung und Staging durchlaufen haben.
Das folgende Diagramm zeigt, wie Änderungen durch jede Umgebungsebene fließen, wobei Validierungs-Gates verhindern, dass ungeprüfte Änderungen die Produktion erreichen.
Die Konfigurationsfalle
Ein Detail, das viele Teams stolpern lässt: umgebungsspezifische Konfiguration. Datenbankpasswörter, API-Keys und Serveradressen unterscheiden sich natürlich zwischen Umgebungen. Aber andere Konfigurationen sollten konsistent bleiben.
Betriebssystemversionen sollten in allen Umgebungen gleich sein. Laufzeitversionen sollten übereinstimmen. Logging-Regeln sollten identisch sein. Wenn diese zwischen Umgebungen abweichen, entsteht eine Lücke, in der Probleme verborgen bleiben können. Ein Fehler, der nur auf einer bestimmten OS-Version auftritt, taucht im Staging möglicherweise nie auf, wenn Staging eine andere Version verwendet.
Die Lösung ist die Trennung der Konfiguration nach Typ. Umgebungsspezifische Werte kommen in separate Dateien pro Umgebung. Gemeinsame Konfiguration wird einmal geschrieben und überall angewendet. Wenn Sie die Betriebssystemversion aktualisieren, ändern Sie sie an einer Stelle, nicht in drei verschiedenen Dateien.
Wie CI/CD Infrastrukturumgebungen verwaltet
Die Pipeline für Infrastrukturänderungen folgt einer klaren Reihenfolge:
- Änderung durch Code-Review oder Planungstools prüfen
- Änderung automatisch auf Staging anwenden
- Tests ausführen, um zu überprüfen, ob Ressourcen korrekt erstellt wurden
- Validieren, dass bestehende Ressourcen nicht beschädigt wurden
- Dieselbe Änderung auf die Produktion anwenden
Jeder Schritt erfolgt durch dieselben Infrastructure-as-Code-Tools. Derselbe Terraform-Plan, dasselbe Ansible-Playbook, dasselbe Pulumi-Programm läuft zuerst gegen Staging. Wenn es bestanden wird, läuft es gegen die Produktion.
Dieser Prozess stellt sicher, dass jede Infrastrukturänderung eine Umgebung durchläuft, die die Produktion spiegelt, bevor sie echte Nutzer betrifft. Die Pipeline erzwingt die Disziplin, die manuelle Prozesse oft überspringen.
Praktische Checkliste für Infrastrukturumgebungen
- Staging befindet sich in einem separaten VPC oder Account von der Produktion
- Staging hat keinen Zugriff auf Produktionsdatenbanken oder -speicher
- Staging verwendet dieselbe OS-Version und Laufzeitversionen wie die Produktion
- Gemeinsame Konfiguration wird einmal definiert und über Umgebungen hinweg geteilt
- Umgebungsspezifische Werte sind in separaten Dateien isoliert
- Die Pipeline wendet Änderungen zuerst auf Staging an, dann auf die Produktion
- Nach dem Staging-Apply laufen Tests zur Korrektheitsprüfung
Was als Nächstes kommt
Das Testen von Infrastrukturänderungen in isolierten Umgebungen fängt die meisten Probleme ab, bevor sie die Produktion erreichen. Aber es fängt nicht alles ab. Eine Änderung, die im Staging perfekt funktioniert, kann dennoch Probleme verursachen, wenn sie in der Produktion im großen Maßstab oder unter realen Traffic-Mustern angewendet wird.
Hier kommen Richtlinien und Governance ins Spiel. Der nächste Schritt ist die Definition von Regeln, welche Änderungen erlaubt sind, wer sie genehmigen darf und welche Bedingungen vor dem Produktions-Deployment erfüllt sein müssen. Aber das ist ein Thema für einen anderen Artikel.
Für jetzt ist die konkrete Erkenntnis diese: Wenn Ihre Infrastrukturänderungen direkt in die Produktion gehen, ohne eine isolierte Staging-Umgebung zu durchlaufen, sind Sie nur einen kleinen Konfigurationstweak von einem Produktionsausfall entfernt. Richten Sie zuerst die Umgebungen ein. Lassen Sie die Pipeline die Disziplin erzwingen. Ihre Nutzer werden es Ihnen danken.