Dela via

Analys av felläge för Azure-program

  • Artikel

Analys av felläge (FMA) är en process för att skapa återhämtning i ett system genom att identifiera möjliga felpunkter i systemet. FMA bör vara en del av arkitektur- och designfaserna, så att du kan skapa återställning av fel i systemet från början.

Här är den allmänna processen för att genomföra en FMA:

  1. Identifiera alla komponenter i systemet. Inkludera externa beroenden, till exempel identitetsprovidrar, tjänster från tredje part och så vidare.

  2. Identifiera potentiella fel som kan inträffa för varje komponent. En enskild komponent kan ha mer än ett felläge. Du bör till exempel överväga läsfel och skrivfel separat, eftersom påverkan och möjliga åtgärdssteg skiljer sig åt.

  3. Betygsätt varje felläge enligt dess övergripande risk. Tänk på följande faktorer:

    • Vad är sannolikheten för felet. Är det relativt vanligt? Extremt sällsynt? Du behöver inte exakta tal. syftet är att hjälpa till att rangordna prioriteten.
    • Vad påverkar programmet när det gäller tillgänglighet, dataförlust, ekonomiska kostnader och avbrott i verksamheten?

  4. För varje felläge bestämmer du hur programmet ska svara och återställa. Överväg att kompromissa med kostnads- och programkomplexitet.

Som utgångspunkt för FMA-processen innehåller den här artikeln en katalog över möjliga fellägen och deras åtgärdssteg. Katalogen organiseras efter teknik eller Azure-tjänst, plus en allmän kategori för design på programnivå. Katalogen är inte fullständig, men omfattar många av de grundläggande Azure-tjänsterna.

App Service

App Service-appen stängs av.

Identifiering. Möjliga orsaker:

  • Förväntad avstängning

    • En operator stänger av programmet. till exempel med hjälp av Azure-portalen.
    • Appen togs bort eftersom den var inaktiv. (Endast om inställningen Always On är inaktiverad.)

  • Oväntad avstängning

    • Appen kraschar.
    • En instans av en virtuell App Service-dator blir inte tillgänglig.

Application_End loggning kommer att fånga appdomänavstängningen (mjuk processkrasch) och är det enda sättet att fånga programdomänavstängningarna.

Återhämtning:

  • Om avstängningen förväntades använder du programmets avstängningshändelse för att stänga av korrekt. Använd till exempel metoden i ASP.NET Application_End .
  • Om programmet togs bort när det var inaktivt startas det automatiskt om vid nästa begäran. Du ådrar dig dock kostnaden för "kallstart".
  • Om du vill förhindra att programmet tas bort när det är inaktivt aktiverar du Always On inställningen i webbappen. Se Konfigurera webbappar i Azure App Service.
  • Om du vill förhindra att en operatör stänger av appen anger du ett resurslås med ReadOnly nivå. Se Låsa resurser med Azure Resource Manager.
  • Om appen kraschar eller en virtuell App Service-dator blir otillgänglig startar App Service automatiskt om appen.

Diagnostik. Programloggar och webbserverloggar. Se Aktivera diagnostikloggning för webbappar i Azure App Service.

En viss användare gör upprepade gånger felaktiga begäranden eller överbelastar systemet.

Identifiering. Autentisera användare och inkludera användar-ID i programloggar.

Återhämtning:

Diagnostik. Logga alla autentiseringsbegäranden.

En felaktig uppdatering har distribuerats.

Identifiering. Övervaka programmets hälsotillstånd via Azure-portalen (se Övervaka prestanda för Azure-webbappar) eller implementera övervakningsmönstret för hälsoslutpunkter.

Återställning:. Använd flera distributionsfack och återställ till den senast kända distributionen. Mer information finns i Grundläggande webbprogram.

Microsoft Entra ID

OpenID-Anslut autentisering misslyckas.

Identifiering. Möjliga fellägen är:

  1. Microsoft Entra-ID är inte tillgängligt eller kan inte nås på grund av ett nätverksproblem. Omdirigeringen till autentiseringsslutpunkten misslyckas och OpenID-Anslut mellanprogram genererar ett undantag.
  2. Microsoft Entra-klientorganisationen finns inte. Omdirigering till autentiseringsslutpunkten returnerar en HTTP-felkod och OpenID-Anslut mellanprogram genererar ett undantag.
  3. Användaren kan inte autentisera. Ingen identifieringsstrategi krävs. Microsoft Entra-ID hanterar inloggningsfel.

