Dela via

Rekommendationer för hantering av tillfälliga fel

  • Artikel

Gäller för den här Power Platform rekommendationen för checklistan Well-Architected Reliability :

RE:05 Stärk återhämtningen för din arbetsbelastning genom att implementera felhantering och hantering av tillfälliga fel. Bygg in funktioner i lösningen för att hantera komponentfel och tillfälliga fel.

Den här guiden beskriver rekommendationer för hantering av tillfälliga fel i molnprogrammen. Alla program som kommunicerar med fjärrtjänster och fjärresurser måste vara känsliga för tillfälliga fel. Detta gäller särskilt för program som körs i molnet, där den här typen av störningar troligen kommer att uppstå oftare på grund av miljöns natur och anslutning via Internet. Tillfälliga fel inkluderar tillfälliga förlust av nätverksanslutning för komponenter och tjänster, tillfällig otillgänglighet för en tjänst samt timeouter som inträffar när en tjänst är upptagen. Felen är ofta själv korrigerande, så om åtgärden upprepas efter en lämplig fördröjning är det troligt att den lyckas.

Viktiga designstrategier

Tillfälliga fel kan inträffa i alla miljöer, på alla plattformar eller operativsystem, och i alla typer av program.

Utmaningar

Tillfälliga fel kan ha en stor effekt på programmets uppfattade tillgänglighet, även om det har testats noggrant under alla tänkbara omständigheter. För att säkerställa att Power Platform-arbetsbelastningen fungerar som den ska måste du se till att den kan hantera följande utmaningar:

  • Programmet måste kunna identifiera fel när de inträffar och avgöra om felen är tillfälliga eller om de är långvariga eller oåterkalleliga fel. Det är troligt att olika resurser returnerar olika svar när ett fel inträffar och svaren kan också variera beroende på sammanhanget i åtgärden. Exempelvis kan åtgärden för ett fel när programmet hämtar data från ett anpassat anslutningsprogram vara ett annat än åtgärden när programmet kör ett molnflöde och väntar på svaret.

  • Programmet måste kunna göra ett nytt försök om det bedömer att felet förmodligen är tillfälligt.

  • Programmet måste använda en lämplig strategi för återförsök. I strategin anges hur många gånger programmet ska försöka igen, fördröjningen mellan varje försök och åtgärderna som ska vidtas efter ett misslyckat försök. Det är ofta svårt att avgöra hur många försök som ska göras och hur fördröjningen mellan försöken är ofta svår att fastställa. Strategin varierar beroende på resurstyp och på resursens och programmets aktuella driftförhållanden.

Allmänna riktlinjer

Med hjälp av följande riktlinjer kan du utforma lämpliga hanteringsmekanismer för tillfälliga fel för dina program.

Bestäm om det finns en inbyggd återförsöksmekanism

En del tjänster som du ansluter till kanske redan tillhandahåller en funktion för hantering av tillfälliga problem. Den återförsöksprincip som den använder är oftast skräddarsydd efter måltjänstens typ och krav. REST-gränssnitten för tjänster kan också returnera information som kan hjälpa dig att avgöra om ett nytt försök är lämpligt och hur länge du ska vänta innan nästa försök görs igen.

Du bör använda den inbyggda återförsöksmekanismen när en är tillgänglig om du inte har specifika och välförstådda krav som gör ett annat återförsöksbeteende mer lämpligt.

Bestäm om åtgärden är lämplig för återförsök

Utför återförsök endast om felen är tillfälliga (visas vanligtvis med felets typ) och det finns åtminstone en sannolikhet för att åtgärden ska lyckas vid ett nytt försök. Det finns ingen anledning att försöka utföra åtgärder igen om du försöker en ogiltig åtgärd, till exempel uppdatera en rad i Microsoft Dataverse som inte finns, eller som användaren inte har behörighet till, eller att anropa ett API-slutpunkt som inte finns.

Implementera återförsöken endast när du kan fastställa den fullständiga effekten av detta och när villkoren är väl förstådda och kan verifieras. Tänk på att felen som returneras från resurser och tjänster som du inte har kontroll över kan utvecklas med tiden. Du kanske måste åtgärda identifieringslogiken för tillfälliga fel.

När du utvecklar enskilda komponenter eller tjänster som anropas från programmen ska du se till att returnera felkoder och meddelanden som hjälper klienterna att avgöra om de ska försöka utföra misslyckade åtgärder igen. Fundera på om klienten ska försöka utföra åtgärden igen, till exempel genom att returnera värdet isTransient. Om du skapar en webbtjänst kan du överväga att returnera anpassade fel som definieras i servicekontrakten.

Fastställ ett lämpligt antal och intervall för återförsök

