Fehlermodusanalyse für Azure-Anwendungen

Fehlermodusanalyse (Failure Mode Analysis, FMA) ist ein Prozess zur Erstellung der Zuverlässigkeit in einem System, indem mögliche Fehlerpunkte identifiziert werden. Die FMA sollte Teil der Architektur- und Entwurfsphasen sein, sodass Sie sowohl Resilienz (die Fähigkeit, Fehlern standzuhalten) als auch die Wiederherstellbarkeit (die Fähigkeit, Funktionen nach Fehlern wiederherzustellen) von Anfang an in das System zu integrieren.

Hier folgt der allgemeine Prozess zum Durchführen einer FMEA:

1. Identifizieren Sie alle Komponenten im System. Schließen Sie externe Abhängigkeiten ein, z. B. Identitätsanbieter und Drittanbieterdienste.

2. Identifizieren Sie für jede Komponente potenzielle Fehler, die auftreten können. Eine einzelne Komponente verfügt möglicherweise über mehrere Fehlermodus. Beispielsweise sollten Sie Lese- und Schreibfehler getrennt betrachten, da deren Auswirkungen und die möglichen Schritte zur Entschärfung unterschiedlich ausfallen werden.

3. Bewerten Sie die einzelnen Fehlermodi nach ihrem Gesamtrisiko. Beachten Sie folgende Faktoren:

   • Was ist die Wahrscheinlichkeit des Fehlers? Tritt der Fehler relativ häufig auf? Äußerst selten? Sie brauchen keine exakten Zahlen. Der Zweck besteht darin, der Priorität einen Rang zuzuweisen.
   • Welche Auswirkungen hat dies auf die Anwendung in Bezug auf Verfügbarkeit, Datenverlust, Kosten und Geschäftsunterbrechung?

4. Legen Sie für jeden Fehlermodus fest, wie die Anwendung reagieren und wiederhergestellt werden soll. Berücksichtigen Sie Kompromisse in Bezug auf Kosten und Anwendungskomplexität.

Dieser Artikel enthält als Ausgangspunkt für den FMA-Prozess einen Katalog mit möglichen Fehlerzuständen und den entsprechenden Schritten zur Entschärfung. Der Katalog ist nach Technologie oder Azure-Dienst sowie einer zusätzlichen allgemeinen Kategorie für das Design auf Anwendungsebene gegliedert. Der Katalog ist nicht vollständig, deckt aber viele der wichtigsten Azure-Dienste ab.

Microsoft Entra ID

Fehler bei der OpenID Connect-Authentifizierung.

Erkennung: Mögliche Fehlermodi:

1. Microsoft Entra-ID ist nicht verfügbar oder kann aufgrund eines Netzwerkproblems nicht erreicht werden. Bei der Umleitung zum Authentifizierungsendpunkt ist ein Fehler aufgetreten, und die OpenID Connect-Middleware löst eine Ausnahme aus.
2. Der Microsoft Entra-Mandant ist nicht vorhanden. Bei der Umleitung zum Authentifizierungsendpunkt wird ein HTTP-Fehlercode zurückgegeben, und die OpenID Connect-Middleware löst eine Ausnahme aus.
3. Der Benutzer kann sich nicht authentifizieren. Es ist keine Erkennungsstrategie erforderlich. Microsoft Entra ID behandelt Anmeldefehler.

Wiederherstellung:

1. Fangen Sie nicht behandelte Ausnahmen von der Middleware ab.
2. Behandeln Sie AuthenticationFailed-Ereignisse.
3. Leiten Sie den Benutzer zu einer Fehlerseite um.
4. Der Benutzer versucht den Vorgang erneut.

Azure KI-Suche

Das Schreiben von Daten in Azure AI Search schlägt fehl.

Erkennung: Erkennen Sie Microsoft.Rest.Azure.CloudException-Fehler.

Wiederherstellung:

