Server anhand von Images zu ersetzen statt sie vor Ort zu patchen, verringert Befunde zu Konfigurationsdrift

Hypothese

Unveränderliche (immutable) Infrastruktur bedeutet, dass eine laufende Instanz nach dem Start nie verändert wird; eine Änderung ist ein neues Image, gebaut mit einem Werkzeug wie Packer (zitiert: identische Maschinen-Images aus einer einzigen Quellkonfiguration) oder ein Container-Build, gefolgt vom Ersetzen der Instanz. Die Terraform-apply-Dokumentation (zitiert) rät bei automatisierten Applies mit -auto-approve dazu, sicherzustellen, dass niemand die Infrastruktur ausserhalb des Terraform-Workflows verändern kann, weil das unvorhersehbare Änderungen und Konfigurationsdrift minimiert. Die Hypothese lautet, dass die Nur-Ersetzen-Disziplin Drift nicht nur bei den vom Infrastruktur-Code verwalteten Ressourcen verringert, sondern auch innerhalb der Instanzen, weil die Operationen, die Drift verursachen (Hotfixes über SSH, teilweise Konfigurationsläufe, Paket-Upgrades, die nur auf manchen Hosts gelingen), keinen Ort mehr haben, an dem sie landen könnten.

Vorhersage

Über vergleichbare Dienste hinweg wird ein geplanter terraform plan -refresh-only (oder das Äquivalent für ein anderes Werkzeug) bei ausschliesslich nach dem Ersetzungsprinzip betriebenen Flotten bei weniger Läufen und mit weniger betroffenen Ressourcen Drift melden als bei vor Ort gepatchten Flotten. Innerhalb einer vor Ort gepatchten Flotte wird die Anzahl der abgedrifteten Attribute mit dem Alter der Instanzen korrelieren; innerhalb einer ausschliesslich nach dem Ersetzungsprinzip betriebenen Flotte wird das nicht der Fall sein, weil keine Instanz alt ist. Vorfälle, deren Postmortem «dieser Host war anders» festhält, werden in ausschliesslich nach dem Ersetzungsprinzip betriebenen Flotten seltener sein.

Vorgeschlagener Test

1. Dienste innerhalb derselben Organisation auswählen, die sich im Betriebsstil unterscheiden (ausschliesslich Ersetzen versus vor Ort), aber dasselbe Infrastruktur-Code-Werkzeug und dieselbe Cloud verwenden.
2. Täglich, für mindestens ein Quartal je Dienst, einen refresh-only-Plan ausführen und festhalten: Läufe mit irgendeiner Drift, abgedriftete Ressourcen, abgedriftete Attribute sowie das Alter jeder beteiligten Instanz.
3. Bei Instanzen ein periodisches Audit innerhalb der Instanz hinzufügen (Paketliste, Hashes der Konfigurationsdateien), verglichen mit dem Manifest des Images; abweichende Dateien je Instanz und Instanzalter zählen.
4. Verteilungen zwischen den Stilen vergleichen; Zahlen je Dienst berichten, nicht nur Gesamtsummen, da ein einzelner unruhiger Dienst dominieren kann.
5. Störgrössen festhalten: Teamgrösse, Bereitschaftspraxis, Änderungsvolumen, sowie ob die vor Ort gepatchten Flotten Konfigurationsmanagement nach Zeitplan oder nur bei Bedarf ausführen.

Status

Es wird kein Ergebnis behauptet. Der ausschliessliche Ersetzungsbetrieb hat Kosten, die die Hypothese nicht abwägt: längere Vorlaufzeit für kleine Korrekturen, zu wartende Image-Build-Pipelines, und Zustand, der ausserhalb der Instanz existieren muss. Von der Cloud-API gefundene Drift und Drift innerhalb des Betriebssystems sind unterschiedliche Messungen und sollten getrennt berichtet werden.