Optimera antalet återförsök och intervallet för typen av användningsfall. Om du inte återförsöker tillräckligt många gånger kan inte programmet slutföra åtgärden och den kommer troligen att misslyckas. Om du återförsöker för många gånger, eller med för kort intervall mellan försöken, kan programmet hålla kvar resurser under långa perioder, vilket påverkar programmets hälsa negativt.

Anpassa värden för tidsintervallet och antalet försök till typen av åtgärd. Om åtgärden till exempel är en del av en användarinteraktion ska intervallet vara kort och endast ett fåtal försök ska göras. Om du använder den här metoden kan du undvika att få användarna att vänta på ett svar. Om åtgärden är en del av ett tidskrävande eller viktigt arbetsflöde där det är dyrt eller tar lång tid att avbryta och starta om processen, bör du vänta längre mellan försöken och återförsöka fler gånger.

Tänk på att det är mycket svårt att fastställa lämpliga intervaller mellan återförsöken när en framgångsrik strategi utformas. Vanliga strategier använder följande typer av intervall för återförsök:

  • Exponentiellt intervall. Programmet väntar en kort tid innan det första återförsöket och ökar sedan tiden exponentiellt mellan varje efterföljande återförsök. Det kan till exempel försöka utföra åtgärden igen efter 3 sekunder, 12 sekunder, 30 sekunder och så vidare.

  • Fasta intervaller. Programmet väntar under samma tidsperiod mellan varje försök.

  • Omedelbart nytt försök. Ibland är det tillfälliga felet kort och det är därför lämpligt att göra ett nytt försök omedelbart, eftersom det kan lyckas om felet försvinner under den tid det tar för programmet att skicka nästa begäran. Du ska dock aldrig göra fler än ett omedelbart försök till återförsök. Du bör byta till alternativa strategier, som exponentiella intervall eller reservåtgärder, om det omedelbara återförsöket misslyckas.

Som allmän regel kan du använda en exponentiell intervallstrategi för bakgrundsåtgärder, och använda strategier med omedelbara återförsök eller återförsök med fast intervall för interaktiva åtgärder. I båda fallen bör du välja fördröjningen och antalet återförsök så att den högsta tillåtna latensen för alla försök igen ligger inom det obligatoriska kravet på komplett latens.

Tänk på kombinationen av alla faktorer som bidrar till den maximala tidsgränsen för en åtgärd som utförs på nytt. Dessa faktorer omfattar den tid det tar för en misslyckad anslutning att skapa ett svar, fördröjningen mellan återförsöken och det maximala antalet återförsök. Totalsumman av alla dessa tider kan resultera i långa generella användningstider, särskilt när du använder en strategi med exponentiell fördröjning där intervallet mellan återförsöken växer snabbt efter varje fel. Om en process måste uppfylla ett visst serviceavtal (SLA, Service Level Agreement) måste den övergripande åtgärdstiden, inklusive alla tidsgränser och förseningar, vara inom de gränser som definieras i SLA-avtalet.

Implementera inte för många, extremt aggressiva återförsöksstrategier. Det här är strategier som har för korta intervaller eller för ofta förekommande återförsök. De kan ha en negativ effekt på målresursen eller måltjänsten. Dessa metoder kan göra att resursen eller tjänsten inte kan återställas från överbelastat tillstånd, och fortsätter att blockera eller avvisa förfrågningar. Det här scenariot resulterar i en ond cirkel där fler och fler förfrågningar skickas till resursen eller tjänsten. Därför minskas möjligheten att återställa ytterligare.

Tänk på tidsgränsen för åtgärderna när du väljer intervall för återförsök för att undvika att starta ett efterföljande försök omedelbart (till exempel om tidsgränsen är ungefär samma som intervallet för återförsök).

Använd feltypen eller felkoderna och meddelandena som returneras från tjänsten för att optimera antalet återförsök och intervallet mellan dem. Vissa undantag eller felkoder (t.ex. HTTP-kod 503, Tjänsten är inte tillgänglig, med rubriken Försök-efter i svaret) kan exempelvis indikera hur länge felet kan vara pågå, eller på att tjänsten misslyckades och kommer inte att svara på efterföljande försök.

Undvik antimönster

I de flesta fall bör du undvika implementeringar som innehåller dubblerade skikt av kod för återförsök. Undvik designer som innehåller kaskadåterförsöksmekanismer eller som implementerar återförsök i varje stadium av en åtgärd som omfattar en hierarki av förfrågningar, såvida du inte har särskilda krav på att göra det. I dessa exceptionella förhållanden, använd principer som förhindrar alltför många perioder av återförsök och förseningar, och försäkra dig om att du förstår konsekvenserna. Låt säga att en komponent gör en begäran till en annan, som sedan får åtkomst till måltjänsten. Om du implementerar tre återförsök för båda anropen görs totalt nio återförsök mot tjänsten. Många tjänster och resurser implementerar en inbyggd återförsöksmekanism. Du bör undersöka hur du kan inaktivera eller ändra de här mekanismerna om du behöver implementera återförsök på en högre nivå.