Das Search .NET SDK versucht nach vorübergehenden Fehlern automatisch, den Vorgang erneut durchzuführen. Alle Ausnahmen, die vom Client-SDK ausgelöst werden, sollten als nicht vorübergehende Fehler behandelt werden.

Die standardmäßige Wiederholungsrichtlinie verwendet einen exponentiellen Backoff. Rufen Sie SetRetryPolicy für die Klasse SearchIndexClient oder SearchServiceClient auf, um eine andere Wiederholungsrichtlinie zu verwenden. Weitere Informationen finden Sie unter Automatische Wiederholungsversuche.

Diagnose: Verwenden Sie Suchverkehrsanalytik.

Das Lesen von Daten aus Azure AI Search schlägt fehl.

Erkennung: Erkennen Sie Microsoft.Rest.Azure.CloudException-Fehler.

Wiederherstellung:

Das Search .NET SDK versucht nach vorübergehenden Fehlern automatisch, den Vorgang erneut durchzuführen. Alle Ausnahmen, die vom Client-SDK ausgelöst werden, sollten als nicht vorübergehende Fehler behandelt werden.

Die standardmäßige Wiederholungsrichtlinie verwendet einen exponentiellen Backoff. Rufen Sie SetRetryPolicy für die Klasse SearchIndexClient oder SearchServiceClient auf, um eine andere Wiederholungsrichtlinie zu verwenden. Weitere Informationen finden Sie unter Automatische Wiederholungsversuche.

Diagnose: Verwenden Sie Suchverkehrsanalytik.

Kassandra

Beim Lesen aus einem Knoten oder beim Schreiben in einen Knoten ist ein Fehler aufgetreten.

Erkennung: Fangen Sie die Ausnahme ab. Für .NET-Clients ist dies normalerweise System.Web.HttpException. Andere Client haben möglicherweise andere Ausnahmetypen. Weitere Informationen finden Sie unter Cassandra error handling done right.

Wiederherstellung:

• Jeder Cassandra-Client verfügt über eigene Wiederholungsrichtlinien und -funktionen. Weitere Informationen finden Sie unter Cassandra error handling done right.
• Verwenden Sie eine rackfähige Bereitstellung mit Datenknoten, die über die Fehlerdomänen verteilt sind.
• Nehmen Sie die Bereitstellung in mehreren Regionen mit lokaler Quorumkonsistenz vor. Wenn ein nicht vorübergehender Fehler auftritt, wechseln Sie zu einer anderen Region.

Diagnose: Anwendungsprotokolle

Queue Storage

Beim Schreiben einer Nachricht in Azure Queue Storage tritt fortlaufend ein Fehler auf.

Erkennung: Nach N Wiederholungsversuchen tritt weiterhin ein Fehler beim Schreibvorgang auf.

Wiederherstellung:

• Speichern Sie die Daten in einem lokalen Cache, und leiten Sie die Schreibvorgänge zu einem späteren Zeitpunkt, wenn der Dienst verfügbar ist, an den Speicher weiter.
• Erstellen Sie eine sekundäre Warteschlange, und schreiben Sie in diese Warteschlange, wenn die primäre Warteschlange nicht verfügbar ist.

Diagnose: Verwenden Sie die Speichermetriken.

Die Anwendung kann eine bestimmte Nachricht aus der Warteschlange nicht verarbeiten.

Erkennung: Dies ist anwendungsspezifisch. Die Nachricht enthält z. B. ungültige Daten oder bei der Geschäftslogik ist ein Fehler aufgetreten.

Wiederherstellung:

Verschieben Sie die Nachricht in eine separate Warteschlange. Führen Sie einen separaten Prozess aus, um die Nachrichten in der Warteschlange zu untersuchen.

Erwägen Sie die Verwendung von Azure Service Bus Messaging-Warteschlangen, die zu diesem Zweck über eine Warteschlange für unzustellbare Nachrichten verfügen.

Diagnose: Verwenden Sie die Anwendungsprotokollierung.

