Читать книгу Handbuch Infrastructure as Code - Kief Morris - Страница 25

Wir möchten gerne glauben, dass wir ein System bauen, und dann ist es »fertig«. Bei einer solchen Sichtweise nehmen wir nicht viele Änderungen vor, daher ist das Automatisieren von Änderungen nur Zeitverschwendung.

In der Realität gibt es nur an sehr wenigen Systemen keine Veränderungen mehr – zumindest nicht, bevor sie ausgemustert werden. Manche gehen davon aus, dass die aktuelle Menge an Änderungen nur vorübergehend ist. Andere schaffen aufwendige Prozesse zum Änderungsmanagement, um Personen davon abzuhalten, nach Änderungen zu fragen. Aber diejenigen reden es sich schön. Die meisten Teams, die aktiv genutzte Systeme betreuen, haben es mit einem kontinuierlichen Strom von Änderungen zu tun.

Denken Sie nur an die folgenden Beispiele für Änderungen an der Infrastruktur:

 Ein wichtiges neues Anwendungsfeature erfordert das Hinzufügen einer neuen Datenbank.

 Für ein neues Anwendungsfeature muss der Anwendungsserver aktualisiert werden.

 Die App wird häufiger genutzt als erwartet. Sie brauchen mehr Server, neue Cluster und zusätzliche Networking- und Storage-Kapazitäten.

 Beim Performance-Profiling zeigt sich, dass die aktuelle Deployment-Architektur für die Anwendung die Performance einschränkt. Sie müssen die Anwendungen auf mehrere andere Anwendungsserver neu deployen. Dazu sind Änderungen am Clustering und an der Netzwerk-Architektur erforderlich.

 Es gibt eine neu bekannt gewordene Sicherheitslücke in Systempaketen für Ihr Betriebssystem. Sie müssen dutzende Produktivserver patchen.

 Sie müssen Server aktualisieren, auf denen veraltete Versionen des Betriebssystems und zentraler Pakete laufen.

 Auf Ihren Webservern gibt es immer wieder Aussetzer. Sie müssen eine Reihe von Konfigurationsänderungen vornehmen, um das Problem untersuchen zu können. Dann müssen Sie ein Modul aktualisieren, um das Problem zu lösen.

 Sie finden eine Konfigurationsänderung, die die Performance Ihrer Datenbank verbessert.

Eine zentrale Wahrheit des Cloud-Zeitalters ist: Stabilität entsteht durch Änderungen.

Ungepatchte Systeme sind nicht stabil – sie sind angreifbar. Können Sie Probleme nicht beheben, sobald Sie sie finden, ist Ihr System nicht stabil. Können Sie nach einem Ausfall nicht schnell wieder auf die Füße kommen, ist Ihr System nicht stabil. Wenn für Ihre Änderungen eine deutliche Downtime erforderlich ist, ist Ihr System nicht stabil. Wenn Änderungen immer wieder fehlschlagen, ist Ihr System nicht stabil.