Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Phase 1: Ziele setzen
Die Grundlage für die Phase der gesetzten Ziele ist es, zu verstehen, welches Maß an Resilienz erforderlich ist und wie Sie es messen werden. Es ist schwierig, etwas zu verbessern, wenn Sie kein Ziel haben und es nicht messen können.
Nicht alle Anwendungen benötigen das gleiche Maß an Belastbarkeit. Wenn Sie sich Ziele setzen, sollten Sie das erforderliche Niveau berücksichtigen, um die richtigen Investitionen und Kompromisse zu tätigen. Eine gute Analogie hierfür ist ein Auto: Es hat vier Reifen, trägt aber nur ein Reserverad. Die Wahrscheinlichkeit, während einer Fahrt mehrere platten Reifen zu bekommen, ist gering, und zusätzliche Ersatzteile könnten andere Merkmale wie den Laderaum oder die Kraftstoffeffizienz beeinträchtigen, sodass dies ein vernünftiger Kompromiss ist.
Nachdem Sie die Ziele definiert haben, implementieren Sie in späteren Phasen (Phase 2: Planung und Implementierung und Phase 4: Betrieb) Kontrollen der Beobachtbarkeit, um zu ermitteln, ob die Ziele erreicht werden.
Zuordnung kritischer Anwendungen
Die Definition von Resilienzzielen sollte nicht ausschließlich ein technisches Gespräch sein. Beginnen Sie stattdessen mit einem geschäftsorientierten Fokus, um zu verstehen, was die Anwendung bieten sollte und welche Folgen eine Beeinträchtigung hat. Dieses Verständnis der Geschäftsziele überträgt sich dann auf Bereiche wie Architektur, Technik und Betrieb. Alle von Ihnen definierten Stabilitätsziele können auf alle Ihre Anwendungen angewendet werden, aber die Art und Weise, wie die Ziele gemessen werden, hängt häufig von der Funktion der Anwendung ab. Möglicherweise führen Sie eine Anwendung aus, die für Ihr Unternehmen von entscheidender Bedeutung ist, und wenn diese Anwendung beeinträchtigt wird, könnte Ihr Unternehmen erhebliche Umsatzeinbußen oder Reputationsschäden erleiden. Alternativ haben Sie möglicherweise eine andere Anwendung, die nicht so wichtig ist und einige Ausfallzeiten tolerieren kann, ohne die Geschäftsfähigkeit Ihres Unternehmens zu beeinträchtigen.
Stellen Sie sich als Beispiel eine Auftragsverwaltungsanwendung für ein Einzelhandelsunternehmen vor. Wenn die Komponenten der Auftragsverwaltungsanwendung beeinträchtigt sind und nicht ordnungsgemäß funktionieren, werden neue Verkäufe nicht abgeschlossen. Dieses Einzelhandelsunternehmen hat auch ein Café für seine Mitarbeiter, das sich in einem seiner Gebäude befindet. Das Café verfügt über ein Online-Menü, auf das die Mitarbeiter auf einer statischen Webseite zugreifen können. Wenn diese Webseite nicht mehr verfügbar ist, können sich einige Mitarbeiter beschweren, aber das wird dem Unternehmen nicht unbedingt finanziellen Schaden zufügen. Auf der Grundlage dieses Beispiels würde sich das Unternehmen wahrscheinlich für aggressivere Stabilitätsziele für die Auftragsverwaltungsanwendung entscheiden, aber keine nennenswerten Investitionen tätigen, um die Ausfallsicherheit der Webanwendung sicherzustellen.
Die Identifizierung der kritischsten Anwendungen, der Bereiche, in denen der größte Aufwand erforderlich ist und wo Kompromisse eingegangen werden müssen, ist genauso wichtig wie die Fähigkeit, die Widerstandsfähigkeit einer Anwendung in der Produktion zu messen. Um die Auswirkungen einer Wertminderung besser zu verstehen, können Sie eine Business Impact Analysis (BIA) durchführen. Eine BIA bietet einen strukturierten und systematischen Ansatz zur Identifizierung und Priorisierung kritischer Geschäftsanwendungen, zur Bewertung potenzieller Risiken und Auswirkungen sowie zur Identifizierung unterstützender Abhängigkeiten. Die BIA hilft dabei, die Kosten von Ausfallzeiten für die wichtigsten Anwendungen Ihres Unternehmens zu quantifizieren. Anhand dieser Kennzahl lässt sich abschätzen, wie viel es kosten wird, wenn eine bestimmte Anwendung beeinträchtigt ist und ihre Funktion nicht erfüllen kann. Im vorherigen Beispiel könnte das Einzelhandelsgeschäft erhebliche Umsatzeinbußen hinnehmen, wenn die Anwendung zur Auftragsverwaltung beeinträchtigt ist.
Zuordnung von Benutzergeschichten
Während des BIA-Prozesses stellen Sie möglicherweise fest, dass eine Anwendung für mehr als eine Geschäftsfunktion verantwortlich ist oder dass eine Geschäftsfunktion mehrere Anwendungen erfordert. Im vorherigen Beispiel eines Einzelhandelsunternehmens sind für die Auftragsverwaltungsfunktion möglicherweise separate Anwendungen für Checkout, Werbung und Preisgestaltung erforderlich. Wenn eine Anwendung ausfällt, können sich dies sowohl auf das Unternehmen als auch auf die Benutzer auswirken, die mit dem Unternehmen interagieren. Beispielsweise ist das Unternehmen möglicherweise nicht in der Lage, neue Bestellungen hinzuzufügen, Zugang zu Werbeaktionen und Rabatten zu gewähren oder den Preis seiner Produkte zu aktualisieren. Diese verschiedenen Funktionen, die für die Auftragsverwaltungsfunktion erforderlich sind, können auf mehreren Anwendungen basieren. Diese Funktionen können auch mehrere externe Abhängigkeiten aufweisen, was den Prozess der Erzielung einer ausschließlich komponentenorientierten Resilienz zu komplex macht. Eine bessere Möglichkeit, mit diesem Szenario umzugehen, besteht darin, sich auf Benutzerberichte
Wenn Sie sich auf Anwenderberichte konzentrieren, können Sie besser verstehen, welche Aspekte des Kundenerlebnisses am wichtigsten sind, sodass Sie Mechanismen zum Schutz vor bestimmten Bedrohungen entwickeln können. Im vorherigen Beispiel könnte es sich bei einer User Story um Checkout handeln, die die Checkout-Anwendung beinhaltet und von der Preisgestaltungsanwendung abhängig ist. Eine andere User Story könnte die Anzeige von Werbeaktionen sein, was auch die Werbeanwendung beinhaltet. Nachdem Sie die wichtigsten Anwendungen und ihre User Stories zugeordnet haben, können Sie damit beginnen, die Metriken zu definieren, anhand derer Sie die Widerstandsfähigkeit dieser User Stories messen werden. Diese Kennzahlen können auf ein gesamtes Portfolio oder auf einzelne User Stories angewendet werden.
Definition von Messungen
Recovery Point Objectives (RPOs), Recovery Time Objectives (RTOs) und Service Level Objectives (SLOs) sind branchenübliche Messgrößen, mit denen die Widerstandsfähigkeit eines bestimmten Systems bewertet wird. RPO bezieht sich darauf, wie viel Datenverlust das Unternehmen bei einem Ausfall tolerieren kann, wohingegen RTO ein Maß dafür ist, wie schnell eine Anwendung nach einem Ausfall wieder verfügbar sein muss. Diese beiden Kennzahlen werden in Zeiteinheiten gemessen: Sekunden, Minuten und Stunden. Sie können auch messen, wie lange die Anwendung ordnungsgemäß funktioniert, d. h. sie erfüllt ihre Funktionen wie vorgesehen und ist für ihre Benutzer zugänglich. Diese SLOs beschreiben das erwartete Serviceniveau, das Kunden erhalten werden, und werden anhand von Kennzahlen wie dem Prozentsatz (%) der Anfragen gemessen, die innerhalb einer Antwortzeit von weniger als einer Sekunde ohne Fehler bearbeitet werden (z. B. erhalten 99,99% der Anfragen jeden Monat eine Antwort). RPO und RTO beziehen sich auf Disaster-Recovery-Strategien, wobei davon ausgegangen wird, dass es zu Unterbrechungen des Anwendungsbetriebs und der Wiederherstellungsprozesse kommen wird, die von der Wiederherstellung von Backups bis hin zur Umleitung von Benutzerdatenverkehr reichen. SLOs werden durch die Implementierung von Hochverfügbarkeitskontrollen behoben, die dazu neigen, die Ausfallzeiten einer Anwendung zu reduzieren.
SLO-Metriken werden häufig bei der Definition von Service Level Agreements (SLAs) verwendet, bei denen es sich um Verträge zwischen Dienstanbietern und Endbenutzern handelt. SLAs sind in der Regel mit finanziellen Verpflichtungen verbunden und enthalten Strafen, die vom Anbieter zu zahlen sind, wenn diese Vereinbarungen nicht eingehalten werden. Eine SLA ist jedoch kein Maßstab für Ihre Resilienz, und eine Erhöhung einer SLA macht Ihre Anwendung nicht widerstandsfähiger.
Sie können damit beginnen, Ihre Ziele auf der Grundlage von SLOs, RPOs und RTOs festzulegen. Nachdem Sie Ihre Resilienzziele definiert und sich ein klares Bild von Ihren RPO- und RTO-Zielen gemacht haben, können Sie eine Bewertung Ihrer Architektur durchführen, AWS Resilience Hub
Erstellung zusätzlicher Messungen
RPO, RTO und SLOs sind gute Indikatoren für Resilienz, aber Sie können Ziele auch aus geschäftlicher Sicht betrachten und Ziele rund um die Funktionen Ihrer Anwendung definieren. Ihr Ziel könnte beispielsweise lauten: Erfolgreiche Bestellungen pro Minute bleiben über 98%, wenn die Latenz zwischen meinem Frontend und meinem Backend um 40% steigt.Oder: Pro Sekunde gestartete Streams bleiben innerhalb einer Standardabweichung vom Durchschnitt, auch wenn eine bestimmte Komponente verloren geht. Sie können auch Ziele festlegen, um die mittlere Wiederherstellungszeit (MTTR) bei bekannten Fehlertypen zu reduzieren. Beispiel: Die Wiederherstellungszeiten werden um x% reduziert, wenn eines dieser bekannten Probleme auftritt. Durch die Festlegung von Zielen, die sich an den Geschäftsanforderungen orientieren, können Sie die Arten von Ausfällen vorhersehen, die Ihre Anwendung tolerieren sollte. Es hilft Ihnen auch dabei, Ansätze zu finden, mit denen Sie die Wahrscheinlichkeit einer Beeinträchtigung Ihrer Anwendung verringern können.
Wenn Sie über das Ziel nachdenken, den Betrieb fortzusetzen, wenn Sie 5% der Instances verlieren, die Ihre Anwendung unterstützen, könnten Sie entscheiden, dass Ihre Anwendung vorab skaliert werden sollte oder die Möglichkeit haben sollte, schnell genug zu skalieren, um den zusätzlichen Datenverkehr zu bewältigen, der bei diesem Ereignis entsteht. Oder Sie könnten entscheiden, dass Sie verschiedene Architekturmuster nutzen sollten, wie im Abschnitt Phase 2: Entwerfen und Implementieren beschrieben.
Sie sollten auch Messgrößen zur Beobachtung Ihrer spezifischen Geschäftsziele implementieren. Sie können beispielsweise die durchschnittliche Bestellrate, den durchschnittlichen Bestellpreis, die durchschnittliche Anzahl von Abonnements oder andere Kennzahlen verfolgen, die anhand des Verhaltens Ihrer Anwendung Aufschluss über den Zustand Ihres Unternehmens geben können. Durch die Implementierung von Beobachtungsfunktionen für Ihre Anwendung können Sie Alarme einrichten und Maßnahmen ergreifen, wenn diese Messwerte Ihre definierten Grenzen überschreiten. Die Beobachtbarkeit wird im Abschnitt Phase 4: Betrieb ausführlicher behandelt.
