Udostępnij za pośrednictwem

Analiza trybu awarii dla aplikacji platformy Azure

  • Artykuł

Analiza trybu awarii (FMA) to proces tworzenia odporności w systemie przez zidentyfikowanie możliwych punktów awarii w systemie. Moduł FMA powinien być częścią faz architektury i projektowania, dzięki czemu można utworzyć odzyskiwanie po awarii w systemie od początku.

Oto ogólny proces przeprowadzania FMA:

  1. Zidentyfikuj wszystkie składniki w systemie. Uwzględnij zależności zewnętrzne, takie jak dostawcy tożsamości, usługi innych firm itd.

  2. Dla każdego składnika zidentyfikuj potencjalne błędy, które mogą wystąpić. Jeden składnik może mieć więcej niż jeden tryb awarii. Na przykład należy rozważyć oddzielne błędy odczytu i błędy zapisu, ponieważ wpływ i możliwe kroki zaradcze będą inne.

  3. Oceń każdy tryb awarii zgodnie z ogólnym ryzykiem. Rozważ następujące czynniki:

    • Jakie jest prawdopodobieństwo awarii. Czy jest to stosunkowo powszechne? Niezwykle rzadkie? Nie potrzebujesz dokładnych liczb; celem jest ułatwienie rangi priorytetu.
    • Jaki jest wpływ na aplikację, pod względem dostępności, utraty danych, kosztów pieniężnych i zakłóceń w działalności biznesowej?

  4. Dla każdego trybu awarii określ, jak aplikacja będzie reagować i odzyskiwać. Rozważ kompromisy w kosztach i złożoności aplikacji.

Jako punkt wyjścia dla procesu FMA ten artykuł zawiera wykaz potencjalnych trybów awarii i ich kroków ograniczania ryzyka. Wykaz jest zorganizowany według technologii lub usługi platformy Azure oraz ogólnej kategorii projektowania na poziomie aplikacji. Wykaz nie jest wyczerpujący, ale obejmuje wiele podstawowych usług platformy Azure.

Uwaga

Błędy powinny być rozróżniane od błędów. Awaria jest nieoczekiwanym zdarzeniem w systemie, które uniemożliwia kontynuowanie normalnego działania. Na przykład awaria sprzętowa, która powoduje awarię partycji sieciowej, jest awarią. Zazwyczaj awarie wymagają interwencji lub konkretnego projektu dla tej klasy błędów. Natomiast błędy są oczekiwaną częścią normalnych operacji, są traktowane natychmiast, a system będzie nadal działać w tej samej pojemności po błędzie. Na przykład błędy wykryte podczas walidacji danych wejściowych można obsłużyć za pomocą logiki biznesowej.

App Service

Aplikacja usługi App Service zostanie zamknięta.

Wykrywanie. Możliwe przyczyny:

  • Oczekiwane zamknięcie

    • Operator zamyka aplikację; na przykład przy użyciu witryny Azure Portal.
    • Aplikacja została zwolniona, ponieważ była bezczynna. (Tylko wtedy, gdy Always On ustawienie jest wyłączone).

  • Nieoczekiwane zamknięcie

    • Aplikacja ulega awarii.
    • Wystąpienie maszyny wirtualnej usługi App Service stanie się niedostępne.

Application_End rejestrowanie przechwyci zamknięcie domeny aplikacji (awaria procesu miękkiego) i jest jedynym sposobem przechwytywania zamykania domeny aplikacji.

Odzyskiwanie:

  • Jeśli zamknięcie było oczekiwane, użyj zdarzenia zamknięcia aplikacji, aby bezpiecznie zamknąć. Na przykład w ASP.NET użyj Application_End metody .
  • Jeśli aplikacja została zwolniona podczas bezczynności, zostanie ona automatycznie uruchomiona ponownie w następnym żądaniu. Jednak poniesiesz koszt "zimny start".
  • Aby zapobiec zwalnianiu aplikacji podczas bezczynności, włącz Always On ustawienie w aplikacji internetowej. Zobacz Konfigurowanie aplikacji internetowych w usłudze aplikacja systemu Azure.
  • Aby uniemożliwić operatorowi zamknięcie aplikacji, ustaw blokadę zasobu na ReadOnly poziomie. Zobacz Blokowanie zasobów za pomocą usługi Azure Resource Manager.
  • Jeśli aplikacja ulegnie awarii lub maszyna wirtualna usługi App Service stanie się niedostępna, usługa App Service automatycznie ponownie uruchomi aplikację.