SQL-Datenbank

Es kann keine Verbindung zur Datenbank in der primären Region hergestellt werden.

Erkennung: Beim Herstellen der Verbindung ist ein Fehler aufgetreten.

Wiederherstellung:

• Aktivieren Sie Zonenredundanz. Durch die Aktivierung von Zonenredundanz repliziert Azure SQL-Datenbank Ihre Schreibvorgänge automatisch in mehrere Azure-Verfügbarkeitszonen innerhalb der unterstützten Regionen. Weitere Informationen finden Sie unter Zonenredundante Verfügbarkeit.

• Aktivieren Sie die Georeplikation. Wenn Sie eine Lösung mit mehreren Regionen entwerfen, ziehen Sie eine Aktivierung der aktiven Georeplikation für die SQL-Datenbank in Betracht.

  Voraussetzung: Die Datenbank muss für die aktive Georeplikation konfiguriert sein. Siehe Aktive Georeplikation der SQL-Datenbank.

  • Bei Abfragen lesen Sie aus einem sekundären Replikat.
  • Für Einfüge- und Aktualisierungsvorgänge führen Sie einen manuellen Failover zu einem sekundären Replikat durch. Weitere Informationen finden Sie unter Initiieren eines geplanten oder ungeplanten Failovers für die Azure SQL-Datenbank.

  Das Replikat verwendet eine andere Verbindungszeichenfolge, sodass Sie die Verbindungszeichenfolge in Ihrer Anwendung aktualisieren müssen.

Die Verbindungen im Verbindungspool gehen für den Client zur Neige.

Erkennung: Erkennen Sie System.InvalidOperationException-Fehler.

Wiederherstellung:

• Wiederholen Sie den Vorgang.
• Isolieren Sie als vorbeugende Maßnahme die Verbindungspools für jeden Anwendungsfall, sodass ein Anwendungsfall nicht alle Verbindungen kontrollieren kann.
• Erhöhen Sie die maximale Anzahl von Verbindungspools.

Diagnose: Anwendungsprotokolle.

Der Grenzwert für Datenbankverbindungen wurde erreicht.

Erkennung: Azure SQL-Datenbank begrenzt die Anzahl der gleichzeitigen Worker, Anmeldungen und Sitzungen. Die Grenzwerte hängen von der Dienstebene ab. Weitere Informationen finden Sie unter Ressourceneinschränkungen für Azure SQL-Datenbank.

Um diese Fehler zu erkennen, fangen Sie System.Data.SqlClient.SqlException ab, und überprüfen Sie den Wert von SqlException.Number für den SQL-Fehlercode. Eine Liste mit relevanten Fehlercodes finden Sie unter SQL-Fehlercodes für SQL-Datenbank-Clientanwendungen: Datenbankverbindungsfehler und andere Probleme.

Wiederherstellen. Diese Fehler werden als vorübergehend betrachtet, sodass das Problem durch erneutes Wiederholen behoben werden kann. Wenn Sie diese Fehler immer wieder feststellen, sollten Sie eine Skalierung der Datenbank in Betracht ziehen.

Diagnose: Die sys.event_log-Abfrage gibt erfolgreiche Datenbankverbindungen, Verbindungsfehler und Deadlocks zurück.

• Erstellen Sie eine Warnungsregel für fehlerhafte Verbindungen.
• Aktivieren Sie die SQL-Datenbanküberwachung, und führen Sie eine Überprüfung auf fehlerhafte Anmeldungen durch.

Nachrichtenübermittlung im Service-Bus

Beim Lesen einer Nachricht aus einer Service Bus-Warteschlange ist ein Fehler aufgetreten.

Erkennung: Fangen Sie vom Client-SDK stammende Ausnahmen ab. Die Basisklasse für Service Bus-Ausnahmen ist MessagingException. Wenn es sich um einen vorübergehenden Fehler handelt, ist die IsTransient-Eigenschaft „true“.

