# Zuverlässigkeit
Die Säule „Zuverlässigkeit“ umfasst die Fähigkeit einer Workload, die beabsichtigte Funktion erwartungsgemäß korrekt und konsistent auszuführen. Dies umfasst die Möglichkeit, die Workload während des gesamten Lebenszyklus zu betreiben und zu testen. Dieses Dokument bietet umfassende Informationen mit bewährten Methoden für die Implementierung zuverlässiger Workloads in AWS.
**Topics**
+ [
# Modell der geteilten Verantwortung für Ausfallsicherheit
](shared-responsibility-model-for-resiliency.md)
+ [
# Designprinzipien
](design-principles.md)
+ [
# Definitionen
](definitions.md)
+ [
# Verstehen des Verfügbarkeitsbedarfs
](understanding-availability-needs.md)
# Modell der geteilten Verantwortung für Ausfallsicherheit
Die Ausfallsicherheit ist eine geteilte Verantwortung zwischen AWS und Ihnen. Sie sollten unbedingt wissen, wie die Notfallwiederherstellung (DR) und Verfügbarkeit als Teil der Ausfallsicherheit im Rahmen dieses gemeinsamen Modells funktionieren.
**AWS-Verantwortung – Ausfallsicherheit der Cloud**
AWS ist für die Ausfallsicherheit der Infrastruktur verantwortlich, über die alle in AWS Cloud angebotenen Services ausgeführt werden. Diese Infrastruktur umfasst die Hardware, Software, Netzwerke und Einrichtungen, die die AWS Cloud-Services ausführen. AWS unternimmt wirtschaftlich vertretbare Anstrengungen, um diese AWS Cloud-Services verfügbar zu halten und sicherzustellen, dass die Verfügbarkeit der Services die [Service Level Agreements (SLAs) von AWS](https://aws.amazon.com/legal/service-level-agreements/) erfüllt oder übertrifft.
Die [globale Cloud-Infrastruktur von AWS](https://aws.amazon.com/about-aws/global-infrastructure/) ist so konzipiert, dass Kunden hochgradig widerstandsfähige Workload-Architekturen erstellen können. Jede AWS-Region-Region ist vollständig isoliert und besteht aus mehreren [Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones), bei denen es sich um physisch isolierte Partitionen der Infrastruktur handelt. Availability Zones isolieren Fehler, die die Ausfallsicherheit von Workloads beeinträchtigen könnten, und verhindern, dass sie sich auf andere Zonen in der Region auswirken. Gleichzeitig sind alle Zonen in einer AWS-Region mit einem Netzwerk mit hoher Bandbreite und geringer Latenz verbunden, und zwar über vollständig redundante, dedizierte Metro-Glasfaserverbindungen, die einen hohen Durchsatz und eine geringe Latenz zwischen den Zonen ermöglichen. Der gesamte Datenverkehr zwischen den Zonen ist verschlüsselt. Die Leistung des Netzwerks ist ausreichend, um eine synchrone Replikation zwischen den Zonen zu ermöglichen. Wenn eine Anwendung auf mehrere AZs aufgeteilt wird, sind Unternehmen besser isoliert und vor Problemen wie Stromausfällen, Blitzeinschlägen, Tornados, Wirbelstürmen und mehr geschützt.
**Kundenverantwortung – Ausfallsicherheit in der Cloud**
Ihre Verantwortung wird von den AWS Cloud-Services bestimmt, die Sie auswählen. Dies bestimmt den Umfang der Konfigurationsarbeit, die Sie als Teil Ihrer Verantwortung für die Ausfallsicherheit durchführen müssen. Bei einem Service wie Amazon Elastic Compute Cloud (Amazon EC2) muss der Kunde zum Beispiel alle notwendigen Aufgaben zur Konfiguration und Verwaltung der Ausfallsicherheit übernehmen. Kunden, die Amazon-EC2-Instances bereitstellen, sind für die [Bereitstellung von Amazon-EC2-Instances an mehreren Standorten](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) (wie AWS Availability Zones), die [Implementierung der Selbstreparatur](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) mit Services wie Auto Scaling sowie die Verwendung von [bewährten Methoden für eine ausfallsichere Workload-Architektur](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) für Anwendungen, die auf den Instances installiert sind, verantwortlich. Für verwaltete Services wie Amazon S3 und Amazon DynamoDB betreibt AWS die Infrastrukturebene, das Betriebssystem und die Plattformen. Kunden greifen auf die Endpunkte zu, um Daten zu speichern und abzurufen. Sie sind dafür verantwortlich, die Ausfallsicherheit Ihrer Daten zu verwalten, einschließlich Sicherungs-, Versionsverwaltungs- und Replikationsstrategien.
Das Bereitstellen Ihrer Workload in mehreren Availability Zones in einer AWS-Region ist Teil einer Hochverfügbarkeitsstrategie, die darauf abzielt, Workloads zu schützen, indem Probleme auf eine Availability Zone beschränkt werden. Die Redundanz der anderen Availability Zones wird genutzt, um Anfragen weiterhin zu bedienen. Eine Multi-AZ-Architektur ist außerdem Teil einer Notfallwiederherstellungsstrategie, die darauf abzielt, Workloads besser zu isolieren und vor Problemen wie Stromausfällen, Blitzeinschlägen, Tornados, Erdbeben und anderen Ereignissen zu schützen. Notfallwiederherstellungsstrategien können auch auf mehrere AWS-Regionen zurückgreifen. In einer Aktiv/Passiv-Konfiguration wird der Service für die Workload beispielsweise von der aktiven Region auf die Notfallwiederherstellungsregion übertragen, wenn die aktive Region die Anfragen nicht mehr bedienen kann.
![\[Diagramm zur Veranschaulichung des geteilten Modells zur Ausfallsicherheit\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png)
Sie können AWS-Services nutzen, um Ihre Ausfallsicherheitsziele zu erreichen. Als Kunde sind Sie für die Verwaltung der folgenden Aspekte Ihres Systems verantwortlich, um die Ausfallsicherheit in der Cloud zu erreichen. Weitere Informationen zu den einzelnen Services finden Sie in der [AWS-Dokumentation](https://docs.aws.amazon.com/index.html).
**Netzwerke, Kontingente und Beschränkungen**
+ Bewährte Methoden für diesen Bereich des Modells der geteilten Verantwortung werden unter [Grundlagen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html) detailliert beschrieben.
+ Planen Sie Ihre Architektur mit ausreichendem Spielraum zum Skalieren. Informieren Sie sich über die [Service Quotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html) und die Beschränkungen der genutzten Services unter Berücksichtigung der erwarteten Zunahme der Last, falls zutreffend.
+ Entwerfen Sie Ihre [Netzwerktopologie](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) so, dass sie hochverfügbar, redundant und skalierbar ist.
**Änderungsmanagement und operative Ausfallsicherheit**
+ Das [Änderungsmanagement](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html) umfasst die Einführung und Verwaltung von Änderungen in Ihrer Umgebung. Die [Implementierung von Änderungen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html) erfordert die Erstellung und Aktualisierung von Runbooks und Bereitstellungsstrategien für Ihre Anwendung und Infrastruktur.
+ Eine belastbare Strategie zur [Überwachung von Workload-Ressourcen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html) berücksichtigt alle Komponenten, einschließlich technischer und geschäftlicher Metriken, Benachrichtigungen, Automatisierung und Analysen.
+ Workloads in der Cloud müssen sich [an Veränderungen der Nachfrage anpassen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html) und als Reaktion auf Beeinträchtigungen oder Schwankungen in der Nutzung skalieren.
**Beobachtbarkeit und Ausfallmanagement**
+ Die Beobachtung von Ausfällen durch Überwachung ist erforderlich, um die Selbstreparatur zu automatisieren, damit Ihre Workloads [Komponentenausfälle überstehen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) können.
+ [Ausfallmanagement](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html) erfordert [Datensicherung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html), die Anwendung bewährter Methoden, um Ihre Workload gegen Komponentenausfälle abzusichern, und die [Planung einer Notfallwiederherstellung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html).
**Workload-Architektur**
+ Ihre [Workload-Architektur](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) umfasst die Art und Weise, wie Sie Services rund um geschäftliche Bereiche entwerfen, SOA und das Design verteilter Systeme anwenden, um Fehler zu vermeiden, und Funktionen wie Drosselung, Wiederholungen, Warteschlangenmanagement, Zeitüberschreitungen und Notfallfunktionen integrieren.
+ Verlassen Sie sich auf bewährte [AWS-Lösungen](https://aws.amazon.com/solutions/), die [Amazon Builders' Library](https://aws.amazon.com/builders-library/) und [Serverless-Muster](https://serverlessland.com/patterns), um sich an bewährten Methoden zu orientieren und Implementierungen anzugehen.
+ Nutzen Sie kontinuierliche Verbesserungen, um Ihr System in verteilte Services aufzuteilen und so schneller zu skalieren und Innovationen voranzutreiben. Nutzen Sie Leitfäden für [AWS-Microservices](https://aws.amazon.com/microservices/) und verwaltete Serviceoptionen, um Ihre Möglichkeiten zur Umsetzung von Veränderungen und Innovationen zu vereinfachen und zu beschleunigen.
**Kontinuierliches Testen kritischer Infrastrukturen**
+ Das [Testen der Zuverlässigkeit](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html) bedeutet auf der Funktions-, Leistungs- und Chaos-Ebene zu testen sowie die Anwendung von Vorfallsanalysen und Gameday-Verfahren, um Fachwissen zur Lösung von Problemen aufzubauen, die nicht genau verstanden werden.
+ Sowohl bei Anwendungen, die vollständig in der Cloud laufen, als auch bei hybriden Anwendungen können Sie sich schnell und zuverlässig von Ausfällen erholen, wenn Sie wissen, wie sich Ihre Anwendung bei Problemen oder Komponentenausfällen verhält.
+ Erstellen und dokumentieren Sie wiederholbare Experimente, um zu verstehen, wie sich Ihr System verhält, wenn Dinge nicht wie erwartet funktionieren. Diese Tests belegen die Effektivität Ihrer allgemeinen Ausfallsicherheit und bieten eine Feedback-Schleife für Ihre operativen Verfahren, bevor Sie mit realen Fehlerszenarien konfrontiert werden.
# Designprinzipien
In der Cloud gibt es zahlreiche Grundsätze, die Sie dabei unterstützen können, die Zuverlässigkeit zu erhöhen. Diese sollten Sie bei der Beschreibung der bewährten Methoden beachten:
+ **Automatische Wiederherstellung** nach einem Fehler: Durch die Überwachung wichtiger Leistungskennzahlen (KPIs) einer Workload können Sie die Automatisierung auslösen, sobald ein Schwellenwert überschritten wurde. Diese KPIs sollten als Kennzahlen für den Geschäftswert und nicht als technische Aspekte für den Betrieb des Service betrachtet werden. Dies ermöglicht eine automatische Benachrichtigung bei und Verfolgung von Fehlern sowie die Einleitung einer automatisierten Wiederherstellung, die eine Fehlerumgehung bietet oder den Fehler behebt. Bei einer ausgefeilteren Automatisierung ist es möglich, Fehler vor ihrem eigentlichen Auftreten zu antizipieren und zu beheben.
+ **Testen von Wiederherstellungsverfahren:** In einer On-Premises-Umgebung werden häufig Tests durchgeführt, um nachzuweisen, dass die Workload in einem bestimmten Szenario funktioniert. Mit den Tests werden in der Regel keine Wiederherstellungsstrategien validiert. In der Cloud können Sie testen, in welchen Situationen die Workload Fehler produziert, und Sie können die Wiederherstellungsverfahren validieren. Mit der Automatisierung können Sie verschiedene Fehler simulieren oder Szenarien reproduzieren, die zuvor zu Fehlern geführt haben. Dieser Ansatz stellt Fehlerpfade bereit, die Sie testen und beheben können, *bevor* ein echtes Fehlerszenario auftritt, und reduziert so das Risiko.
+ **Horizontale Skalierung zur Erhöhung der aggregierten Workload-Verfügbarkeit:** Ersetzen Sie eine große Ressource durch mehrere kleine Ressourcen, um die Auswirkung eines einzigen Fehlers auf das Gesamtsystem zu reduzieren. Verteilen Sie Anfragen auf mehrere kleinere Ressourcen, damit sie keine gemeinsame Fehlerquelle haben.
+ **Genaue Analyse der verfügbaren Kapazität:** Eine häufige Fehlerursache bei On-Premises-Workloads ist die Ressourcensättigung. Ein solches Szenario liegt vor, wenn die Anforderungen an die Workload die Kapazität dieser Workload überschreiten (dies ist häufig das Ziel von Denial-of-Service-Angriffen). In der Cloud können Sie die Nachfrage und die Workload-Auslastung überwachen und das Hinzufügen oder Entfernen von Ressourcen automatisieren, um den Bedarf ohne Über- oder Unterbereitstellung stets optimal zu erfüllen. Es gibt weiterhin Grenzen, aber einige Kontingente können gesteuert und andere verwaltet werden (siehe [Verwaltung von Service Quotas und Einschränkungen](manage-service-quotas-and-constraints.md)).
+ **Änderungsmanagement per Automatisierung:** Änderungen an Ihrer Infrastruktur sollten über eine Automatisierung vorgenommen werden. Zu den Änderungen, die verwaltet werden müssen, gehören Änderungen an der Automatisierung, die anschließend nachverfolgt und überprüft werden können.
# Definitionen
Dieses Whitepaper behandelt die Zuverlässigkeit in der Cloud und beschreibt bewährte Methoden für die folgenden vier Bereiche:
+ Grundlagen
+ Workload-Architektur
+ Änderungsmanagement
+ Fehlerverwaltung
Um Zuverlässigkeit zu erreichen, müssen Sie mit den Grundlagen beginnen – einer Umgebung, in der Service Quotas und Netzwerktopologie der Workload entsprechen. Die Workload-Architektur des verteilten Systems muss so ausgelegt sein, dass Ausfälle verhindert und minimiert werden. Die Workload muss Änderungen in Bezug auf den Bedarf oder die Anforderungen verarbeiten und so konzipiert sein, dass sie Fehler erkennt und sie automatisch selbst behebt.
**Topics**
+ [
# Ausfallsicherheit und die Komponenten der Zuverlässigkeit
](resiliency-and-the-components-of-reliability.md)
+ [
# Verfügbarkeit
](availability.md)
+ [
# Notfallwiederherstellungsziele
](disaster-recovery-dr-objectives.md)
# Ausfallsicherheit und die Komponenten der Zuverlässigkeit
Die Zuverlässigkeit einer Workload in der Cloud hängt von mehreren Faktoren ab. Die *Ausfallsicherheit* ist hierbei der wichtigste Faktor:
+ Unter **Ausfallsicherheit** versteht man die Fähigkeit einer Workload, sich von Infrastruktur- oder Serviceunterbrechungen zu erholen, Datenverarbeitungsressourcen dynamisch zur Erfüllung des Bedarfs anzufordern und Unterbrechungen zu minimieren, die beispielsweise aus Fehlkonfigurationen oder vorübergehenden Netzwerkproblemen entstehen.
Weitere Faktoren, die sich auf die Zuverlässigkeit von Workloads auswirken:
+ Operative Exzellenz, einschließlich Automatisierung von Änderungen, Verwendung von Playbooks zur Reaktion auf Ausfälle und Überprüfungen der betrieblichen Bereitschaft (Operational Readiness Reviews, ORRs), um zu bestätigen, dass Anwendungen für den Produktionsbetrieb bereit sind.
+ Sicherheit, einschließlich der Verhinderung von Daten- oder Infrastrukturschäden durch böswillige Akteure, die sich auf die Verfügbarkeit auswirken würden. Verschlüsseln Sie beispielsweise Sicherungen, um zu gewährleisten, dass die Daten geschützt sind.
+ Leistungseffizienz, einschließlich der Konzeption für maximale Anfrageraten und der Latenzminimierung für Ihre Workload.
+ Kostenoptimierung, die Kompromisse einschließt, z. B. ob Sie mehr für EC2-Instances ausgeben möchten, um statische Stabilität zu erzielen, oder ob Sie sich auf die automatische Skalierung verlassen möchten, wenn mehr Kapazität benötigt wird.
In diesem Whitepaper geht es vor allem um die Ausfallsicherheit.
Die anderen vier Aspekte sind ebenfalls wichtig und werden von den jeweiligen Säulen des [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) abgedeckt. Viele der bewährten Methoden hier kommen auch diesen Aspekten der Zuverlässigkeit zugute, der Fokus liegt aber auf der Ausfallsicherheit.
# Verfügbarkeit
*Verfügbarkeit* (bzw. *Serviceverfügbarkeit*) ist sowohl eine häufig verwendete Metrik zur quantitativen Messung der Ausfallsicherheit als auch ein Ziel für die Ausfallsicherheit.
+ **Verfügbarkeit** ist der Prozentsatz der Zeit, für den eine Workload zur Verfügung steht.
*Verfügbar zur Verwendung* bedeutet, dass die vereinbarte Funktion bei Bedarf erfolgreich ausgeführt wird.
Dieser Prozentsatz wird über einen definierten Zeitraum berechnet, z. B. über einen Monat, ein Jahr oder über drei aufeinander folgende Jahre. Wenn man der strengsten Interpretation folgt, reduziert sich die Verfügbarkeit immer dann, wenn die Anwendung nicht normal ausgeführt wird, einschließlich geplanter und ungeplanter Unterbrechungen. Wir definieren *Verfügbarkeit* wie folgt:
![\[\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ Die Verfügbarkeit ist ein Prozentsatz der Betriebszeit (z. B. 99,9 %) über einen bestimmten Zeitraum (in der Regel ein Monat oder ein Jahr).
+ Die übliche Kurzform bezieht sich nur auf die Anzahl der Neunen, so stehen „fünf Neunen“ für eine Verfügbarkeit von 99,999 %.
+ Einige Kunden entscheiden sich dafür, geplante Serviceausfallzeiten (z. B. geplante Wartungsarbeiten) von der *Gesamtzeit* in der Formel auszuschließen. Das wird jedoch nicht empfohlen, da Ihre Benutzer Ihren Service wahrscheinlich während dieser Zeit nutzen wollen werden.
Im Folgenden finden Sie eine Tabelle mit bekannten Designzielen für die Anwendungsverfügbarkeit und der möglichen Dauer von Unterbrechungen, die innerhalb eines Jahres auftreten können, ohne sich auf das Erreichen des Ziels auszuwirken. Die Tabelle enthält Beispiele für die Anwendungstypen, die auf den jeweiligen Verfügbarkeitsstufen häufig vorkommen. In diesem Dokument beziehen wir uns immer wieder auf diese Werte.
| Verfügbarkeit | Maximale Unterbrechung der Verfügbarkeit (pro Jahr) | Anwendungskategorien |
| --- | --- | --- |
| 99 % | 3 Tage und 15 Stunden | Stapelverarbeitung, Datenextrahierung, Übertragung und Laden von Aufgaben |
| 99,9 % | 8 Stunden und 45 Minuten | Interne Tools wie Wissensmanagement, Projektverfolgung |
| 99,95 % | 4 Stunden und 22 Minuten | Online-Handel, Verkaufsort |
| 99,99 % | 52 Minuten | Workloads zur Videobereitstellung und für Broadcasts |
| 99,999 % | 5 Minuten | Geldautomaten-Transaktionen, Telekommunikations-Workloads |
**Messung der Verfügbarkeit anhand von Anfragen.** Es kann für Ihren Service einfacher sein, anstelle der „zur Nutzung verfügbaren Zeit“ die erfolgreichen und fehlgeschlagenen Anfragen zu messen. In diesem Fall kann die folgende Berechnung verwendet werden:
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
Dies wird oft für Zeiträume von einer oder fünf Minuten gemessen. Mit dem Durchschnitt dieser Zeiträume kann dann ein monatlicher Prozentwert für die Verfügbarkeit (zeitbasierte Verfügbarkeitsmessung) berechnet werden. Wenn in einem bestimmten Zeitraum keine Anfragen eingehen, wird für diesen Zeitraum von 100 % Verfügbarkeit ausgegangen.
**Berechnen der Verfügbarkeit mit harten Abhängigkeiten.** Viele Systeme weisen harte Abhängigkeiten von anderen Systemen auf. In einem solchen Fall wirkt sich eine Unterbrechung in einem abhängigen System direkt auf eine Unterbrechung des aufrufenden Systems aus. Dies steht im Gegensatz zu einer weichen Abhängigkeit, bei der ein Fehler im abhängigen System in der Anwendung kompensiert wird. Wenn harte Abhängigkeiten auftreten, ist die Verfügbarkeit des aufrufenden Systems das Produkt der Verfügbarkeiten der abhängigen Systeme. Beispiel: Wenn Sie über ein System verfügen, das für eine Zuverlässigkeit von 99,99 % ausgelegt ist und eine harte Abhängigkeit von zwei weiteren unabhängigen Systemen aufweist, die jeweils für eine Verfügbarkeit von 99,99 % ausgelegt sind, kann die Workload theoretisch eine Verfügbarkeit von 99,97 % erreichen:
Availinvok × Avail*dep1* × Avail*dep2* = Availworkload
99,99 % × 99,99 % × 99,99 % = 99,97 %
Es ist daher wichtig, dass Sie sich bei der Berechnung Ihrer Ziele mit Ihren Abhängigkeiten und den jeweiligen Verfügbarkeitsdesignzielen vertraut machen.
**Berechnen der Verfügbarkeit mit redundanten Komponenten.** Wenn ein System die Verwendung unabhängiger, redundanter Komponenten beinhaltet (z. B. redundante Ressourcen in unterschiedlichen Availability Zones), wird die theoretische Verfügbarkeit mit 100 % minus dem Produkt aus den Komponentenfehlerraten berechnet. Beispiel: Wenn ein System zwei unabhängige Komponenten verwendet und jede einzelne Komponente eine Verfügbarkeit von 99,9 % aufweist, liegt die effektive Verfügbarkeit dieser Abhängigkeit bei 99,9999 %:
![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99,9999 % = 100 % − (0,1 % × 0,1 %)
*Schnellberechnung*: Wenn die Verfügbarkeit aller Komponenten in Ihrer Berechnung ausschließlich aus der Ziffer Neun besteht, können Sie die Anzahl der Ziffern addieren, um ein Ergebnis zu erhalten. Im obigen Beispiel ergeben zwei redundante, unabhängige Komponenten mit drei Neunen Verfügbarkeit sechs Neunen.
**Berechnen der Abhängigkeitsverfügbarkeit.** Für einige Abhängigkeiten stehen Informationen zur Verfügbarkeit bereit, einschließlich der Verfügbarkeitsdesignziele für viele AWS-Services. In Fällen, in denen diese Informationen jedoch nicht verfügbar sind (z. B. bei einer Komponente, bei der der Hersteller Verfügbarkeitsinformationen nicht veröffentlicht), können Sie die Verfügbarkeit über die Ermittlung der **mittleren Betriebsdauer zwischen Ausfällen (MTBF)** und der **mittleren Reparaturzeit (MTTR))** schätzen. Eine Verfügbarkeitsschätzung kann über die folgende Formel erfolgen:
![\[\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
Wenn beispielsweise der Wert für MTBF 150 Tage ist und der Wert für MTTR mit einer Stunde angegeben ist, ergibt sich eine geschätzte Verfügbarkeit von 99,97 %.
Weitere Details finden Sie unter [Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html). Diese Informationen können Sie bei der Berechnung Ihrer Verfügbarkeit unterstützen.
**Kosten für Verfügbarkeit.** Die Entwicklung von Anwendungen für höhere Verfügbarkeiten geht in der Regel mit höheren Kosten einher. Daher ist es sinnvoll, den tatsächlichen Verfügbarkeitsbedarf zu ermitteln, bevor Sie eine Anwendung konzipieren. Höhere Verfügbarkeiten erfordern striktere Anforderungen für Tests und Validierung unter umfassenden Fehlerszenarios. Sie erfordern die Automatisierung der Wiederherstellung aus allen Fehlertypen und außerdem, dass alle Aspekte der Systemabläufe auf Basis der gleichen Standards in gleicher Weise aufgebaut und getestet werden. So müssen das Hinzufügen oder Entfernen von Kapazität, die Bereitstellung oder das Rollback von aktualisierter Software oder Konfigurationsänderungen oder die Migration von Systemdaten gemäß dem, gewünschten Verfügbarkeitsziel durchgeführt werden. Erschwerend kommt hinzu, dass neben den Kosten für die Software-Entwicklung bei einem sehr hohen Verfügbarkeitsgrad die Innovation leidet, da die Geschwindigkeit bei der Bereitstellung von Systemen sehr stark herabgesetzt werden muss. Der Leitfaden muss daher in der Anwendung der Standards und der Berücksichtigung der entsprechenden Verfügbarkeitsziele über den gesamten Lebenszyklus des Systembetriebs sehr gründlich sein.
Eine andere Möglichkeit, dass Kosten in Systemen eskalieren, die unter Designzielen für eine höhere Verfügbarkeit betrieben werden, ist die Auswahl von Abhängigkeiten. Unter diesen höheren Zielen wird sich das Angebot an Software und Services, die als Abhängigkeiten ausgewählt werden können, abhängig davon reduzieren, bei welchen dieser Services die zuvor beschriebenen hohen Investitionen zum Tragen kommen. Bei steigenden Verfügbarkeitsdesignzielen ist es üblich, dass weniger Mehrzweckservices (z. B. eine relationale Datenbank) und mehr spezielle Services angeboten werden. Der Grund dafür ist, dass spezielle Services einfacher bewertet, getestet und automatisiert werden können und ein geringeres Potenzial für überraschende Interaktionen mit eingeschlossener, jedoch nicht genutzter Funktionalität bergen.
# Notfallwiederherstellungsziele
Neben Verfügbarkeitszielen sollte Ihre Strategie für Ausfallsicherheit auch Ziele für die Notfallwiederherstellung (Disaster Recovery, DR) umfassen, die auf den Strategien zum Wiederherstellen Ihrer Workload bei Auftreten eines Notfalls basieren. Die Notfallwiederherstellung konzentriert sich auf einmalige Wiederherstellungsziele als Reaktion auf Naturkatastrophen, umfangreiche technische Fehler oder menschliche Bedrohungen wie Angriffe oder Fehler. Das unterscheidet sich von der Verfügbarkeit, bei der die mittlere Ausfallsicherheit über einen bestimmten Zeitraum bei Komponentenstörungen, Lastspitzen oder Softwarefehlern gemessen wird.
**Recovery Time Objective (RTO)** Wird von der Organisation festgelegt. RTO ist die maximal akzeptable Verzögerung zwischen der Unterbrechung und der Wiederherstellung des Service. Damit wird festgelegt, was als akzeptables Zeitfenster gilt, wenn der Service nicht verfügbar ist.
**Recovery Point Objective (RPO)** Wird von der Organisation festgelegt. RPO ist die maximal zulässige Zeitspanne seit dem letzten Wiederherstellungspunkt. Damit wird festgelegt, was als akzeptabler Datenverlust zwischen dem letzten Wiederherstellungspunkt und der Serviceunterbrechung gilt.
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*Die Beziehung von RPO (Recovery Point Objective), RTO (Recovery Time Objective) und dem Notfallereignis.*
RTO ist ähnlich wie MTTR (mittlere Reparaturzeit), da beide die Zeit zwischen dem Start eines Ausfalls und der Wiederherstellung einer Workload messen. MTTR ist jedoch ein Mittelwert, der über mehrere Verfügbarkeitsbeeinträchtigungen für Ereignisse über einen bestimmten Zeitraum hinweg verwendet wird, während RTO ein Ziel oder Maximalwert für ein *einzelnes* Ereignis ist, das sich auf die Verfügbarkeit auswirkt.
# Verstehen des Verfügbarkeitsbedarfs
Es ist weit verbreitet, die Verfügbarkeit einer Anwendung anfänglich als einzelnes Ziel für die Anwendung als Ganzes zu betrachten. Bei näherer Betrachtung können wir jedoch sehen, dass bestimmte Aspekte einer Anwendung oder eines Service unterschiedliche Verfügbarkeitsanforderungen aufweisen. Einige Systeme legen beispielsweise den Schwerpunkt auf die Fähigkeit, neue Daten vor dem Abrufen vorhandener Daten zu empfangen und zu speichern. Andere Systeme priorisieren Echtzeitvorgänge gegenüber Vorgängen, die sich auf die Konfiguration oder die Umgebung eines Systems auswirken können. Services können zu bestimmten Zeiten eines Tages möglicherweise mit sehr hohen Verfügbarkeitsanforderungen verknüpft sein, aber außerhalb dieser Zeiten wesentlich längere Ausfallzeiten tolerieren. Dies sind einige der Möglichkeiten, um eine Anwendung in ihre Bestandteile aufzugliedern und anschließend die Verfügbarkeitsanforderungen für diese Teile zu bewerten. Der Vorteil dieses Ansatzes besteht darin, dass der Fokus der Bemühungen (und der Kosten) gemäß den spezifischen Anforderungen auf die Verfügbarkeit gelegt werden kann, statt das gesamte System auf die strengste Anforderung hin zu konzipieren.
| Empfehlung |
| --- |
| Sie sollten die einzigartigen Aspekte Ihrer Anwendungen kritisch bewerten und die Verfügbarkeits- und Notfallwiederherstellungsdesignziele ggf. differenzieren, damit sie die Anforderungen Ihres Unternehmens widerspiegeln. |
In AWS teilen wir Services in der Regel in „Datenebene“ und „Steuerebene“ auf. Die Datenebene ist zuständig für die Bereitstellung von Echtzeitservices, während die Steuerebene dazu verwendet wird, die Umgebung zu konfigurieren. So handelt es sich bei Amazon-EC2-Instances, Amazon-RDS-Datenbanken und Schreib-/Lesevorgängen in Amazon-DynamoDB-Tabellen beispielsweise ausschließlich um Datenebenenvorgänge. Im Gegensatz dazu handelt es sich beim Starten neuer EC2-Instances oder RDS-Datenbanken oder dem Hinzufügen oder Ändern von Tabellenmetadaten in DynamoDB um Vorgänge auf Steuerebene. Ein hoher Verfügbarkeitsgrad ist für all diese Funktionen wichtig. Allerdings verfolgt die Datenebene in der Regel Designziele für eine höhere Verfügbarkeit als die Steuerebene. Aus diesem Grund sollten Workloads mit hohen Verfügbarkeitsanforderungen keine Laufzeitabhängigkeiten von Abläufen der Steuerebene haben.
Viele AWS-Kunden verfolgen einen ähnlichen Ansatz, um ihre Anwendungen kritisch zu bewerten und Unterkomponenten mit abweichenden Verfügbarkeitsanforderungen zu identifizieren. Verfügbarkeitsdesignziele werden dann auf die verschiedenen Aspekte zugeschnitten und es werden entsprechende Bemühungen unternommen, um das System weiterzuentwickeln. AWS verfügt über ausgeprägte Erfahrungen beim Engineering von Anwendungen mit verschiedenen Verfügbarkeitsdesignzielen, einschließlich Services mit einer Verfügbarkeit von 99,999 % oder mehr. AWS Solution Architects (SAs) können Sie dabei unterstützen, ein Design entsprechend Ihren Verfügbarkeitszielen zu erarbeiten. Je eher Sie AWS in Ihren Designprozess integrieren, desto besser können wir Sie bei der Erfüllung Ihrer Verfügbarkeitsziele unterstützen. Das Planen der Verfügbarkeit erfolgt nicht erst direkt vor der Einführung Ihrer Workload. Es ist ein kontinuierlicher Prozess, mit dem Sie Ihr Design mit wachsender Kenntnis, dem Kennenlernen realer Ereignisse und der Bewältigung verschiedener Fehlerarten anpassen können. Anschließend können Sie geeignete Anstrengungen unternehmen, um Ihre Implementierung zu verbessern.
Die Verfügbarkeitsanforderungen, die für eine Workload erforderlich sind, müssen den geschäftlichen Anforderungen und der Kritikalität entsprechen. Legen Sie zunächst unternehmenskritische Rahmenbedingungen mit definieren RTO-, RPO- und Verfügbarkeitswerten fest, um anschließend die einzelnen Workloads zu bewerten. Ein solcher Ansatz erfordert, dass die Mitarbeiter, die an der Implementierung der Workload beteiligt sind, über das Framework und die Auswirkungen ihrer Workload auf die Geschäftsanforderungen informiert sind.