Infrastrukturänderungen brauchen Code-Reviews – genau wie Anwendungscode

Stell dir vor: Ein Server läuft in Produktion. Jemand aus deinem Team muss einen neuen Port für ein Monitoring-Tool öffnen. Er loggt sich in die Cloud-Konsole ein, sucht die Security Group, fügt die Regel hinzu und speichert. Niemand sonst weiß davon. Drei Tage später führt das Security-Team ein Audit durch und findet einen offenen Port, der nicht da sein sollte. Niemand erinnert sich, wer ihn geöffnet hat oder warum.

Dieses Szenario passiert in Teams, die Infrastrukturänderungen anders behandeln als Änderungen am Anwendungscode. Dasselbe Team, das für einen Einzeiler-Bugfix im Code Pull-Requests, Peer-Reviews und Freigaben verlangt, lässt jemanden per SSH auf einen Server gehen und Konfigurationsdateien direkt ändern. Diese Inkonsistenz schafft Risiken, Verwirrung und unnötige Brandbekämpfung.

Warum Infrastrukturänderungen dieselbe Sorgfalt verdienen

Wenn du Infrastructure as Code betreibst, liegen Serverkonfigurationen, Netzwerkregeln, Datenbankeinstellungen und Deployment-Definitionen in Git. Diese Dateien beschreiben exakt, wie deine Infrastruktur aussehen soll. Eine Änderung an diesen Dateien kann genauso schwerwiegende Folgen haben wie eine Änderung am Anwendungscode.

Überleg mal, was passiert, wenn jemand eine Firewall-Regel ändert. Ein einziger falsch konfigurierter Port kann Kundendaten ins Internet exponieren. Eine falsche Datenbank-Instanzgröße kann Performance-Einbußen oder unerwartete Kosten verursachen. Eine falsche Load-Balancer-Einstellung kann die gesamte Anwendung offline nehmen. Das sind keine hypothetischen Risiken. Sie passieren regelmäßig in Teams, die bei Infrastrukturänderungen auf Review-Prozesse verzichten.

Das Problem ist nicht, dass Leute Fehler machen. Jeder macht Fehler. Das Problem ist, dass Fehler unbemerkt bleiben, bis etwas kaputtgeht, wenn Infrastrukturänderungen ohne Review durchgeführt werden. Und wenn etwas kaputtgeht, gibt es keine Aufzeichnung darüber, was geändert wurde, wer es geändert hat und warum.

Wie Pull-Requests für Infrastruktur funktionieren

Wenn deine Infrastruktur als Code in Git definiert ist, funktioniert der Review-Prozess genauso wie für Anwendungscode. Jemand erstellt einen Branch, nimmt Änderungen an den Infrastrukturdateien vor und öffnet einen Pull-Request. Andere Teammitglieder reviewen die Änderungen, hinterlassen Kommentare, schlagen Verbesserungen vor oder geben die Freigabe. Nach der Freigabe wird die Änderung in den Haupt-Branch gemergt und die Pipeline wendet sie an.

Dieser Prozess ist weder neu noch kompliziert. Es ist derselbe Workflow, den Entwicklungsteams seit Jahren verwenden. Der einzige Unterschied ist, was reviewed wird. Statt Anwendungslogik reviewst du Konfigurationsdefinitionen.

Was du beim Infrastruktur-Review prüfen solltest

Wenn du einen Infrastruktur-Pull-Request reviewst, achtest du auf mehrere Dinge.

Erstens: Ergibt die Änderung für die Anforderung Sinn? Wenn jemand einen Port öffnet, braucht er diesen Port wirklich? Gibt es eine sicherere Alternative? Passt die Änderung zu dem, was das Team vereinbart hat?

Zweitens: Ist die Konfiguration korrekt? Prüfe die Syntax. Vergewissere dich, dass Portnummern, Instanzgrößen und Netzwerk-CIDR-Blöcke stimmen. Achte auf zu permissive Sicherheitsregeln. Eine Regel, die Traffic von 0.0.0.0/0 auf Port 22 erlaubt, ist fast immer ein Alarmzeichen.

Drittens: Ist die Änderung konsistent mit anderen Umgebungen? Wenn deine Staging-Umgebung einen bestimmten Instanztyp oder eine bestimmte Datenbankgröße verwendet, sollte die Produktionsumgebung nicht plötzlich etwas völlig anderes nutzen – ohne dokumentierten Grund. Inkonsistenzen zwischen Umgebungen sind eine häufige Ursache für Deployment-Probleme.

Viertens: Folgt die Änderung den Namenskonventionen und Tagging-Standards deines Teams? Einheitliche Namen erleichtern das Verständnis, wofür Ressourcen da sind und wem sie gehören. Tags helfen bei der Kostenverteilung und dem Ressourcenmanagement.