Implementera aldrig någon oändlig återförsöksmekanism. Om du gör det kan den förhindra att resursen eller tjänsten återställs från överbelastade situationer, och det kan leda till att begränsningar och nekade anslutningar fortsätter under en längre tid.

Försök aldrig utföra ett omedelbart återförsök mer än en gång.

Undvik att använda ett fast återförsöksintervall när du kommer åt tjänster och resurser i Azure, särskilt när du har ett stort antal återförsök. Den bästa metoden i det här scenariot är en exponentiell intervallstrategi.

Testa återförsöksstrategin och implementeringen

Testa återförsöksstrategin under så många omständigheter som möjligt, särskilt när både programmet och målresurserna eller måltjänsterna som används är under extrem belastning. Om du vill kontrollera beteendet under testningen kan du:

  • Injicera tillfälliga och icke-övergående fel i tjänsten. Du kan till exempel skicka ogiltiga förfrågningar eller lägga till kod som identifierar testförfrågningar och svarar på olika typer av fel.

  • Skapa en fiktiv resurs eller tjänst som returnerar en rad fel som den verkliga tjänsten kan komma att returnera. Täck alla typer av fel som återförsöksstrategin är utformad för att identifiera.

  • För anpassade tjänster som du skapar och distribuerar måste du tvinga fram tillfälliga fel genom att tillfälligt inaktivera eller överbelasta tjänsten. (Försök inte överbelasta några delade resurser eller delade tjänster i Azure.)

  • Om du testar ett klientwebbprograms återhämtning vid tillfälliga fel, använd webbläsarens utvecklarverktyg eller testramverkets möjlighet att efterlikna eller blockera nätverksbegäranden.

  • Utför test av hög belastningsfaktor och samtidighet för att säkerställa att återförsöksmekanismen och strategin fungerar korrekt under dessa förhållanden. Med hjälp av dessa tester kan du även se till att återförsöket inte påverkar klientens funktion negativt eller leder till kontaminering mellan förfrågningarna.

Hantera konfigurationer av återförsöksprinciper

En återförsöksprincip är en kombination av alla element i återförsöksstrategin. Den definierar den identifieringsmekanism som avgör om det är troligt att ett fel är tillfälligt, vilken typ av intervall som ska användas (som fast eller exponentiell), de faktiska intervallvärdena och antalet gånger som det ska göras ett nytt försök.

Dra nytta av de inbyggda strategierna eller standardstrategierna för återförsök, men bara när de passar ditt scenario. De här strategierna är vanligtvis generiska. I vissa scenarier kanske de är allt du behöver, men i andra scenarier erbjuder de inte alla alternativ för dina specifika behov. Du måste utföra tester för att ta reda på hur inställningarna påverkar ditt program för att avgöra vilka värden som är mest lämpliga.

Logga och spåra tillfälliga och icke-övergående fel

Som en del av återförsöksstrategin inkluderar du undantagshantering och annan instrumentation som loggar återförsök. Ett enstaka tillfälligt fel och återförsök förväntas och tyder inte på några problem. Ett regelbundet och ökande antal återförsök visar dock ofta på problem som kan orsaka fel eller försämra programmets prestanda och tillgänglighet.

Logga tillfälliga fel som varningsposter i stället för som felposter så att övervakningssystem inte identifierar dem som programfel som kan utlösa felaktiga aviseringar.

Överväg att lagra ett värde i loggposterna som anger om återförsöken orsakas av begränsning i tjänsten eller av andra typer av fel, t.ex. anslutningsfel, så att du kan skilja dem åt vid analys av data. Ett ökande antal begränsningsfel beror ofta på att programmet har ett designfel eller att det finns ett behov av att lägga till premium-kapacitet i miljön.

Överväg att implementera ett telemetri- och övervakningssystem som kan ge varningar vid ökning av antalet och frekvensen av fel, det genomsnittliga antalet återförsök eller den övergripande tid innan åtgärderna lyckas.

Hantera åtgärder som ständigt misslyckas

Fundera på hur du ska hantera åtgärder som misslyckas vid varje försök. Situationer som den här är ofrånkomliga.