Diagnostyka. Dzienniki aplikacji i dzienniki serwera internetowego. Zobacz Włączanie rejestrowania diagnostycznego dla aplikacji internetowych w usłudze aplikacja systemu Azure Service.

Określony użytkownik wielokrotnie wysyła nieprawidłowe żądania lub przeciąża system.

Wykrywanie. Uwierzytelnianie użytkowników i dołączanie identyfikatora użytkownika w dziennikach aplikacji.

Odzyskiwanie:

Diagnostyka. Rejestruje wszystkie żądania uwierzytelniania.

Wdrożono nieprawidłową aktualizację.

Wykrywanie. Monitorowanie kondycji aplikacji za pośrednictwem witryny Azure Portal (zobacz Monitorowanie wydajności aplikacji internetowej platformy Azure) lub implementowanie wzorca monitorowania punktu końcowego kondycji.

Odzyskiwanie:. Użyj wielu miejsc wdrożenia i wycofaj się do ostatniego znanego dobrego wdrożenia. Aby uzyskać więcej informacji, zobacz Podstawowa aplikacja internetowa.

Microsoft Entra ID

Uwierzytelnianie openID Connect kończy się niepowodzeniem.

Wykrywanie. Możliwe tryby awarii obejmują:

  1. Identyfikator entra firmy Microsoft jest niedostępny lub nie można go uzyskać z powodu problemu z siecią. Przekierowanie do punktu końcowego uwierzytelniania kończy się niepowodzeniem, a oprogramowanie pośredniczące OpenID Connect zgłasza wyjątek.
  2. Dzierżawa firmy Microsoft Entra nie istnieje. Przekierowanie do punktu końcowego uwierzytelniania zwraca kod błędu HTTP, a oprogramowanie pośredniczące OpenID Connect zgłasza wyjątek.
  3. Użytkownik nie może uwierzytelnić się. Nie jest wymagana żadna strategia wykrywania; Identyfikator Entra firmy Microsoft obsługuje błędy logowania.

Odzyskiwanie:

  1. Przechwyć nieobsługiwane wyjątki z oprogramowania pośredniczącego.
  2. Obsługa AuthenticationFailed zdarzeń.
  3. Przekieruj użytkownika na stronę błędu.
  4. Użytkownik ponawia próbę.

Zapisywanie danych w usłudze Azure Search kończy się niepowodzeniem.

Wykrywanie. Przechwyć Microsoft.Rest.Azure.CloudException błędy.

Odzyskiwanie:

Zestaw SDK wyszukiwania platformy .NET automatycznie ponawia próbę po przejściowych niepowodzeniach. Wszelkie wyjątki zgłaszane przez zestaw SDK klienta powinny być traktowane jako nieprzejerzane błędy.

Domyślne zasady ponawiania prób używają wycofywania wykładniczego. Aby użyć innych zasad ponawiania, wywołaj SetRetryPolicy metodę SearchIndexClient lub SearchServiceClient . Aby uzyskać więcej informacji, zobacz Automatyczne ponawianie prób.

Diagnostyka. Użyj analizy ruchu wyszukiwania.

Odczytywanie danych z usługi Azure Search kończy się niepowodzeniem.

Wykrywanie. Przechwyć Microsoft.Rest.Azure.CloudException błędy.

Odzyskiwanie:

Zestaw SDK wyszukiwania platformy .NET automatycznie ponawia próbę po przejściowych niepowodzeniach. Wszelkie wyjątki zgłaszane przez zestaw SDK klienta powinny być traktowane jako nieprzejerzane błędy.

Domyślne zasady ponawiania prób używają wycofywania wykładniczego. Aby użyć innych zasad ponawiania, wywołaj SetRetryPolicy metodę SearchIndexClient lub SearchServiceClient . Aby uzyskać więcej informacji, zobacz Automatyczne ponawianie prób.

Diagnostyka. Użyj analizy ruchu wyszukiwania.

Cassandra

Odczytywanie lub zapisywanie w węźle kończy się niepowodzeniem.