Weitere Informationen finden Sie unter Service Bus-Messagingausnahmen.

Wiederherstellung:

1. Wiederholen Sie den Vorgang bei vorübergehenden Fehlern.
2. Nachrichten, die keinem Empfänger übermittelt werden können, befinden sich in einer Warteschlange für unzustellbare Nachrichten. Verwenden Sie diese Warteschlange, um zu sehen, welche Nachrichten nicht empfangen werden konnten. Es erfolgt keine automatische Bereinigung der Warteschlange für unzustellbare Nachrichten. Nachrichten verbleiben dort, bis Sie sie explizit abrufen. Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Beim Schreiben einer Nachricht in eine Service Bus-Warteschlange ist ein Fehler aufgetreten.

Erkennung: Fangen Sie vom Client-SDK stammende Ausnahmen ab. Die Basisklasse für Service Bus-Ausnahmen ist MessagingException. Wenn es sich um einen vorübergehenden Fehler handelt, ist die IsTransient-Eigenschaft „true“.

Weitere Informationen finden Sie unter Service Bus-Messagingausnahmen.

Wiederherstellung:

• Der Service Bus-Client wiederholt den Versuch nach einem vorübergehenden Fehler automatisch. Standardmäßig wird ein exponentieller Backoff verwendet. Nach der maximalen Anzahl der Wiederholungsversuche oder der maximalen Timeoutperiode löst der Client eine Ausnahme aus.

• Wenn das Warteschlangenkontingent überschritten wird, löst der Client QuotaExceededException aus. Weitere Details finden Sie in der Ausnahmemeldung. Entfernen Sie einige Nachrichten aus der Warteschlange, bevor Sie den Versuch wiederholen, und ziehen Sie in Betracht, das Circuit Breaker Pattern zu verwenden, um fortlaufende Wiederholungsversuche zu vermeiden, während das Kontingent überschritten wird. Stellen Sie darüber hinaus sicher, dass für die BrokeredMessage.TimeToLive-Eigenschaft kein zu hoher Wert festgelegt ist.

• Innerhalb einer Region kann die Resilienz mithilfe von partitionierten Warteschlangen oder Themen verbessert werden. Eine nicht partitionierte Warteschlange bzw. ein Thema ist einem Nachrichtenspeicher zugewiesen. Wenn dieser Nachrichtenspeicher nicht verfügbar ist, schlagen alle Vorgänge in Bezug auf die Warteschlange oder das Thema fehl. Eine partitionierte Warteschlange bzw. ein Thema ist über mehrere Nachrichtenspeicher hinweg partitioniert.

• Verwenden Sie Zonenredundanz, um Änderungen automatisch zwischen mehreren Verfügbarkeitszonen zu replizieren. Wenn eine Verfügbarkeitszone ausfällt, wird automatisch ein Failover durchgeführt. Weitere Informationen finden Sie unter Best Practices zum Schützen von Anwendungen vor Service Bus-Ausfällen und Notfällen.

• Wenn Sie eine Lösung mit mehreren Regionen entwerfen, erstellen Sie zwei Service Bus-Namespaces in verschiedenen Regionen, und replizieren Sie die Nachrichten. Sie können entweder die aktive oder die passive Replikation verwenden.

  • Aktive Replikation: Der Client sendet alle Nachrichten an beide Warteschlangen. Der Empfänger lauscht an beiden Warteschlangen. Kennzeichnen Sie Nachrichten mit einem eindeutigen Bezeichner, damit der Client doppelte Nachrichten verwerfen kann.
  • Passive Replikation: Der Client sendet die Nachricht an eine Warteschlange. Wenn ein Fehler aufgetreten ist, führt der Client einen Fallback zur anderen Warteschlange aus. Der Empfänger lauscht an beiden Warteschlangen. Dieser Ansatz reduziert die Anzahl doppelter Nachrichten, die gesendet werden. Der Empfänger muss jedoch weiterhin doppelte Nachrichten verarbeiten.

  Weitere Informationen finden Sie unter GeoReplication-Beispiel und Bewährte Methoden zum Schützen von Anwendungen vor Service Bus-Ausfällen und Notfällen.