Återhämtning:

  1. Fånga ohanterade undantag från mellanprogrammet.
  2. Hantera AuthenticationFailed händelser.
  3. Omdirigera användaren till en felsida.
  4. Användaren försöker igen.

Det går inte att skriva data till Azure Search.

Identifiering. Fånga Microsoft.Rest.Azure.CloudException fel.

Återhämtning:

Search .NET SDK försöker automatiskt igen efter tillfälliga fel. Eventuella undantag som genereras av klient-SDK:t ska behandlas som icke-övergående fel.

Standardprincipen för återförsök använder exponentiell säkerhetskopiering. Om du vill använda en annan återförsöksprincip anropar du SetRetryPolicy SearchIndexClient klassen eller SearchServiceClient . Mer information finns i Automatiska återförsök.

Diagnostik. Använd Search Traffic Analytics.

Det går inte att läsa data från Azure Search.

Identifiering. Fånga Microsoft.Rest.Azure.CloudException fel.

Återhämtning:

Search .NET SDK försöker automatiskt igen efter tillfälliga fel. Eventuella undantag som genereras av klient-SDK:t ska behandlas som icke-övergående fel.

Standardprincipen för återförsök använder exponentiell säkerhetskopiering. Om du vill använda en annan återförsöksprincip anropar du SetRetryPolicy SearchIndexClient klassen eller SearchServiceClient . Mer information finns i Automatiska återförsök.

Diagnostik. Använd Search Traffic Analytics.

Cassandra

Det går inte att läsa eller skriva till en nod.

Identifiering. Fånga undantaget. För .NET-klienter är System.Web.HttpExceptiondetta vanligtvis . Andra klienter kan ha andra undantagstyper. Mer information finns i Felhantering av Cassandra som har utförts på rätt sätt.

Återhämtning:

  • Varje Cassandra-klient har sina egna återförsöksprinciper och funktioner. Mer information finns i Felhantering av Cassandra som har utförts på rätt sätt.
  • Använd en rackmedveten distribution med datanoder fördelade över feldomänerna.
  • Distribuera till flera regioner med lokal kvorumkonsekvens. Om ett icke-tillfälligt fel inträffar redundansväxlar du till en annan region.

Diagnostik. Programloggar

Molntjänst

Webb- eller arbetsroller stängs oväntat av.

Identifiering. Händelsen RoleEnvironment.Stop utlöses.

Återställning. Åsidosätt metoden RoleEntryPoint.OnStop för att rensa korrekt. Mer information finns i Rätt sätt att hantera Azure OnStop-händelser (blogg).

Azure Cosmos DB

Det går inte att läsa data.

Identifiering. Fånga System.Net.Http.HttpRequestException eller Microsoft.Azure.Documents.DocumentClientException.

Återhämtning:

  • SDK:et försöker automatiskt igen misslyckade försök. Om du vill ange antalet återförsök och den maximala väntetiden konfigurerar du ConnectionPolicy.RetryOptions. Undantag som klienten aktiverar ligger utanför återförsöksprincipen eller är inte tillfälliga fel.
  • Om Azure Cosmos DB begränsar klienten returneras ett HTTP 429-fel. Kontrollera statuskoden i DocumentClientException. Om du får fel 429 konsekvent kan du överväga att öka dataflödesvärdet för samlingen.
    • Om du använder MongoDB-API:et returnerar tjänsten felkoden 16500 vid begränsning.
  • Aktivera zonredundans när du arbetar med en region som stöder tillgänglighetszoner. När du använder zonredundans redundans redundansväxlar Azure Cosmos DB automatiskt i händelse av ett zonfel. Mer information finns i Uppnå hög tillgänglighet med Azure Cosmos DB.
  • Om du utformar en lösning för flera regioner replikerar du Azure Cosmos DB-databasen i två eller flera regioner. Alla repliker är läsbara. Ange parametern med hjälp av klient-SDK:erna PreferredLocations . Det här är en ordnad lista över Azure-regioner. Alla läsningar skickas till den första tillgängliga regionen i listan. Om begäran misslyckas provar klienten de andra regionerna i listan i ordning. Mer information finns i Konfigurera global distribution i Azure Cosmos DB för NoSQL.

Diagnostik. Logga alla fel på klientsidan.

Det går inte att skriva data.

