Infrastructure as Code im Serverbetrieb: Wann sich Automatisierung lohnt und wie der Einstieg gelingt

Server, die von Hand eingerichtet wurden, unterscheiden sich nach einigen Monaten immer. Ein Paket wurde für einen Test nachinstalliert, eine Konfigurationsdatei im Störfall angepasst, ein Limit erhöht und nie zurückgesetzt. Solange alles läuft, fällt das nicht auf. Auffällig wird es erst, wenn ein Dienst auf einem von drei vermeintlich identischen Systemen anders reagiert oder wenn ein Server nach einem Ausfall neu aufgebaut werden muss und niemand den exakten Zustand kennt.

Infrastructure as Code und Konfigurationsmanagement sind die Antwort auf dieses Problem. Sie sind aber kein Selbstzweck. Dieser Beitrag ordnet ein, welches Problem die Werkzeuge tatsächlich lösen, ab wann sich der Aufwand rechnet und wie ein Einstieg aussieht, der den laufenden Betrieb nicht blockiert.

Das eigentliche Problem heißt Konfigurationsdrift

Konfigurationsdrift bezeichnet das Auseinanderlaufen des tatsächlichen Systemzustands und dessen, was dokumentiert oder angenommen wird. Drift entsteht nicht durch Nachlässigkeit, sondern durch normalen Betrieb: manuelle Eingriffe unter Zeitdruck, Änderungen durch mehrere Personen, Pakete, die Standardkonfigurationen bei Updates überschreiben.

Die Folgen sind bekannt. Fehler lassen sich in der Testumgebung nicht reproduzieren, weil die Testumgebung nie wirklich gleich war. Ein Wiederaufbau nach Hardwareausfall dauert Tage statt Stunden. Neue Kolleginnen und Kollegen trauen sich an bestimmte Systeme nicht heran, weil niemand mehr weiß, warum eine bestimmte Einstellung so gesetzt wurde.

Der Kern von Infrastructure as Code ist nicht Geschwindigkeit, sondern Reproduzierbarkeit: Der Sollzustand eines Systems liegt in einer versionierten Datei und nicht im Gedächtnis einzelner Personen.

Drei Automatisierungsstufen unterscheiden

Der Begriff wird oft pauschal verwendet, obwohl sich dahinter unterschiedliche Ebenen verbergen. Die Trennung hilft bei der Entscheidung, womit man beginnt.

Provisionierung der Infrastruktur

Hier geht es um das Anlegen von Servern, Netzen, Firewallregeln, Speicher und DNS-Einträgen. Deklarative Werkzeuge beschreiben den gewünschten Zustand und gleichen ihn gegen die tatsächliche Umgebung ab. Diese Ebene lohnt sich besonders, wenn Umgebungen häufig neu entstehen oder wenn mehrere Umgebungen wie Produktion, Staging und Test strukturgleich bleiben sollen.

Konfiguration der Systeme

Diese Ebene beschreibt, was auf einem bestehenden Server passiert: Pakete, Dienste, Benutzer, Dateien, Zertifikate, Systemparameter. Konfigurationsmanagement arbeitet idealerweise idempotent, das heißt, ein wiederholter Lauf führt zum selben Ergebnis und ändert nichts, was bereits korrekt ist. Für klassische Serverlandschaften mit langlebigen Systemen ist das meist die Ebene mit dem größten Nutzen.

Auslieferung der Anwendung

Deployments gehören streng genommen nicht zum Konfigurationsmanagement, werden aber häufig mit denselben Werkzeugen erschlagen. Diese Vermischung ist ein häufiger Grund dafür, dass Automatisierung unübersichtlich wird. Anwendungsstand und Systemzustand ändern sich in unterschiedlichen Rhythmen und sollten getrennt bleiben.

Wann sich der Aufwand rechnet

Automatisierung kostet zuerst Zeit und zahlt später zurück. Ob sich diese Rechnung aufgeht, hängt weniger von der Servermenge ab, als oft angenommen. Entscheidend sind vier Fragen.

• Wiederholung: Wird dieselbe Konfiguration auf mehreren Systemen oder in mehreren Umgebungen gebraucht? Ab etwa drei gleichartigen Systemen wird manuelles Vorgehen unzuverlässig.
• Änderungsrate: Wie oft wird ein System angefasst? Ein Server, der zweimal im Jahr ein Update bekommt, braucht kein Konfigurationsmanagement. Ein System mit wöchentlichen Anpassungen profitiert sofort.
• Anzahl der Beteiligten: Sobald mehr als eine Person Änderungen vornimmt, ersetzt ein versioniertes Repository die informelle Absprache.
• Wiederherstellungsanspruch: Wenn ein System innerhalb weniger Stunden neu aufgebaut werden muss, ist eine dokumentierte Installationsanleitung zu langsam und zu fehleranfällig.