Även om en återförsöksstrategi definierar det maximala antalet gånger som en åtgärd ska göras på nytt, förhindrar den inte att programmet upprepar åtgärden med samma antal återförsök. Exempelvis kan ett flöde utlösas om du skickar ett formulär i programmet. Återförsöksstrategin kanske identifierar en tidsgräns för anslutningen och ser det som ett tillfälligt problem. Flödet försöker utföra åtgärden ett angivet antal gånger och ger sedan upp. Men när samma eller en ny användare försöker skicka formuläret igen görs ett nytt försök att utföra åtgärden, även om det kan fortsätta att misslyckas.

Tjänsten kan regelbundet testas av programmet, och på tillfällig bas och med långa intervaller mellan förfrågningar, för att identifiera när den blir tillgänglig. Ett lämpligt intervall beror på faktorer som hur kritisk åtgärden är och typen av tjänst. Det kan ta mellan några minuter och flera timmar. När testet har lyckats kan programmet återuppta normala åtgärder och skicka förfrågningar till den nyligen återställda tjänsten.

Under tiden kanske du kan utföra några alternativa åtgärder och hoppas att tjänsten snart kommer att vara tillgänglig. Det kan exempelvis vara lämpligt att lagra förfrågningar om tjänsten i en kö eller ett datalager och försöka genomföra dem igen senare. Du kan också behöva returnera ett meddelande till användaren för att ange att programmet inte är tillgängligt.

Övrigt att tänka på

När du bestämmer värden för antalet återförsök och intervaller för återförsök för en princip bör du tänka på om åtgärden för tjänsten eller resursen är en del av en lång körning eller en åtgärd med flera steg. Det kan vara svårt eller dyrt att behöva kompensera för alla andra verksamhetssteg som redan har lyckats när ett steg misslyckas. I det här fallet kan ett långt intervall och ett stort antal återförsök accepteras, om inte den strategin blockerar andra åtgärder genom att spärra eller lås begränsade resurser.

Fundera på om ett nytt försök med samma åtgärd kan orsaka inkonsekvenser i data. Om vissa delar i en flerstegsprocess upprepas och åtgärderna inte är idempotenta kan inkonsekvenser uppstå. Om en åtgärd som infogar en post i Microsoft Dataverse upprepas kan det exempelvis orsaka felaktiga värden i tabellen. Eller, om du upprepar en åtgärd som skickar ett meddelande till användaren, kan de få dubblettmeddelanden.

Fundera över vilka åtgärder som ska återförsökas. Det kan till exempel vara enklare att implementera återförsökskod på en nivå som omfattar flera åtgärder och försöka utföra alla igen om en misslyckas. Det kan emellertid leda till problem med idempotens eller onödiga återställningsåtgärder.

Om du väljer en omfattning för återförsök som omfattar flera åtgärder bör du tänka på den totala latensen för alla åtgärder när du fastställer återförsöksintervaller, när du övervakar de upplupna tiderna för åtgärden och innan du gör aviseringar om fel.

Underlätta Power Platform

I följande avsnitt beskrivs vilka metoder du kan använda för att hantera tillfälliga fel.

Power Automate

Power Automate innehåller en funktion för att försöka utföra en åtgärd igen om den misslyckas. Konfigurera det per åtgärdsnivå. Lär dig mer om att minska risker och planera för felhantering i ett Power Automate projekt. Power Automate erbjuder även åtgärder för att returnera anpassade fel och data till anropande app eller flöde.

Vissa tillfälliga flöden kan orsakas av genomflödes- och begäransbegränsningar. Lär dig om begränsningarna för automatiserade och schemalagda flöden och snabbflöden samt begäransbegränsningar och tilldelningar.

Konfigurera fel- och undantagshantering i molnflöden med hjälp av omfång och kör-efter-inställningar.

Power Apps

Med Power Apps-arbetsyteappar kan du kontrollera anslutningsstatusen, så att de kan agera på ett annat sätt när appen är offline. Lär dig hur du utvecklar arbetsyteappar som är offline-kompatibla.

Du kan också använda funktionerna Error, IfError, IsError och IsBlankOrError i arbetsyteappar för att avgöra vad som ska göras om ett fel inträffar.

Läs mer om hantering av tillfälliga fel i Power Apps:

Azure och anpassade anslutningsprogram

Om din arbetsbelastning ansluter till Azure-tjänster, läs om hur du hanterar tillfälliga fel med Azures välstrukturerade ramverk.

Hantera anpassade anslutningsprograms svar på fel genom att följa kodstandarder.

Application Insights

Använd Application Insights-integreringarna för att logga fel i Power Automate och Power Apps:

Affärskontinuitet och haveriberedskap för Dynamics 365 SaaS-appar

Checklista för tillförlitlighet

Se den fullständiga uppsättningen med rekommendationer.

Checklista för tillförlitlighet