Der historische Verlauf

Jeder genehmigte und gemergte Pull-Request wird zu einem dauerhaften Protokoll darüber, was geändert wurde, von wem und wann. Diese historische Spur ist unbezahlbar, wenn etwas schiefgeht.

Stell dir vor, du wachst auf und stellst fest, dass deine Produktionsanwendung nicht erreichbar ist. Du prüfst die letzten Änderungen in deinem Infrastruktur-Repository und siehst einen Pull-Request, der vor zwei Stunden die Load-Balancer-Konfiguration geändert hat. Du siehst sofort, was geändert wurde, besprichst es mit der Person, die die Änderung vorgenommen hat, und entscheidest, ob du zurücksetzen oder vorwärts reparieren willst.

Ohne diese Aufzeichnung würdest du raten. Du würdest im Team herumfragen, Chat-Logs durchgehen und Cloud-Konsolen-Aktivitätslogs durchsuchen. Der Prozess dauert länger und ist weniger zuverlässig. Die Pull-Request-Historie gibt dir eine direkte Antwort.

Das Geschwindigkeitsargument entkräften

Manche Teams sträuben sich gegen Infrastruktur-Reviews, weil sie glauben, dass es alles verlangsamt. Sie argumentieren, dass Infrastrukturänderungen schnell gehen müssen, besonders bei Incidents oder dringenden Updates.

Die Realität ist: Die Zeit, die für ein Review aufgewendet wird, ist fast immer geringer als die Zeit, die für die Behebung einer ungeprüften Änderung benötigt wird, die die Produktion lahmgelegt hat. Ein Fünf-Minuten-Review kann einen Zwei-Stunden-Ausfall verhindern. Die Rechnung ist einfach.

Bei dringenden Änderungen während Incidents kannst du den Prozess anpassen. Manche Teams verwenden ein Post-Incident-Review-Modell: Die Änderung wird zuerst angewendet, um den Dienst wiederherzustellen, und der Pull-Request wird danach erstellt und reviewed. Entscheidend ist, dass das Review trotzdem stattfindet und die Änderung dokumentiert wird. Der Prozess biegt sich für Notfälle, verschwindet aber nicht.

Was nach dem Review passiert

Sobald die Infrastrukturänderung das Review bestanden hat und gemergt wurde, ist die Arbeit noch nicht getan. Die Pipeline muss zeigen, was sich tatsächlich ändern wird, bevor sie es anwendet. Das ist der Plan-Schritt. Die Pipeline vergleicht den gewünschten Zustand aus deinem Code mit dem aktuellen Zustand deiner Infrastruktur und zeigt die Unterschiede. Erst nachdem du den Plan geprüft und bestätigt hast, dass er korrekt aussieht, fährt die Pipeline mit der Anwendung der Änderungen fort.

Dieser Plan-Schritt ist entscheidend. Selbst bei gründlichem Code-Review kann der Plan unerwartete Auswirkungen offenbaren. Eine Änderung, die im Code korrekt aussieht, könnte einen Plan erzeugen, der Ressourcen löscht und neu erstellt – was zu Ausfallzeiten führen kann. Der Plan gibt dir eine letzte Chance, Probleme zu erkennen, bevor sie in Produktion gehen.

Praktische Checkliste für Infrastruktur-Pull-Requests

• Entspricht die Änderung der tatsächlichen Anforderung oder Anfrage?
• Sind alle Werte korrekt (Ports, Instanzgrößen, CIDR-Bereiche)?
• Sind Sicherheitsregeln so restriktiv wie möglich, während sie dennoch notwendigen Traffic erlauben?
• Ist die Änderung konsistent mit anderen Umgebungen?
• Folgt sie den Namens- und Tagging-Konventionen?
• Gibt es eine Plan-Ausgabe, die zeigt, was sich vor der Anwendung ändern wird?

Das Fazit

Infrastrukturänderungen verdienen denselben Review-Prozess wie Änderungen am Anwendungscode. Die Folgen einer schlechten Infrastrukturänderung sind oft schwerwiegender und schwieriger zu diagnostizieren als die eines schlechten Code-Änderung. Pull-Requests bieten eine strukturierte Möglichkeit, Fehler zu erkennen, Standards durchzusetzen und einen historischen Verlauf zu bewahren. Die Zeit, die du in das Review von Infrastrukturänderungen investierst, ist Zeit, die du nicht mit dem Debuggen von Produktionsausfällen verbringen wirst, die durch ungeprüfte Konfigurationsänderungen verursacht wurden. Behandle deinen Infrastrukturcode mit derselben Sorgfalt wie deinen Anwendungscode – und deine Produktionsumgebung wird es dir danken.