Wykrywanie. Przechwyć wyjątek. W przypadku klientów platformy .NET zazwyczaj będzie System.Web.HttpExceptionto . Inny klient może mieć inne typy wyjątków. Aby uzyskać więcej informacji, zobacz Obsługa błędów rozwiązania Cassandra wykonana prawidłowo.

Odzyskiwanie:

  • Każdy klient Cassandra ma własne zasady i możliwości ponawiania prób. Aby uzyskać więcej informacji, zobacz Obsługa błędów rozwiązania Cassandra wykonana prawidłowo.
  • Użyj wdrożenia obsługującego stojak, z węzłami danych dystrybuowanymi między domenami błędów.
  • Wdrażanie w wielu regionach przy użyciu spójności kworum lokalnego. Jeśli wystąpi nieprzejrzały błąd, przełączenie w tryb failover do innego regionu.

Diagnostyka. Dzienniki aplikacji

Usługi w chmurze

Role sieci Web lub procesu roboczego są nieoczekiwanie zamykane.

Wykrywanie. Zdarzenie RoleEnvironment.Stopping zostało wyzwolone.

Odzyskiwanie. Zastąpi metodę RoleEntryPoint.OnStop , aby bezpiecznie wyczyścić. Aby uzyskać więcej informacji, zobacz The Right Way to Handle Azure OnStop Events (Blog).

Azure Cosmos DB

Odczytywanie danych kończy się niepowodzeniem.

Wykrywanie. Catch System.Net.Http.HttpRequestException lub Microsoft.Azure.Documents.DocumentClientException.

Odzyskiwanie:

  • Zestaw SDK automatycznie ponawia próby nie powiodły się. Aby ustawić liczbę ponownych prób i maksymalny czas oczekiwania, skonfiguruj wartość ConnectionPolicy.RetryOptions. Wyjątki wywoływane przez klienta wykraczają poza zasady ponawiania lub nie są błędami przejściowymi.
  • Jeśli usługa Azure Cosmos DB ogranicza klienta, zwraca błąd HTTP 429. Sprawdź kod stanu dotyczący elementu DocumentClientException. Jeśli stale występuje błąd 429, rozważ zwiększenie wartości przepływności kolekcji.
    • Jeśli używasz interfejsu API bazy danych MongoDB, usługa zwraca kod błędu 16500 podczas ograniczania przepustowości.
  • Włącz nadmiarowość strefy podczas pracy z regionem obsługującym strefy dostępności. W przypadku korzystania z nadmiarowości strefy usługa Azure Cosmos DB automatycznie przełączy się w tryb failover w przypadku awarii strefy. Aby uzyskać więcej informacji, zobacz Uzyskiwanie wysokiej dostępności za pomocą usługi Azure Cosmos DB.
  • Jeśli projektujesz rozwiązanie z wieloma regionami, zreplikuj bazę danych usługi Azure Cosmos DB w co najmniej dwóch regionach. Wszystkie repliki można odczytać. Przy użyciu zestawów SDK klienta określ PreferredLocations parametr . Jest to uporządkowana lista regionów świadczenia usługi Azure. Wszystkie operacje odczytu zostaną wysłane do pierwszego dostępnego regionu na liście. Jeśli żądanie zakończy się niepowodzeniem, klient spróbuje wykonać inne regiony na liście w kolejności. Aby uzyskać więcej informacji, zobacz Jak skonfigurować dystrybucję globalną w usłudze Azure Cosmos DB for NoSQL.

Diagnostyka. Zarejestruj wszystkie błędy po stronie klienta.

Zapisywanie danych kończy się niepowodzeniem.

Wykrywanie. Catch System.Net.Http.HttpRequestException lub Microsoft.Azure.Documents.DocumentClientException.

