Empfehlungen für die Fehlermodusanalyse
Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des Azure Well-Architected Framework:
| RE:03 | Verwenden Sie die Fehlermodusanalyse (FMA), um potenzielle Fehler in Ihren Lösungskomponenten zu identifizieren und zu priorisieren. Führen Sie FMA aus, um das Risiko und die Auswirkungen jedes Fehlermodus zu bewerten. Bestimmen Sie, wie die Workload reagiert und wie sie wiederhergestellt wird. |
|---|
In diesem Handbuch werden die bewährten Methoden für die Durchführung der Fehlermodusanalyse (FMA) für Ihre Workload beschrieben. FMA ist die Praxis, potenzielle Fehlerpunkte innerhalb Ihrer Workload und die zugehörigen Abläufe und die entsprechenden Maßnahmen zur Risikominderung zu identifizieren. Bei jedem Schritt des Flows identifizieren Sie den Strahlradius mehrerer Fehlertypen. Dies hilft Ihnen, eine neue Workload zu entwerfen oder eine bestehende Workload so umzugestalten, dass die weitreichenden Auswirkungen von Fehlern minimiert werden.
Ein wichtiger Tenet von FMA ist, dass Fehler auftreten, unabhängig davon, wie viele Ebenen von Resilienz Sie anwenden. Komplexere Umgebungen werden mehr Arten von Fehlern ausgesetzt. Aufgrund dieser Realität können Sie ihre Arbeitsauslastung so entwerfen, dass sie den meisten Arten von Fehlern standhält und ordnungsgemäß wiederhergestellt wird, wenn ein Fehler auftritt.
Wenn Sie FMA vollständig überspringen oder eine unvollständige Analyse durchführen, besteht Ihr Arbeitsaufwand dem Risiko eines unvoreingenommenen Verhaltens und potenzieller Ausfälle, die durch suboptimales Design verursacht werden.
Definitionen
| Begriff | Definition |
|---|---|
| Fehlermodus | Eine Art von Problem, das dazu führen kann, dass eine oder mehrere Workloadkomponenten beeinträchtigt oder stark beeinträchtigt werden, um nicht verfügbar zu sein. |
| Abmilderung | Die Aktivitäten, die Sie identifiziert haben, um Probleme entweder proaktiv oder reaktiv zu beheben. |
| Erkennung | Ihre Infrastruktur, Daten und App-Überwachung und Benachrichtigungsprozesse und -verfahren. |
Wichtige Entwurfsstrategien
Überprüfen und implementieren Sie die Empfehlungen zur Identifizierung von Flüssen. Es wird davon ausgegangen, dass Sie Benutzer- und Systemflüsse basierend auf der Kritischität identifiziert und priorisiert haben.
Die Daten, die Sie gesammelt haben, und die Artefakte, die Sie in Ihrer Arbeit erstellt haben, enthalten eine konkrete Beschreibung Ihrer Datenpfade, die in den einzelnen Flüssen beteiligt sind. Um in Ihrer FMA-Arbeit erfolgreich zu sein, ist Genauigkeit und Gründlichkeit in Ihren Artefakten von entscheidender Bedeutung.
Nachdem Sie die kritischen Flüsse ermittelt haben, können Sie die erforderlichen Komponenten planen. Befolgen Sie als Nächstes jeden Flussschritt, um Abhängigkeiten zu identifizieren, einschließlich Drittanbieterdiensten und potenziellen Fehlerpunkten, und planen Sie Ihre Entschärfungsstrategien.
Dekompilieren der Workload
Beim Übergang von der Idee zum Entwurf müssen Sie die Komponententypen ermitteln, die zur Unterstützung Ihrer Workload erforderlich sind. Ihr Workload bestimmt die notwendigen Komponenten, die Sie einplanen müssen. In der Regel müssen Sie die Eingangssteuerung, das Netzwerk, die Berechnung, daten, die Speicherung, unterstützende Dienste (z. B. Authentifizierung, Messaging und geheime oder schlüsselbasierte Verwaltung) und die Übergabesteuerung planen. In dieser Phase ihrer Entwurfsarbeit kennen Sie möglicherweise nicht die spezifischen Technologien, die Sie bereitstellen werden, sodass Ihr Design wie im folgenden Beispiel aussehen kann.
Nachdem Sie ihren anfänglichen Architekturentwurf erstellt haben, können Sie Ihre Flüsse überlagern, um die einzelnen Komponenten zu identifizieren, die in diesen Flüssen verwendet werden, und Listen oder Workflowdiagramme zu erstellen, die die Flüsse und deren Komponenten beschreiben. Um die Kritischität der Komponenten zu verstehen, verwenden Sie die Kritischitätsdefinitionen, die Sie den Flüssen zugewiesen haben. Berücksichtigen Sie die Auswirkungen einer Komponentenfunktion auf Ihre Flüsse.
Ermitteln von Abhängigkeiten
Identifizieren Sie Ihre Workloadabhängigkeiten, um Ihre einzelnen Fehlerpunkte zu analysieren. Durch die Dekompilierung Ihrer Workload- und Überlagerungsflüsse erhalten Sie Einblicke in Abhängigkeiten, die intern und extern für die Workload sind.
Interne Abhängigkeiten sind Komponenten im Workloadbereich, die für die Funktion der Workload erforderlich sind. Zu den typischen internen Abhängigkeiten zählen APIs oder Geheimnis-/Schlüsselverwaltungslösungen wie Azure Key Vault. Erfassen Sie für diese Abhängigkeiten die Zuverlässigkeitsdaten, z. B. Verfügbarkeits-SLAs und Skalierungsgrenzwerte. Externe Abhängigkeiten sind erforderliche Komponenten außerhalb des Workloadbereichs, z. B. eine andere Anwendung oder ein Drittanbieterdienst. Typische externe Abhängigkeiten umfassen Authentifizierungslösungen wie Microsoft Entra ID und Cloudkonnektivitätslösungen wie Azure ExpressRoute.
Identifizieren und dokumentieren Sie die Abhängigkeiten in Ihrer Workload, und fügen Sie sie in Ihre Flussdokumentationsartefakte ein.
Auswerten von Fehlerpunkten
Berücksichtigen Sie in den kritischen Abläufen Ihrer Workload jede Komponente, und bestimmen Sie, wie diese Komponente und ihre Abhängigkeiten von einem Fehlermodus betroffen sein können. Denken Sie daran, dass bei der Planung von Resilienz und Wiederherstellung viele Fehlermodi berücksichtigt werden müssen. Jede Komponente kann jeweils von mehr als einem Fehlermodus betroffen sein. Zu diesen Fehlermodi gehören:
Regionaler Ausfall. Eine gesamte Azure-Region ist nicht verfügbar.
Ausfall der Verfügbarkeitszone. Eine Azure-Verfügbarkeitszone ist nicht verfügbar.
Dienstausfall. Mindestens ein Azure-Dienst ist nicht verfügbar.
Verteilter Denial-of-Service (DDoS) oder anderer böswilliger Angriff.
Fehlkonfiguration von Apps oder Komponenten.
Operatorfehler.
Geplanter Wartungsausfall.
Komponentenüberladung.
Die Analyse sollte sich immer im Kontext des Flusses befinden, den Sie analysieren möchten. Dokumentieren Sie daher unbedingt den Effekt auf den Benutzer und das erwartete Ergebnis dieses Flusses. Wenn Sie beispielsweise über eine E-Commerce-Anwendung verfügen und Ihren Kundenfluss analysieren, kann die Auswirkung eines bestimmten Fehlermodus auf eine oder mehrere Komponenten sein, dass alle Kunden das Auschecken nicht abschließen können.
Berücksichtigen Sie die Wahrscheinlichkeit jedes Fehlermodustyps. Einige sind sehr unwahrscheinlich, z. B. Mehrzonen- oder Mehrregionenausfälle, und das Hinzufügen von Entschärfungsplanung über Redundanz hinaus ist keine gute Verwendung von Ressourcen und Zeit.
Abmilderung
Entschärfungsstrategien sind in zwei allgemeine Kategorien unterteilt: Das Erstellen von mehr Resilienz und das Entwerfen für beeinträchtigte Leistung.
Das Erstellen weiterer Resilienz umfasst das Hinzufügen von Redundanz zu Ihren Komponenten, z. B. Infrastruktur, Daten und Netzwerk, und sicherstellen, dass Ihr Anwendungsdesign bewährte Methoden für die Haltbarkeit befolgt, z. B. das Aufteilen von monolithischen Anwendungen in isolierte Apps und Microservices. Weitere Informationen finden Sie unter Empfehlungen für Redundanz und Empfehlungen zur Selbsterhaltung.
Um eine beeinträchtigte Leistung zu erzielen, identifizieren Sie potenzielle Fehlerpunkte, die möglicherweise eine oder mehrere Komponenten ihres Flusses deaktivieren, aber diesen Fluss nicht vollständig deaktivieren. Um die Funktionalität des End-to-End-Flusses aufrechtzuerhalten, müssen Sie möglicherweise einen oder mehrere Schritte an andere Komponenten umleiten oder akzeptieren, dass eine fehlerhafte Komponente eine Funktion ausführt, sodass die Funktion nicht mehr in der Benutzeroberfläche verfügbar ist. Um zum Beispiel einer E-Commerce-Anwendung zurückzukehren, kann eine fehlerhafte Komponente wie ein Microservice dazu führen, dass Ihr Empfehlungsmodul nicht verfügbar ist, aber die Kunden können weiterhin nach Produkten suchen und ihre Transaktion abschließen.
Außerdem müssen Sie die Entschärfung für Abhängigkeiten planen. Starke Abhängigkeiten spielen eine kritische Rolle bei Funktion und Verfügbarkeit einer Anwendung. Wenn sie nicht vorhanden sind oder eine Fehlfunktion auftreten, kann es erhebliche Auswirkungen haben. Das Fehlen schwacher Abhängigkeiten wirkt sich möglicherweise nur auf bestimmte Features aus und wirkt sich nicht auf die Gesamtverfügbarkeit aus. Diese Unterscheidung spiegelt die Kosten wider, um die Hohe Verfügbarkeitsbeziehung zwischen dem Dienst und seinen Abhängigkeiten aufrechtzuerhalten. Klassifizieren Sie Abhängigkeiten entweder als stark oder schwach, um zu erkennen, welche Komponenten für die Anwendung unerlässlich sind.
Wenn die Anwendung starke Abhängigkeiten aufweist, ohne die sie nicht funktionieren kann, sollten die Verfügbarkeits- und Wiederherstellungsziele dieser Abhängigkeiten mit den Zielen der Anwendung selbst übereinstimmen. Minimieren Sie Abhängigkeiten, um die Kontrolle über die Zuverlässigkeit der Anwendung zu erreichen. Weitere Informationen finden Sie unter Minimieren der Koordination zwischen Anwendungsdiensten, um Skalierbarkeit zu erzielen.
Wenn der Anwendungslebenszyklus eng mit dem Lebenszyklus seiner Abhängigkeiten verknüpft ist, kann die operative Flexibilität der Anwendung begrenzt sein, insbesondere für neue Versionen.
Erkennung
Die Fehlererkennung ist unerlässlich, um sicherzustellen, dass Sie in Ihrer Analyse korrekt Fehlerpunkte identifiziert und Ihre Bewältigungsstrategien ordnungsgemäß geplant haben. Die Erkennung in diesem Zusammenhang bedeutet die Überwachung Ihrer Infrastruktur, Ihrer Daten und Anwendung und warnungen, wenn Probleme auftreten. Automatisieren Sie die Erkennung so weit wie möglich, und erstellen Sie Redundanz in Ihre Betriebsprozesse, um sicherzustellen, dass Warnungen immer abgefangen werden und schnell genug reagieren, um Ihre Geschäftlichen Anforderungen zu erfüllen. Weitere Informationen finden Sie in den Empfehlungen für die Überwachung.
Ergebnis
Erstellen Sie für das Ergebnis Ihrer Analyse eine Reihe von Dokumenten, die Ihre Ergebnisse effektiv kommunizieren, die Entscheidungen, die Sie im Verhältnis zu den Flusskomponenten und der Entschärfung getroffen haben, und die Auswirkungen des Ausfalls auf Ihre Workload.
Priorisieren Sie in Ihrer Analyse die Fehlermodi und Entschärfungsstrategien, die Sie basierend auf Schweregrad und Wahrscheinlichkeit identifiziert haben. Verwenden Sie diese Priorisierung, um Ihre Dokumentation auf die Fehlermodi zu konzentrieren, die häufig und schwerwiegend genug sind, um die Zeit, den Aufwand und die Ressourcen für das Entwerfen von Entschärfungsstrategien zu rechtfertigen. Es kann z. B. einige Fehlermodi geben, die bei Auftreten oder Erkennung sehr selten sind. Das Entwerfen von Entschärfungsstrategien für sie lohnt sich nicht.
In der folgenden Beispieltabelle finden Sie einen Dokumentationsstartpunkt.
Während Ihrer ersten FMA-Übung werden die dokumente, die Sie erstellen, meist theoretische Planung. Die FMA-Dokumente sollten regelmäßig überprüft und aktualisiert werden, um sicherzustellen, dass sie mit Ihrer Arbeitsauslastung auf dem neuesten Stand bleiben. Chaostests und echte Erfahrungen helfen Ihnen dabei, Ihre Analysen im Laufe der Zeit zu verfeinern.
Azure-Erleichterung
Verwenden Sie Azure Monitor und Log Analytics , um Probleme in Ihrer Workload zu erkennen. Um weitere Einblicke in Probleme im Zusammenhang mit Ihrer Infrastruktur, Apps und Datenbanken zu erhalten, verwenden Sie Tools wie Application Insights, Container Insights, Network Insights, VM Insights und SQL Insights.
Azure Chaos Studio ist ein verwalteter Dienst, der Chaos-Engineering verwendet, um Sie beim Messen, Verstehen und Verbessern der Resilienz Ihrer Cloudanwendungen und Dienste zu unterstützen.
Informationen zum Anwenden von FMA-Prinzipien auf allgemeine Azure-Dienste finden Sie unter Fehlermodusanalyse für Azure-Anwendungen.
Beispiel
In der folgenden Tabelle ist ein FMA-Beispiel für eine E-Commerce-Website dargestellt, die in Azure-App Dienstinstanzen mit Azure SQL-Datenbanken gehostet wird und von Azure Front Door vorne angezeigt wird.
Benutzerablauf: Benutzeranmeldung, Produktsuche und Interaktion mit Einkaufswagen
| Komponente | Risiko | Wahrscheinlichkeit | Effekt/Entschärfung/Hinweis | Outage |
|---|---|---|---|---|
| Microsoft Entra ID | Dienstunterbrechung | Niedrig | Vollständiger Workloadausfall. Abhängig von Microsoft zur Behebung. | Vollständig |
| Microsoft Entra ID | Fehlkonfiguration | Medium | Benutzer können sich nicht anmelden. Kein nachgeschalteter Effekt. Das Konfigurationsproblem des Helpdesks wird an das Identitätsteam gemeldet. | Keine |
| Azure Front Door | Dienstunterbrechung | Niedrig | Vollständiger Ausfall für externe Benutzer. Abhängig von Microsoft zur Behebung. | Nur extern |
| Azure Front Door | Regionaler Ausfall | Sehr niedrig | Minimaler Effekt. Azure Front Door ist ein globaler Dienst, sodass das globale Datenverkehrsrouting den Datenverkehr über nicht wirksamen Azure-Regionen leitet. | Keine |
| Azure Front Door | Fehlkonfiguration | Medium | Fehlkonfigurationen sollten während der Bereitstellung abgefangen werden. Wenn dies während eines Konfigurationsupdates geschieht, müssen Administratoren Änderungen zurücksetzen. Das Konfigurationsupdate verursacht einen kurzen externen Ausfall. | Nur extern |
| Azure Front Door | DDoS-Angriff | Medium | Potenzial für Unterbrechungen. Microsoft verwaltet den DDoS-Schutz (L3 und L4), und die Azure-Webanwendungsfirewall blockiert die meisten Bedrohungen. Potenzielles Wirkungsrisiko von L7-Angriffen. | Potenzial für teilweisen Ausfall |
| Azure SQL | Dienstunterbrechung | Niedrig | Vollständiger Workloadausfall. Abhängig von Microsoft zur Behebung. | Vollständig |
| Azure SQL | Regionaler Ausfall | Sehr niedrig | Die Automatische Failovergruppe schlägt zu sekundärer Region fehl. Potenzieller Ausfall während des Failovers. Wiederherstellungszeitziele (RTOs) und Ziele des Wiederherstellungspunkts (Recovery Point Objectives, RPOs), die während der Zuverlässigkeitstests ermittelt werden sollen. | Potenzial voll |
| Azure SQL | Ausfall der Verfügbarkeitszone | Niedrig | Keine Auswirkungen | Keine |
| Azure SQL | Böswilliger Angriff (Injektion) | Medium | Minimales Risiko. Alle Azure SQL-Instanzen sind durch private Endpunkte und Netzwerksicherheitsgruppen (Network Security Groups, NSGs) durch virtuelle Netzwerke gebunden. | Potenzielles niedriges Risiko |
| App Service | Dienstunterbrechung | Niedrig | Vollständiger Workloadausfall. Abhängig von Microsoft zur Behebung. | Vollständig |
| App Service | Regionaler Ausfall | Sehr niedrig | Minimaler Effekt. Latenz für Benutzer in wirksamen Regionen. Azure Front Door leitet den Datenverkehr automatisch an nicht wirksame Regionen weiter. | Keine |
| App Service | Ausfall der Verfügbarkeitszone | Niedrig | Keine Auswirkung. App-Dienste wurden als Zonenredundanz bereitgestellt. Ohne Zonenredundanz besteht ein Effektpotenzial. | Keine |
| App Service | DDoS-Angriff | Medium | Minimaler Effekt. Eingehender Datenverkehr wird durch die Azure Front Door- und Azure-Webanwendungsfirewall geschützt. | Keine |
Verwandte Links
Zuverlässigkeitsprüfliste
Lesen Sie den vollständigen Satz von Empfehlungen.