Identifiering. Fånga System.Net.Http.HttpRequestException eller Microsoft.Azure.Documents.DocumentClientException.

Återhämtning:

  • SDK:et försöker automatiskt igen misslyckade försök. Om du vill ange antalet återförsök och den maximala väntetiden konfigurerar du ConnectionPolicy.RetryOptions. Undantag som klienten aktiverar ligger utanför återförsöksprincipen eller är inte tillfälliga fel.
  • Om Azure Cosmos DB begränsar klienten returneras ett HTTP 429-fel. Kontrollera statuskoden i DocumentClientException. Om du får fel 429 konsekvent kan du överväga att öka dataflödesvärdet för samlingen.
  • Aktivera zonredundans när du arbetar med en region som stöder tillgänglighetszoner. När du använder zonredundans replikerar Azure Cosmos DB synkront alla skrivningar mellan tillgänglighetszoner. Mer information finns i Uppnå hög tillgänglighet med Azure Cosmos DB.
  • Om du utformar en lösning för flera regioner replikerar du Azure Cosmos DB-databasen i två eller flera regioner. Om den primära regionen misslyckas befordras en annan region till skrivning. Du kan också utlösa en redundansväxling manuellt. SDK:et gör automatisk identifiering och routning, så programkoden fortsätter att fungera efter en redundansväxling. Under redundansperioden (vanligtvis minuter) får skrivåtgärder högre svarstid, eftersom SDK:n hittar den nya skrivregionen. Mer information finns i Konfigurera global distribution i Azure Cosmos DB för NoSQL.
  • Som reserv sparar du dokumentet i en säkerhetskopieringskö och bearbetar kön senare.

Diagnostik. Logga alla fel på klientsidan.

Queue Storage

Det går inte att skriva ett meddelande till Azure Queue Storage konsekvent.

Identifiering. När N försöker igen misslyckas fortfarande skrivåtgärden.

Återhämtning:

  • Lagra data i en lokal cache och vidarebefordra skrivningar till lagring senare när tjänsten blir tillgänglig.
  • Skapa en sekundär kö och skriv till den kön om den primära kön inte är tillgänglig.

Diagnostik. Använd lagringsmått.

Programmet kan inte bearbeta ett visst meddelande från kön.

Identifiering. Programspecifikt. Meddelandet innehåller till exempel ogiltiga data, eller så misslyckas affärslogiken av någon anledning.

Återhämtning:

Flytta meddelandet till en separat kö. Kör en separat process för att undersöka meddelandena i kön.

Överväg att använda Azure Service Bus Messaging-köer, som tillhandahåller en köfunktion med obeställbara meddelanden för detta ändamål.

Kommentar

Om du använder Lagringsköer med WebJobs tillhandahåller WebJobs SDK inbyggd hantering av giftmeddelanden. Se Så här använder du Azure Queue Storage med WebJobs SDK.

Diagnostik. Använd programloggning.

Azure Cache for Redis

Det går inte att läsa från cachen.

Identifiering. Fånga StackExchange.Redis.RedisConnectionException.

Återhämtning:

  1. Försök igen vid tillfälliga fel. Azure Cache for Redis har stöd för inbyggda återförsök. Mer information finns i Riktlinjer för återförsök i Azure Cache for Redis.
  2. Behandla icke-övergående fel som en cachemiss och återgå till den ursprungliga datakällan.

Diagnostik. Använd Azure Cache for Redis-diagnostik.

Det går inte att skriva till cachen.

Identifiering. Fånga StackExchange.Redis.RedisConnectionException.

Återhämtning:

  1. Försök igen vid tillfälliga fel. Azure Cache for Redis har stöd för inbyggda återförsök. Mer information finns i Riktlinjer för återförsök i Azure Cache for Redis.
  2. Om felet inte är tillfälligt ignorerar du det och låter andra transaktioner skriva till cacheminnet senare.

Diagnostik. Använd Azure Cache for Redis-diagnostik.

SQL Database

Det går inte att ansluta till databasen i den primära regionen.

Identifiering. Anslut ion misslyckas.

Återhämtning:

  • Aktivera zonredundans. Genom att aktivera zonredundans replikerar Azure SQL Database automatiskt dina skrivningar över flera Azure-tillgänglighetszoner i regioner som stöds. Mer information finns i Zonredundant tillgänglighet.

  • Aktivera geo-replikering. Om du utformar en lösning för flera regioner bör du överväga att aktivera aktiv geo-replikering i SQL Database.

    Krav: Databasen måste konfigureras för aktiv geo-replikering. Se SQL Database Active Geo-Replication.

    Repliken använder en annan anslutningssträng, så du måste uppdatera anslutningssträng i programmet.