Doppelte Nachricht.

Erkennung: Überprüfen Sie die Eigenschaften MessageId und DeliveryCount der Nachricht.

Wiederherstellung:

• Gestalten Sie Ihre Verarbeitungsvorgänge für Nachrichten nach Möglichkeit idempotent. Andernfalls speichern Sie Nachrichten-IDs von bereits verarbeiteten Nachrichten, und überprüfen Sie die ID vor der Verarbeitung einer Nachricht.

• Aktivieren Sie die Duplikaterkennung, indem Sie beim Erstellen der Warteschlange RequiresDuplicateDetection auf „true“ festlegen. Mit dieser Einstellung löscht Service Bus automatisch alle Nachrichten, die mit derselben MessageId wie eine vorherige Nachricht gesendet werden. Beachten Sie die folgenden Punkte:

  • Diese Einstellung verhindert, dass doppelte Nachrichten in die Warteschlange gestellt werden. Sie hindert einen Empfänger nicht daran, dieselbe Nachricht mehrmals zu verarbeiten.
  • Die Duplikaterkennung verfügt über ein Zeitfenster. Wenn dieses Zeitfenster beim Senden eines Duplikats überschritten wird, kann das Duplikat nicht erkannt werden.

Diagnose: Protokollieren Sie doppelte Nachrichten.

Die Anwendung kann eine bestimmte Nachricht aus der Warteschlange nicht verarbeiten.

Erkennung: Dies ist anwendungsspezifisch. Die Nachricht enthält z. B. ungültige Daten oder bei der Geschäftslogik ist ein Fehler aufgetreten.

Wiederherstellung:

Zwei Fehlermodi müssen berücksichtigt werden.

• Der Empfänger erkennt den Fehler. In diesem Fall verschieben Sie die Nachricht in die Warteschlange für unzustellbare Nachrichten. Führen Sie später einen separaten Prozess aus, um die Nachrichten in der Warteschlange für unzustellbare Nachrichten zu untersuchen.
• Beim Empfänger tritt mitten in der Verarbeitung der Nachricht ein Ausfall auf, z. B. aufgrund einer nicht behandelten Ausnahme. Verwenden Sie den Modus PeekLock, um diesen Fall zu behandeln. Wenn in diesem Modus die Sperre abläuft, wird die Nachricht für andere Empfänger verfügbar. Wenn die Nachricht die maximale Anzahl der Zustellungen oder die Gültigkeitsdauer überschreitet, wird die Nachricht automatisch in die Warteschlange für unzustellbare Nachrichten verschoben.

Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Diagnose: Sobald die Anwendung eine Nachricht in die Warteschlange für unzustellbare Nachrichten verschiebt, schreiben Sie ein Ereignis in die Anwendungsprotokolle.

Speicher

Beim Schreiben von Daten in Azure Storage ist ein Fehler aufgetreten.

Erkennung: Der Client erhält beim Schreiben entsprechende Fehlermeldungen.

Wiederherstellung:

1. Versuchen Sie den Vorgang erneut, um die Wiederherstellung nach vorübergehenden Fehlern zu erreichen. Die Wiederholungsrichtlinie im Client-SDK verarbeitet dies automatisch.

2. Implementieren Sie das Trennschalter-Muster, um eine Überlastung des Speichers zu vermeiden.

3. Wenn bei N Wiederholungsversuchen Fehler auftreten, führen Sie einen ordnungsgemäßen Fallback aus. Beispiel:

   • Speichern Sie die Daten in einem lokalen Cache, und leiten Sie die Schreibvorgänge zu einem späteren Zeitpunkt, wenn der Dienst verfügbar ist, an den Speicher weiter.
   • Wenn der Schreibvorgang in einem Transaktionsbereich erfolgt ist, kompensieren Sie die Transaktion.