Odzyskiwanie:

  • Zestaw SDK automatycznie ponawia próby nie powiodły się. Aby ustawić liczbę ponownych prób i maksymalny czas oczekiwania, skonfiguruj wartość ConnectionPolicy.RetryOptions. Wyjątki wywoływane przez klienta wykraczają poza zasady ponawiania lub nie są błędami przejściowymi.
  • Jeśli usługa Azure Cosmos DB ogranicza klienta, zwraca błąd HTTP 429. Sprawdź kod stanu dotyczący elementu DocumentClientException. Jeśli stale występuje błąd 429, rozważ zwiększenie wartości przepływności kolekcji.
  • Włącz nadmiarowość strefy podczas pracy z regionem obsługującym strefy dostępności. W przypadku korzystania z nadmiarowości strefy usługa Azure Cosmos DB synchronicznie replikuje wszystkie operacje zapisu w strefach dostępności. Aby uzyskać więcej informacji, zobacz Uzyskiwanie wysokiej dostępności za pomocą usługi Azure Cosmos DB.
  • Jeśli projektujesz rozwiązanie z wieloma regionami, zreplikuj bazę danych usługi Azure Cosmos DB w co najmniej dwóch regionach. Jeśli region podstawowy ulegnie awarii, zostanie podwyższony poziom do zapisu w innym regionie. Możesz również ręcznie wyzwolić tryb failover. Zestaw SDK wykonuje automatyczne odnajdywanie i routing, dlatego kod aplikacji nadal działa po przejściu w tryb failover. W okresie pracy w trybie failover (zazwyczaj minuty) operacje zapisu będą miały większe opóźnienie, ponieważ zestaw SDK znajdzie nowy region zapisu. Aby uzyskać więcej informacji, zobacz Jak skonfigurować dystrybucję globalną w usłudze Azure Cosmos DB for NoSQL.
  • Jako rezerwowy utrąć dokument w kolejce kopii zapasowej i przetworzyć kolejkę później.

Diagnostyka. Zarejestruj wszystkie błędy po stronie klienta.

Queue Storage

Spójne zapisywanie komunikatu w usłudze Azure Queue Storage kończy się niepowodzeniem.

Wykrywanie. Po ponowieniu próby N operacja zapisu nadal kończy się niepowodzeniem.

Odzyskiwanie:

  • Zapisz dane w lokalnej pamięci podręcznej i prześlij dalej zapisy do magazynu później, gdy usługa stanie się dostępna.
  • Utwórz kolejkę pomocniczą i zapisz w tej kolejce, jeśli kolejka podstawowa jest niedostępna.

Diagnostyka. Użyj metryk magazynu.

Aplikacja nie może przetworzyć określonego komunikatu z kolejki.

Wykrywanie. Specyficzne dla aplikacji. Na przykład komunikat zawiera nieprawidłowe dane lub logika biznesowa kończy się niepowodzeniem z jakiegoś powodu.

Odzyskiwanie:

Przenieś komunikat do oddzielnej kolejki. Uruchom oddzielny proces, aby zbadać komunikaty w tej kolejce.

Rozważ użycie kolejek komunikatów usługi Azure Service Bus, które w tym celu udostępniają funkcję kolejki utraconych komunikatów.

Uwaga

Jeśli używasz kolejek usługi Storage z zadaniami WebJob, zestaw SDK usługi WebJobs zapewnia wbudowaną obsługę zatrutych komunikatów. Zobacz How to use Azure Queue Storage with the WebJobs SDK (Jak używać usługi Azure Queue Storage z zestawem SDK usługi WebJobs).

Diagnostyka. Użyj rejestrowania aplikacji.

Azure Cache for Redis

Odczyt z pamięci podręcznej kończy się niepowodzeniem.

Wykrywanie. Przechwyć StackExchange.Redis.RedisConnectionException.

Odzyskiwanie:

  1. Ponów próbę w przypadku błędów przejściowych. Usługa Azure Cache for Redis obsługuje wbudowane ponawianie prób. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące ponawiania prób usługi Azure Cache for Redis.
  2. Traktuj nieprzejrzane błędy jako chybienie pamięci podręcznej i wracaj do oryginalnego źródła danych.

Diagnostyka. Użyj diagnostyki usługi Azure Cache for Redis.

Zapisywanie w pamięci podręcznej kończy się niepowodzeniem.

Wykrywanie. Przechwyć StackExchange.Redis.RedisConnectionException.

Odzyskiwanie:

  1. Ponów próbę w przypadku błędów przejściowych. Usługa Azure Cache for Redis obsługuje wbudowane ponawianie prób. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące ponawiania prób usługi Azure Cache for Redis.
  2. Jeśli błąd jest nieprzejrzały, zignoruj go i pozwól innym transakcjom zapisywać w pamięci podręcznej później.

Diagnostyka. Użyj diagnostyki usługi Azure Cache for Redis.

SQL Database

Nie można nawiązać połączenia z bazą danych w regionie podstawowym.

Wykrywanie. Połączenie kończy się niepowodzeniem.