Klienten får slut på anslutningar i anslutningspoolen.

Identifiering. Fånga System.InvalidOperationException fel.

Återhämtning:

  • Försök att utföra åtgärden igen.
  • Som en åtgärdsplan isolerar du anslutningspoolerna för varje användningsfall, så att ett användningsfall inte kan dominera alla anslutningar.
  • Öka maximalt antal anslutningspooler.

Diagnostik. Programloggar.

Gränsen för databasanslutning har nåtts.

Identifiering. Azure SQL Database begränsar antalet samtidiga arbetare, inloggningar och sessioner. Gränserna beror på tjänstnivån. Mer information finns i Resursbegränsningar för Azure SQL Database.

Om du vill identifiera dessa fel fångar System.Data.SqlClient.SqlException du upp och kontrollerar värdet SqlException.Number för sql-felkoden. En lista över relevanta felkoder finns i SQL-felkoder för SQL Database-klientprogram: Databasanslutningsfel och andra problem.

Återställning. Dessa fel anses vara tillfälliga, så omförsök kan lösa problemet. Om du konsekvent stöter på dessa fel kan du överväga att skala databasen.

Diagnostik. – Den sys.event_log frågan returnerar lyckade databasanslutningar, anslutningsfel och dödlägen.

Service Bus-meddelanden

Det går inte att läsa ett meddelande från en Service Bus-kö.

Identifiering. Fånga undantag från klient-SDK: et. Basklassen för Service Bus-undantag är MessagingException. Om felet är tillfälligt är egenskapen IsTransient sann.

Mer information finns i Undantag för Service Bus-meddelanden.

Återhämtning:

  1. Försök igen vid tillfälliga fel. Se Riktlinjer för återförsök i Service Bus.
  2. Meddelanden som inte kan levereras till någon mottagare placeras i en kö med obeställbara meddelanden. Använd den här kön om du vill se vilka meddelanden som inte kunde tas emot. Det finns ingen automatisk rensning av kön med obeställbara meddelanden. Meddelanden finns kvar tills du uttryckligen hämtar dem. Se Översikt över Service Bus-köer med obeställbara meddelanden.

Det går inte att skriva ett meddelande till en Service Bus-kö.

Identifiering. Fånga undantag från klient-SDK: et. Basklassen för Service Bus-undantag är MessagingException. Om felet är tillfälligt är egenskapen IsTransient sann.

Mer information finns i Undantag för Service Bus-meddelanden.

Återhämtning:

  • Service Bus-klienten försöker automatiskt igen efter tillfälliga fel. Som standard använder den exponentiell säkerhetskopiering. Efter det maximala antalet återförsök eller den maximala tidsgränsen utlöser klienten ett undantag. Mer information finns i Riktlinjer för återförsök i Service Bus.

  • Om kökvoten överskrids genererar klienten QuotaExceededException. Undantagsmeddelandet innehåller mer information. Töm vissa meddelanden från kön innan du försöker igen och överväg att använda kretsbrytarmönstret för att undvika fortsatta återförsök medan kvoten överskrids. Kontrollera också att egenskapen BrokeredMessage.TimeToLive inte är för hög.

  • Inom en region kan återhämtning förbättras med hjälp av partitionerade köer eller ämnen. En icke-partitionerad kö eller ett ämne tilldelas till ett meddelandearkiv. Om det här meddelandearkivet inte är tillgängligt misslyckas alla åtgärder i kön eller ämnet. En partitionerad kö eller ett ämne partitioneras i flera meddelandearkiv.

  • Använd zonredundans för att automatiskt replikera ändringar mellan flera tillgänglighetszoner. Om en tillgänglighetszon misslyckas sker redundans automatiskt. Mer information finns i Metodtips för att isolera program mot Service Bus-avbrott och katastrofer.

  • Om du utformar en lösning för flera regioner skapar du två Service Bus-namnområden i olika regioner och replikerar meddelandena. Du kan använda antingen aktiv replikering eller passiv replikering.

    • Aktiv replikering: Klienten skickar varje meddelande till båda köerna. Mottagaren lyssnar på båda köerna. Tagga meddelanden med en unik identifierare så att klienten kan ta bort dubblettmeddelanden.
    • Passiv replikering: Klienten skickar meddelandet till en kö. Om det uppstår ett fel återgår klienten till den andra kön. Mottagaren lyssnar på båda köerna. Den här metoden minskar antalet duplicerade meddelanden som skickas. Mottagaren måste dock fortfarande hantera duplicerade meddelanden.

    Mer information finns i GeoReplication-exempel och Metodtips för att isolera program mot Service Bus-avbrott och katastrofer.

