

# Implementierung von Änderungen
<a name="implement-change"></a>

 Kontrollierte Änderungen sind erforderlich, um neue Funktionen bereitzustellen und sicherzustellen, dass für Workloads und Betriebsumgebung bekannte, ordnungsgemäß gepatchte Software ausgeführt wird. Wenn solche Änderungen nicht kontrolliert sind, ist es schwierig, die Auswirkungen der Änderungen vorherzusagen oder Probleme zu lösen, die sich aus ihnen ergeben. 

 **Zusätzliche Bereitstellungsmuster zur Risikominderung** 

 [Feature-Flags (auch als Feature-Toggles bezeichnet)](https://martinfowler.com/articles/feature-toggles.html) sind Konfigurationsoptionen für eine Anwendung. Sie können die Software mit einem ausgeschalteten Feature bereitstellen, sodass Kunden das Feature nicht sehen. Anschließend können Sie das Feature wie bei einer Canary-Bereitstellung aktivieren oder die Änderungsgeschwindigkeit auf 100 % setzen, um die Auswirkungen zu beobachten. Wenn die Bereitstellung Probleme bereitet, können Sie das Feature einfach wieder ausschalten, ohne ein Rollback durchführen zu müssen. 

 [Zonale Bereitstellung mit Fehlerisolation](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/): Eine der wichtigsten Regeln, die AWS für seine eigenen Bereitstellungen definiert hat, besteht darin zu vermeiden, gleichzeitig mehrere Availability Zones innerhalb einer Region zu berühren. Damit wird sichergestellt, dass Availability Zones zum Zwecke unserer Verfügbarkeitsberechnungen unabhängig sind. Wir empfehlen, bei Ihren Bereitstellungen ähnlichen Überlegungen zu folgen. 

 **Überprüfungen der betrieblichen Bereitschaft (Operational Readiness Reviews, ORRs)** 

 AWS betrachtet es als sinnvoll, die betriebliche Bereitschaft zu überprüfen, um die Vollständigkeit der Testverfahren, die Fähigkeit zur Überwachung und insbesondere die Fähigkeit zur Bewertung der Anwendungsleistung in Bezug auf die zugehörigen SLAs zu bewerten sowie Daten bereitzustellen, wenn es zu einer Unterbrechung oder sonstigen Anomalien kommt. Eine formale ORR erfolgt vor der ersten Produktionsbereitstellung. AWS wiederholt ORRs regelmäßig (einmal pro Jahr oder vor wichtigen Leistungszeiträumen), um damit sicherzustellen, dass keine Abweichungen von den betrieblichen Erwartungen vorliegen. Weitere Informationen zur betrieblichen Bereitschaft finden Sie in der [Säule „Operative Exzellenz“](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) des [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/). 

**Topics**
+ [REL08-BP01 Verwenden von Runbooks für Standardaktivitäten wie die Bereitstellung](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Integrieren von Funktionstests in die Bereitstellung](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Integrieren von Ausfallsicherheitstests in die Bereitstellung](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Bereitstellung mit einer unveränderlichen Infrastruktur](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Automatisieren von Änderungen](rel_tracking_change_management_automated_changemgmt.md)