Odzyskiwanie:

  • Włącz nadmiarowość strefy. Dzięki włączeniu nadmiarowości strefy usługa Azure SQL Database automatycznie replikuje zapisy w wielu strefach dostępności platformy Azure w obsługiwanych regionach. Aby uzyskać więcej informacji, zobacz Dostępność strefowo nadmiarowa.

  • Włącz replikację geograficzną. Jeśli projektujesz rozwiązanie z wieloma regionami, rozważ włączenie aktywnej replikacji geograficznej usługi SQL Database.

    Wymaganie wstępne: baza danych musi być skonfigurowana do aktywnej replikacji geograficznej. Zobacz Aktywna replikacja geograficzna usługi SQL Database.

    Replika używa innego parametry połączenia, dlatego należy zaktualizować parametry połączenia w aplikacji.

Klient kończy połączenia w puli połączeń.

Wykrywanie. Przechwyć System.InvalidOperationException błędy.

Odzyskiwanie:

  • Spróbuj ponownie wykonać operację.
  • W ramach planu ograniczania ryzyka izoluj pule połączeń dla każdego przypadku użycia, aby jeden przypadek użycia nie mógł zdominować wszystkich połączeń.
  • Zwiększ maksymalną liczbę pul połączeń.

Diagnostyka. Dzienniki aplikacji.

Osiągnięto limit połączeń z bazą danych.

Wykrywanie. Usługa Azure SQL Database ogranicza liczbę współbieżnych procesów roboczych, logowań i sesji. Limity zależą od warstwy usługi. Aby uzyskać więcej informacji, zobacz Limity zasobów usługi Azure SQL Database.

Aby wykryć te błędy, przechwyć System.Data.SqlClient.SqlException i sprawdź wartość SqlException.Number kodu błędu SQL. Aby uzyskać listę odpowiednich kodów błędów, zobacz Kody błędów SQL dla aplikacji klienckich usługi SQL Database: Błąd połączenia z bazą danych i inne problemy.

Odzyskiwanie. Te błędy są uznawane za przejściowe, dlatego ponawianie próby mogą rozwiązać ten problem. Jeśli stale osiągasz te błędy, rozważ skalowanie bazy danych.

Diagnostyka. — Zapytanie sys.event_log zwraca pomyślne połączenia z bazą danych, błędy połączeń i zakleszczenia.

Komunikaty usługi Service Bus

Odczytywanie komunikatu z kolejki usługi Service Bus kończy się niepowodzeniem.

Wykrywanie. Przechwyć wyjątki z zestawu SDK klienta. Klasa podstawowa wyjątków usługi Service Bus to MessagingException. Jeśli błąd jest przejściowy, IsTransient właściwość ma wartość true.

Aby uzyskać więcej informacji, zobacz Wyjątki obsługi komunikatów usługi Service Bus.

Odzyskiwanie:

  1. Ponów próbę w przypadku błędów przejściowych. Zobacz Wskazówki dotyczące ponawiania prób w usłudze Service Bus.
  2. Komunikaty, których nie można dostarczyć do żadnego odbiorcy, są umieszczane w kolejce utraconych komunikatów. Użyj tej kolejki, aby zobaczyć, których komunikatów nie można odebrać. Nie ma automatycznego czyszczenia kolejki utraconych komunikatów. Komunikaty pozostają tam do momentu ich jawnego pobrania. Zobacz Omówienie kolejek utraconych komunikatów usługi Service Bus.

Zapisywanie komunikatu w kolejce usługi Service Bus kończy się niepowodzeniem.

Wykrywanie. Przechwyć wyjątki z zestawu SDK klienta. Klasa podstawowa wyjątków usługi Service Bus to MessagingException. Jeśli błąd jest przejściowy, IsTransient właściwość ma wartość true.

Aby uzyskać więcej informacji, zobacz Wyjątki obsługi komunikatów usługi Service Bus.