Duplicera meddelande.

Identifiering. MessageId Granska egenskaperna och DeliveryCount för meddelandet.

Återhämtning:

  • Utforma om möjligt dina meddelandebearbetningsåtgärder så att de är idempotent. Annars lagrar du meddelande-ID:t för meddelanden som redan har bearbetats och kontrollerar ID:t innan du bearbetar ett meddelande.

  • Aktivera dubblettidentifiering genom att skapa kön med RequiresDuplicateDetection värdet true. Med den här inställningen tar Service Bus automatiskt bort alla meddelanden som skickas med samma MessageId som ett tidigare meddelande. Notera följande:

    • Den här inställningen förhindrar att dubbletter av meddelanden placeras i kön. Det hindrar inte en mottagare från att bearbeta samma meddelande mer än en gång.
    • Dubblettidentifiering har ett tidsfönster. Om en dubblett skickas utanför det här fönstret identifieras den inte.

Diagnostik. Logga duplicerade meddelanden.

Programmet kan inte bearbeta ett visst meddelande från kön.

Identifiering. Programspecifikt. Meddelandet innehåller till exempel ogiltiga data, eller så misslyckas affärslogiken av någon anledning.

Återhämtning:

Det finns två fellägen att tänka på.

  • Mottagaren identifierar felet. I det här fallet flyttar du meddelandet till kön med obeställbara meddelanden. Kör senare en separat process för att undersöka meddelandena i kön med obeställbara meddelanden.
  • Mottagaren misslyckas mitt i bearbetningen av meddelandet, till exempel på grund av ett ohanterat undantag. Använd läge för att hantera det här fallet PeekLock . Om låset upphör att gälla i det här läget blir meddelandet tillgängligt för andra mottagare. Om meddelandet överskrider det maximala leveransantalet eller time-to-live flyttas meddelandet automatiskt till kön med obeställbara meddelanden.

Mer information finns i Översikt över Service Bus-köer med obeställbara meddelanden.

Diagnostik. När programmet flyttar ett meddelande till kön med obeställbara meddelanden skriver du en händelse till programloggarna.

Lagring

Det går inte att skriva data till Azure Storage

Identifiering. Klienten får fel när den skrivs.

Återhämtning:

  1. Försök igen för att återställa från tillfälliga fel. Återförsöksprincipen i klient-SDK hanterar detta automatiskt.

  2. Implementera kretsbrytarmönstret för att undvika överväldigande lagring.

  3. Om N försöker igen misslyckas utför du en graciös återställning. Till exempel:

    • Lagra data i en lokal cache och vidarebefordra skrivningar till lagring senare när tjänsten blir tillgänglig.
    • Om skrivåtgärden fanns i ett transaktionsomfång kompenserar du transaktionen.

Diagnostik. Använd lagringsmått.

Det går inte att läsa data från Azure Storage.

Identifiering. Klienten får fel vid läsning.

Återhämtning:

  1. Försök igen för att återställa från tillfälliga fel. Återförsöksprincipen i klient-SDK hanterar detta automatiskt.
  2. Om det inte går att läsa från den primära slutpunkten för RA-GRS-lagring kan du prova att läsa från den sekundära slutpunkten. Klient-SDK kan hantera detta automatiskt. Se Azure Storage-replikering.
  3. Om N försöker igen misslyckas kan du vidta en återställningsåtgärd för att försämras på ett korrekt sätt. Om en produktbild till exempel inte kan hämtas från lagringen visar du en allmän platshållarbild.

Diagnostik. Använd lagringsmått.

Virtuell maskin

Anslut till en virtuell serverdelsdator misslyckas.

Identifiering. Nätverksanslutningsfel.

Återhämtning:

  • Distribuera minst två virtuella serverdelsdatorer i en tillgänglighetsuppsättning bakom en lastbalanserare.
  • Om anslutningsfelet är tillfälligt försöker TCP ibland skicka meddelandet igen.
  • Implementera en återförsöksprincip i programmet.
  • För beständiga eller icke-övergående fel implementerar du kretsbrytarmönstret .
  • Om den anropande virtuella datorn överskrider gränsen för nätverksutgående trafik fylls den utgående kön. Om den utgående kön är konsekvent full kan du överväga att skala ut.