Umgekehrt gibt es Fälle, in denen Automatisierung wenig bringt. Einzelne Spezialsysteme mit viel manueller Fachkonfiguration, Altanwendungen ohne saubere Installationsroutine oder Umgebungen kurz vor der Ablösung sind schlechte Kandidaten. Hier ist eine ehrliche Betriebsdokumentation der bessere Weg.

Einstieg ohne Big Bang

Der häufigste Fehler ist der Versuch, eine gewachsene Umgebung in einem Zug vollständig abzubilden. Das Projekt wird groß, zieht sich und wird nebenbei vom Tagesgeschäft überholt. Ein schrittweises Vorgehen ist belastbarer.

Mit neuen Systemen beginnen

Jeder neu aufgesetzte Server wird ab sofort nur noch über Code konfiguriert. Bestehende Systeme bleiben zunächst unangetastet. So entsteht Routine, ohne dass Produktionsrisiko entsteht.

Die Basis zuerst abdecken

Sinnvoll ist eine Grundrolle, die für alle Systeme gilt: Benutzerkonten und SSH-Schlüssel, Zeitsynchronisation, Logweiterleitung, Monitoring-Agent, Firewall-Grundregeln, Paketquellen und automatische Sicherheitsupdates. Diese Basis ändert sich selten, gilt aber überall und bringt den schnellsten Nutzen. Anwendungsspezifische Rollen kommen danach.

Umgang mit Geheimnissen klären

Passwörter, API-Schlüssel und private Zertifikatsschlüssel gehören nicht im Klartext ins Repository. Diese Entscheidung sollte vor dem ersten produktiven Einsatz fallen, nicht danach. Ob verschlüsselte Variablen, ein dedizierter Secret-Store oder eine getrennte Ablage gewählt wird, ist zweitrangig. Wichtig ist, dass es genau einen definierten Weg gibt.

Änderungen testen, bevor sie wirken

Nahezu alle Werkzeuge bieten einen Probelauf, der Änderungen nur anzeigt, statt sie anzuwenden. Dieser Modus gehört in jeden Arbeitsablauf. Zusätzlich hilft eine Testumgebung, in der Änderungen zuerst laufen. Wer ohne beides arbeitet, hat die manuelle Fehlerquelle lediglich durch eine automatisierte ersetzt, die schneller und flächendeckender wirkt.

Typische Fehler im laufenden Betrieb

Automatisierung bringt eigene Risiken mit, die sich benennen lassen.

Teilautomatisierung ohne Regel. Wenn manche Einstellungen über Code und andere von Hand gepflegt werden, ohne dass klar ist welche, überschreibt der nächste Lauf stillschweigend eine manuelle Korrektur. Für jedes System sollte festgelegt sein, welche Bereiche verwaltet werden.

Code ohne Review. Infrastructure as Code ist Code und gehört in denselben Prozess wie Anwendungscode: Versionierung, nachvollziehbare Änderungen, Vier-Augen-Prinzip bei kritischen Rollen.

Fehlende Abweichungserkennung. Ein Konfigurationslauf, der nur bei Bedarf gestartet wird, erkennt Drift nicht. Regelmäßige Läufe oder zumindest regelmäßige Probeläufe machen sichtbar, wo Systeme vom Sollzustand abweichen.

Automatisierung ersetzt kein Verständnis. Wer eine fremde Rolle einbindet, ohne zu wissen, was sie setzt, hat Komplexität importiert statt reduziert. Gerade sicherheitsrelevante Einstellungen sollten im eigenen Repository nachvollziehbar sein.

Was bleibt, wenn die Automatisierung steht

Ein gut gepflegtes Repository beantwortet drei Fragen ohne Rückfrage an Einzelpersonen: Wie ist dieses System konfiguriert, warum ist es so konfiguriert, und wie baue ich es wieder auf. Das ist der eigentliche Gewinn, besonders bei Personalwechsel, Audits und Störfällen.

Die Entscheidung für oder gegen Infrastructure as Code sollte deshalb nicht an der Anzahl der Server festgemacht werden, sondern an der Frage, wie teuer der Verlust von Wissen und Reproduzierbarkeit im konkreten Fall wäre. Wo diese Kosten hoch sind, rechnet sich der Einstieg schnell. Wo sie niedrig sind, ist eine saubere, aktuell gehaltene Dokumentation die ehrlichere Lösung.