# 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.