Diagnostik. Logga händelser vid tjänstens gränser.

Vm-instansen blir otillgänglig eller är inte felfri.

Identifiering. Konfigurera en Load Balancer-hälsoavsökning som signalerar om den virtuella datorinstansen är felfri. Avsökningen bör kontrollera om kritiska funktioner svarar korrekt.

Återställning. För varje programnivå placerar du flera VM-instanser i samma tillgänglighetsuppsättning och placerar en lastbalanserare framför de virtuella datorerna. Om hälsoavsökningen misslyckas slutar Lastbalanseraren att skicka nya anslutningar till den felaktiga instansen.

Diagnostik. – Använd Logganalys för Load Balancer.

  • Konfigurera övervakningssystemet för att övervaka alla slutpunkter för hälsoövervakning.

Operatorn stänger av en virtuell dator av misstag.

Identifiering. Ej tillämpligt

Återställning. Ange ett resurslås med ReadOnly nivå. Se Låsa resurser med Azure Resource Manager.

Diagnostik. Använd Azure-aktivitetsloggar.

WebJobs

Kontinuerliga jobb slutar köras när SCM-värden är inaktiv.

Identifiering. Skicka en annulleringstoken till webbjobbsfunktionen. Mer information finns i Graciös avstängning.

Återställning. Aktivera inställningen Always On i webbappen. Mer information finns i Köra bakgrundsaktiviteter med webbjobb.

Programdesign

Programmet kan inte hantera en topp i inkommande begäranden.

Identifiering. Beror på programmet. Vanliga symtom:

  • Webbplatsen börjar returnera HTTP 5xx-felkoder.
  • Beroende tjänster, till exempel databas eller lagring, börjar begränsa begäranden. Leta efter HTTP-fel som HTTP 429 (för många begäranden), beroende på tjänsten.
  • HTTP-kölängden växer.

Återhämtning:

  • Skala ut för att hantera ökad belastning.

  • Minimera fel för att undvika sammanhängande fel som stör hela programmet. Åtgärdsstrategier omfattar:

    • Implementera begränsningsmönstret för att undvika överväldigande serverdelssystem.
    • Använd köbaserad belastningsutjämning för att buffringsbegäranden och bearbeta dem i lämplig takt.
    • Prioritera vissa klienter. Om programmet till exempel har kostnadsfria och betalda nivåer begränsar du kunder på den kostnadsfria nivån, men inte betalda kunder. Se Mönster för prioritetskö.

Diagnostik. Använd Diagnostikloggning för App Service. Använd en tjänst som Azure Log Analytics, Application Insights eller New Relic för att förstå diagnostikloggarna.

Ett exempel finns här. Den använder Polly för följande undantag:

  • 429 – Begränsning
  • 408 – Tidsgräns
  • 401 – Ej behörig
  • 503 eller 5xx – Tjänsten är inte tillgänglig

En av åtgärderna i ett arbetsflöde eller en distribuerad transaktion misslyckas.

Identifiering. När N försöker igen misslyckas det fortfarande.

Återhämtning:

  • Som en åtgärdsplan implementerar du Scheduler Agent Supervisor-mönstret för att hantera hela arbetsflödet.
  • Försök inte igen vid tidsgränser. Det finns en låg framgångsgrad för det här felet.
  • Köarbete för att försöka igen senare.

Diagnostik. Logga alla åtgärder (lyckade och misslyckade), inklusive kompenserande åtgärder. Använd korrelations-ID så att du kan spåra alla åtgärder inom samma transaktion.

Ett anrop till en fjärrtjänst misslyckas.

Identifiering. HTTP-felkod.

Återhämtning:

  1. Försök igen vid tillfälliga fel.
  2. Om anropet misslyckas efter N-försök vidtar du en återställningsåtgärd. (Programspecifikt.)
  3. Implementera kretsbrytarmönstret för att undvika sammanhängande fel.

Diagnostik. Logga alla fjärranropsfel.

Nästa steg

Se Återhämtning och beroenden i Azure Well-Architected Framework. Återställning av fel i systemet bör vara en del av arkitektur- och designfaserna från början för att undvika risken för fel.