Odzyskiwanie:

  • Klient usługi Service Bus automatycznie ponawia próby po błędach przejściowych. Domyślnie używa wycofywania wykładniczego. Po maksymalnej liczbie ponownych prób lub maksymalnym przedziale czasu klient zgłasza wyjątek. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące ponawiania prób w usłudze Service Bus.

  • Jeśli limit przydziału kolejki zostanie przekroczony, klient zgłasza wyjątek QuotaExceededException. Komunikat o wyjątku zawiera więcej szczegółów. Opróżnianie niektórych komunikatów z kolejki przed ponowną próbą i rozważ użycie wzorca wyłącznika, aby uniknąć dalszych ponownych prób podczas przekroczenia limitu przydziału. Upewnij się również, że właściwość BrokeredMessage.TimeToLive nie jest ustawiona zbyt wysoko.

  • W obrębie regionu odporność można poprawić przy użyciu partycjonowanych kolejek lub tematów. Kolejka lub temat bez partycji jest przypisywany do jednego magazynu obsługi komunikatów. Jeśli ten magazyn obsługi komunikatów jest niedostępny, wszystkie operacje w tej kolejce lub temacie zakończy się niepowodzeniem. Partycjonowana kolejka lub temat jest partycjonowana w wielu magazynach obsługi komunikatów.

  • Użyj nadmiarowości strefy, aby automatycznie replikować zmiany między wieloma strefami dostępności. Jeśli jedna strefa dostępności zakończy się niepowodzeniem, tryb failover odbywa się automatycznie. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące izolowania aplikacji przed awariami i awariami usługi Service Bus.

  • Jeśli projektujesz rozwiązanie z wieloma regionami, utwórz dwie przestrzenie nazw usługi Service Bus w różnych regionach i zreplikuj komunikaty. Można użyć aktywnej replikacji lub replikacji pasywnej.

    • Aktywna replikacja: klient wysyła każdy komunikat do obu kolejek. Odbiornik nasłuchuje w obu kolejkach. Tagowanie komunikatów przy użyciu unikatowego identyfikatora, aby klient mógł odrzucić zduplikowane komunikaty.
    • Replikacja pasywna: klient wysyła komunikat do jednej kolejki. Jeśli wystąpi błąd, klient wróci do innej kolejki. Odbiornik nasłuchuje w obu kolejkach. Takie podejście zmniejsza liczbę wysyłanych zduplikowanych komunikatów. Jednak odbiorca musi nadal obsługiwać zduplikowane komunikaty.

    Aby uzyskać więcej informacji, zobacz Przykład georeplikacji i Najlepsze rozwiązania dotyczące izolowania aplikacji przed awariami i awariami usługi Service Bus.

Zduplikowany komunikat.

Wykrywanie. MessageId Sprawdź właściwości i DeliveryCount komunikatu.

Odzyskiwanie:

  • Jeśli to możliwe, zaprojektuj operacje przetwarzania komunikatów jako idempotentne. W przeciwnym razie przechowuj identyfikatory komunikatów, które są już przetwarzane, i sprawdź identyfikator przed przetworzeniem komunikatu.

  • Włącz wykrywanie duplikatów, tworząc kolejkę z ustawioną wartością RequiresDuplicateDetection true. Dzięki temu ustawieniu usługa Service Bus automatycznie usuwa wszystkie komunikaty wysyłane z taką samą MessageId jak poprzednia wiadomość. Należy zwrócić uwagę na następujące kwestie:

    • To ustawienie uniemożliwia umieszczanie zduplikowanych komunikatów w kolejce. Nie uniemożliwia odbiornikowi przetwarzania tego samego komunikatu więcej niż raz.
    • Wykrywanie duplikatów ma przedział czasu. Jeśli duplikat zostanie wysłany poza to okno, nie zostanie wykryty.

Diagnostyka. Rejestruje zduplikowane komunikaty.

Aplikacja nie może przetworzyć określonego komunikatu z kolejki.

Wykrywanie. Specyficzne dla aplikacji. Na przykład komunikat zawiera nieprawidłowe dane lub logika biznesowa kończy się niepowodzeniem z jakiegoś powodu.

Odzyskiwanie:

Istnieją dwa tryby awarii, które należy wziąć pod uwagę.

  • Odbiornik wykrywa błąd. W takim przypadku przenieś komunikat do kolejki utraconych komunikatów. Następnie uruchom oddzielny proces, aby zbadać komunikaty w kolejce utraconych komunikatów.
  • Odbiornik kończy się niepowodzeniem w trakcie przetwarzania komunikatu — na przykład z powodu nieobsługiwanego wyjątku. Aby obsłużyć ten przypadek, użyj PeekLock trybu. W tym trybie, jeśli blokada wygaśnie, komunikat stanie się dostępny dla innych odbiorników. Jeśli komunikat przekracza maksymalną liczbę dostarczania lub czas wygaśnięcia, wiadomość zostanie automatycznie przeniesiona do kolejki utraconych komunikatów.