Diagnose: Verwenden Sie die Speichermetriken.

Beim Lesen von Daten aus Azure Storage tritt ein Fehler auf.

Erkennung: Der Client erhält beim Lesen entsprechende Fehlermeldungen.

Wiederherstellung:

1. Versuchen Sie den Vorgang erneut, um die Wiederherstellung nach vorübergehenden Fehlern zu erreichen. Die Wiederholungsrichtlinie im Client-SDK verarbeitet dies automatisch.
2. Wenn für RA-GRS-Speicher beim Lesen aus dem primären Endpunkt ein Fehler auftritt, versuchen Sie den Lesevorgang mit einem sekundären Endpunkt. Das Client-SDK kann dies automatisch verarbeiten. Informationen finden Sie unter Azure Storage-Replikation.
3. Wenn bei N Wiederholungsversuchen Fehler auftreten, führen Sie eine Fallbackaktion zum ordnungsgemäßen Herabstufen durch. Wenn z. B. ein Produktbild nicht aus dem Speicher abgerufen werden kann, zeigen Sie ein allgemeines Platzhalterbild an.

Diagnose: Verwenden Sie die Speichermetriken.

Virtueller Computer

Beim Herstellen der Verbindung mit einer Back-End-VM ist ein Fehler aufgetreten.

Erkennung: Netzwerkverbindungsfehler.

Wiederherstellung:

• Stellen Sie mindestens zwei Back-End-VMs in einer Verfügbarkeitsgruppe hinter einem Lastenausgleich bereit.
• Wenn der Verbindungsfehler vorübergehend ist, wird TCP manchmal erfolgreich versuchen, die Nachricht erneut zu senden.
• Implementieren Sie eine Wiederholungsrichtlinie in der Anwendung.
• Für persistente oder nicht vorübergehende Fehler implementieren Sie das Trennschalter-Muster.
• Überschreitet die aufrufende VM ihren Netzwerk-Ausgangsgrenzwert, füllt sich die ausgehende Warteschlange. Wenn die ausgehende Warteschlange beständig voll ist, sollten Sie eine horizontale Skalierung in Betracht ziehen.

Diagnose: Protokollieren Sie Ereignisse an den Dienstgrenzen.

Eine VM-Instanz steht nicht mehr zur Verfügung oder ist fehlerhaft.

Erkennung: Konfigurieren Sie einen Load Balancer-Integritätstest, der angibt, ob die VM-Instanz fehlerfrei ist. Der Test sollte überprüfen, ob wichtige Funktionen ordnungsgemäß reagieren.

Wiederherstellen. Stellen Sie für jede Anwendungsschicht mehrere VM-Instanzen in dieselbe Verfügbarkeitsgruppe, und platzieren Sie einen Lastenausgleich vor den virtuellen Computern. Wenn beim Integritätstest ein Fehler auftritt, beendet der Load Balancer das Senden neuer Verbindungen an die fehlerhafte Instanz.

Diagnose: Verwenden Sie die Load Balancer-Protokollanalysen.

• Konfigurieren Sie Ihr Überwachungssystem so, dass es alle Endpunkte der Gesundheitsüberwachung prüft.

Der Operator fährt versehentlich einen virtuellen Computer herunter.

Erkennung: N/V

Wiederherstellen. Legen Sie eine Ressourcensperre mit der Stufe ReadOnly fest. Weitere Informationen finden Sie unter Sperren von Ressourcen mit Azure Resource Manager.

Diagnose: Verwenden Sie Azure-Aktivitätsprotokolle.

Nächste Schritte

Siehe Identifizieren von Abhängigkeiten im Azure Well-Architected Framework. Das Integrieren von Wiederherstellung nach Fehlern in das System sollte von Anfang an Teil der Architektur- und Entwurfsphasen sein, um das Risiko eines Ausfalls zu vermeiden.