Aby uzyskać więcej informacji, zobacz Omówienie kolejek utraconych komunikatów usługi Service Bus.

Diagnostyka. Za każdym razem, gdy aplikacja przenosi komunikat do kolejki utraconych komunikatów, zapisz zdarzenie w dziennikach aplikacji.

Storage

Zapisywanie danych w usłudze Azure Storage kończy się niepowodzeniem

Wykrywanie. Klient otrzymuje błędy podczas zapisywania.

Odzyskiwanie:

  1. Spróbuj ponownie wykonać operację, aby odzyskać sprawność po przejściowych błędach. Zasady ponawiania próby w zestawie SDK klienta obsługują to automatycznie.

  2. Zaimplementuj wzorzec wyłącznika, aby uniknąć przytłaczającego magazynu.

  3. Jeśli n ponownych prób nie powiedzie się, wykonaj łaskawy powrót. Na przykład:

    • Zapisz dane w lokalnej pamięci podręcznej i prześlij dalej zapisy do magazynu później, gdy usługa stanie się dostępna.
    • Jeśli akcja zapisu znajdowała się w zakresie transakcyjnym, skompensuj transakcję.

Diagnostyka. Użyj metryk magazynu.

Odczytywanie danych z usługi Azure Storage kończy się niepowodzeniem.

Wykrywanie. Klient otrzymuje błędy podczas odczytywania.

Odzyskiwanie:

  1. Spróbuj ponownie wykonać operację, aby odzyskać sprawność po przejściowych błędach. Zasady ponawiania próby w zestawie SDK klienta obsługują to automatycznie.
  2. W przypadku magazynu RA-GRS w przypadku niepowodzenia odczytu z podstawowego punktu końcowego spróbuj odczytać z pomocniczego punktu końcowego. Zestaw SDK klienta może obsługiwać to automatycznie. Zobacz Replikacja usługi Azure Storage.
  3. Jeśli N ponawianie próby nie powiedzie się, wykonaj akcję rezerwową, aby bezpiecznie obniżyć sprawność. Jeśli na przykład nie można pobrać obrazu produktu z magazynu, pokaż ogólny obraz zastępczy.

Diagnostyka. Użyj metryk magazynu.

Maszyna wirtualna

Połączenie z maszyną wirtualną zaplecza kończy się niepowodzeniem.

Wykrywanie. Błędy połączenia sieciowego.

Odzyskiwanie:

  • Wdróż co najmniej dwie maszyny wirtualne zaplecza w zestawie dostępności za modułem równoważenia obciążenia.
  • Jeśli błąd połączenia jest przejściowy, czasami protokół TCP pomyślnie ponowi próbę wysłania komunikatu.
  • Zaimplementuj zasady ponawiania prób w aplikacji.
  • W przypadku trwałych lub nieprzejaśniających błędów zaimplementuj wzorzec wyłącznika.
  • Jeśli wywołująca maszyna wirtualna przekroczy limit ruchu wychodzącego sieci, kolejka wychodząca zostanie wypełnina. Jeśli kolejka wychodząca jest spójnie pełna, rozważ skalowanie w poziomie.

Diagnostyka. Rejestrowanie zdarzeń na granicach usługi.

Wystąpienie maszyny wirtualnej stanie się niedostępne lub jest w złej kondycji.

Wykrywanie. Skonfiguruj sondę kondycji modułu równoważenia obciążenia, która sygnalizuje, czy wystąpienie maszyny wirtualnej jest w dobrej kondycji. Sonda powinna sprawdzić, czy funkcje krytyczne odpowiadają poprawnie.

Odzyskiwanie. Dla każdej warstwy aplikacji umieść wiele wystąpień maszyn wirtualnych w tym samym zestawie dostępności i umieść moduł równoważenia obciążenia przed maszynami wirtualnymi. Jeśli sonda kondycji nie powiedzie się, moduł równoważenia obciążenia przestanie wysyłać nowe połączenia do wystąpienia w złej kondycji.

Diagnostyka. — Użyj analizy dzienników usługi Load Balancer.

  • Skonfiguruj system monitorowania, aby monitorować wszystkie punkty końcowe monitorowania kondycji.

Operator przypadkowo zamyka maszynę wirtualną.

Wykrywanie. Nie dotyczy

Odzyskiwanie. Ustaw blokadę zasobu z ReadOnly poziomem. Zobacz Blokowanie zasobów za pomocą usługi Azure Resource Manager.

Diagnostyka. Użyj dzienników aktywności platformy Azure.

Zadania WebJob

Zadanie ciągłe przestaje działać, gdy host SCM jest bezczynny.

Wykrywanie. Przekaż token anulowania do funkcji Zadania WebJob. Aby uzyskać więcej informacji, zobacz Graceful shutdown (Graceful shutdown).

Odzyskiwanie. Always On Włącz ustawienie w aplikacji internetowej. Aby uzyskać więcej informacji, zobacz Uruchamianie zadań w tle za pomocą zadań WebJob.

Projekt aplikacji

Aplikacja nie może obsłużyć skoku liczby żądań przychodzących.

Wykrywanie. Zależy od aplikacji. Typowe objawy:

  • Witryna internetowa rozpoczyna zwracanie kodów błędów HTTP 5xx.
  • Usługi zależne, takie jak baza danych lub magazyn, zaczynają ograniczać żądania. Poszukaj błędów HTTP, takich jak HTTP 429 (Zbyt wiele żądań), w zależności od usługi.
  • Rośnie długość kolejki HTTP.

Odzyskiwanie:

  • Skalowanie w poziomie w celu obsługi zwiększonego obciążenia.

  • Zniweluj błędy, aby uniknąć awarii kaskadowych zakłócających działanie całej aplikacji. Strategie ograniczania ryzyka obejmują:

    • Zaimplementuj wzorzec ograniczania przepustowości, aby uniknąć przeciążenia systemów zaplecza.
    • Użyj bilansowania obciążenia opartego na kolejce, aby buforować żądania i przetwarzać je w odpowiednim tempie.
    • Określanie priorytetów niektórych klientów. Jeśli na przykład aplikacja ma warstwy bezpłatne i płatne, ograniczaj klientów w warstwie Bezpłatna, ale nie płacący klienci. Zobacz Wzorzec kolejki priorytetu.

Diagnostyka. Użyj rejestrowania diagnostycznego usługi App Service. Użyj usługi, takiej jak Azure Log Analytics, Application Insights lub New Relic , aby ułatwić zrozumienie dzienników diagnostycznych.

Przykład jest dostępny tutaj. Używa usługi Polly dla tych wyjątków:

  • 429 — Ograniczanie przepustowości
  • 408 — Limit czasu
  • 401 — Brak autoryzacji
  • 503 lub 5xx — usługa jest niedostępna

Jedna z operacji w przepływie pracy lub transakcji rozproszonej kończy się niepowodzeniem.

Wykrywanie. Po ponowieniu próby N nadal kończy się niepowodzeniem.

Odzyskiwanie:

  • W ramach planu ograniczania ryzyka zaimplementuj wzorzec nadzorcy agenta harmonogramu, aby zarządzać całym przepływem pracy.
  • Nie należy ponawiać próby w przypadku przekroczenia limitu czasu. W przypadku tego błędu występuje niski współczynnik powodzenia.
  • Praca w kolejce, aby ponowić próbę później.

Diagnostyka. Zarejestruj wszystkie operacje (zakończone powodzeniem i niepowodzeniem), w tym akcje wyrównywane. Użyj identyfikatorów korelacji, aby można było śledzić wszystkie operacje w ramach tej samej transakcji.

Wywołanie usługi zdalnej kończy się niepowodzeniem.

Wykrywanie. Kod błędu HTTP.

Odzyskiwanie:

  1. Ponów próbę w przypadku błędów przejściowych.
  2. Jeśli wywołanie nie powiedzie się po N próbach, wykonaj akcję rezerwową. (Specyficzne dla aplikacji).
  3. Zaimplementuj wzorzec wyłącznika, aby uniknąć błędów kaskadowych.

Diagnostyka. Zarejestruj wszystkie błędy wywołań zdalnych.

Następne kroki

Zobacz Odporność i zależności w witrynie Azure Well-Architected Framework. Tworzenie odzyskiwania po awarii w systemie powinno być częścią faz architektury i projektowania od początku, aby uniknąć ryzyka awarii.