Del via

Anbefalinger til håndtering af midlertidige fejl

  • Artikel

Gælder for denne Power Platform anbefaling af tjekliste for velstruktureret pålidelighed:

RE:05 Styrk arbejdsbelastningens robusthed ved at implementere fejlhåndtering og midlertidig fejlbehandling. Opbyg funktionerne i løsningen til at håndtere komponentfejl og midlertidige fejl.

I denne vejledning beskrives anbefalingerne til håndtering af midlertidige fejl i dine cloudprogrammer. Alle programmer, der kommunikerer med fjerntjenester og ressourcer, skal være følsomme over for midlertidige fejl. Dette gælder især for programmer, der kører i cloud, hvor der på grund af miljøets og forbindelsens art over internettet er sandsynlighed for, at denne type fejl opstår oftere. Midlertidige fejl omfatter midlertidigt tab af netværksforbindelsen til komponenter og tjenester, midlertidig utilgængelighed af en tjeneste og timeout, der opstår, når en tjeneste er optaget. Disse fejl retter ofte sig selv, så hvis handlingen gentages efter en passende forsinkelse, lykkes den sandsynligvis.

Vigtigste designstrategier

Midlertidige fejl kan forekomme i alle miljøer, på en platform eller et operativsystem og i alle typer programmer.

Udfordringer

Midlertidige fejl kan have en betydelig indvirkning på, om et program er tilgængeligt, selvom det er blevet grundigt testet under alle forventelige omstændigheder. For at sikre, at Power Platform-arbejdsbelastningen kan fungere pålideligt, skal du sikre, at den kan håndtere følgende udfordringer:

  • Programmet skal kunne registrere fejl, når de opstår, og finde ud af, om fejlene kan være midlertidige, er langvarige eller er vedvarende fejl. Forskellige ressourcer returnerer sandsynligvis forskellige svar, når der opstår en fejl, og svarene kan også variere, afhængigt af handlingens kontekst. Responset på en fejl, når programmet henter data fra en brugerdefineret connector, kan f.eks. være et andet end svaret, når programmet kører et connector og venter på svaret.

  • Programmet skal kunne prøve handlingen igen, hvis det beslutter, at fejlen sandsynligvis er midlertidig.

  • Der skal bruges en passende strategi for nye forsøg i programmet. Strategien angiver det antal gange, programmet skal forsøge igen, forsinkelsen mellem de enkelte forsøg og de handlinger, der skal udføres efter et mislykket forsøg. Det er ofte svært at afgøre, hvor mange forsøg der skal gøres, og hvor lang tid der skal gå mellem dem. Strategien varierer, afhængigt af ressourcetypen og de aktuelle driftsbetingelser for ressourcen og programmet.

Generelle retningslinjer

Brug følgende retningslinjer til at designe egnede midlertidige fejlhåndteringsmekanismer til dine programmer.

Find ud af, om der er en indbygget mekanisme til flere forsøg

Nogle tjenester, du opretter forbindelse til, indeholder måske allerede en midlertidig fejlhåndteringsmekanisme. Den politik for nyt forsøg, der bruges, er typisk skræddersyet til destinationstjenestens art og krav. Alternativt kan REST-grænseflader for tjenester returnere oplysninger, der kan hjælpe dig med at finde ud af, om et nyt forsøg er passende, og hvor lang tid der skal gå før næste forsøg.

Du skal bruge den indbyggede mekanisme til flere forsøg, når den er tilgængelig, medmindre du har specifikke og velforståede krav, der gør en anden funktionsmåde for flere forsøg mere passende.

Find ud af, om handlingen er velegnet til nye forsøg

Udfør kun nye forsøg, når fejlene er midlertidige (typisk angivet af fejlens art), og når der i det mindste er en vis sandsynlighed for, at handlingen lykkes, når den udføres igen. Det giver ikke mening at gøre nye forsøg på at udføre en ugyldig handling, f.eks. at opdatere en række i Microsoft Dataverse, der ikke findes, eller brugeren ikke har tilladelse til eller kald af et API-slutpunkt, der ikke findes.

Implementer kun nye forsøg, når du kan fastslå den fulde effekt af at gøre det, og når betingelserne er velforståede og kan valideres. Husk, at de fejl, der returneres fra ressourcer og tjenester uden for din kontrol, kan udvikle sig over tid, og du skal måske revidere logikken for registrering af midlertidige fejl.

Når du udvikler individuelle komponenter eller tjenester, der kaldes fra dine programmer, skal du sørge for at returnere fejlkoder og meddelelser, der hjælper klienter med at finde ud af, om de skal udføre mislykkede handlinger igen. Overvej at angive, om klienten skal prøve handlingen igen, ved f.eks. at returnere en isTransient-værdi. Hvis du har opbygget en webtjeneste, kan du overveje at returnere egne tilpassede fejl, der er defineret i servicekontrakterne.

Fastlæg et passende antal nye forsøg og et passende interval

Optimer antallet af nye forsøg og intervallet til typen af brugssag. Hvis du ikke forsøger at udføre handlingen igen nok gange, kan programmet ikke fuldføre handlingen, og den lykkes sandsynligvis ikke. Hvis du prøver for mange gange eller med et for kort interval mellem forsøgene, kan programmet holde på ressourcer i lang tid, hvilket har en negativ indvirkning på programmets tilstand.

Tilpas værdierne for tidsintervallet og antallet af nye forsøg til typen af handling. Hvis handlingen f.eks. er en del af en brugerinteraktion, skal intervallet være kort, og der skal kun gøres få nye forsøg. Ved hjælp af denne fremgangsmåde kan du undgå, at brugerne skal vente på et svar. Hvis handlingen er en del af en langvarig eller kritisk arbejdsproces, hvor annullering og genstart af processen er dyr og tidskrævende, er det passende at vente længere mellem forsøg og gentage flere gange.

Husk på, at fastlæggelse af de rette intervaller mellem nye forsøg er det vanskeligste ved at udarbejde en vellykket strategi. I typiske strategier bruges følgende typer gentagelsesintervaller:

  • Eksponentielt interval. Programmet venter en kort periode, før det første forsøg prøves igen, og derefter øges tiden eksponentielt mellem hvert efterfølgende forsøg. Det kan f.eks. være, at handlingen skal udføres igen efter 3 sekunder, 12 sekunder, 30 sekunder osv.

  • Faste intervaller. I programmet ventes der den samme periode mellem hvert forsøg.

  • Prøv straks igen. Undertiden er en midlertidig fejl kort, og det er passende at forsøge at gennemføre handlingen igen med det samme, da den kan lykkes, hvis fejlen er ryddet i den tid, det tager at sende den næste forespørgsel. Der bør dog aldrig straks gøres nye forsøg mere end én gang. Du bør skifte til alternative strategier, f.eks. eksponentielt interval eller fallback-handlinger, hvis det omgående nye forsøg mislykkes.

Som en generel retningslinje kan du bruge en eksponentiel intervalstrategi til baggrundshandlinger og bruge strategier for omgående forsøg eller fast interval for interaktive handlinger. I begge tilfælde skal du vælge forsinkelsen og antallet af nye forsøg, så maksimumventetiden for alle nye forsøg ligger inden for kravet om samlet ventetid.

Overvej en kombination af alle faktorer, der bidrager til den samlede maksimale timeout for en gentaget handling. Disse faktorer omfatter den tid, det tager for en mislykket forbindelse at oprette et svar, forsinkelsen mellem nye forsøg og det maksimale antal forsøg. Den samlede værdi af alle disse tider kan resultere i lange samlede driftstider, især når du bruger en eksponentiel forsinkelsesstrategi, hvor intervallet mellem nye forsøg vokser hurtigt efter hver fejl. Hvis en proces skal overholde en bestemt serviceaftale, skal den samlede driftstid, herunder alle timeout og forsinkelser, være inden for de grænser, der er defineret i SLA'en.

Du må ikke implementere en overdreven gentagelsesstrategi. Det er strategier med intervaller, der er for korte, eller hvor der er for mange nye forsøg. De kan have en negativ indvirkning på målressourcen eller servicen. Disse strategier kan forhindre, at ressourcen eller tjenesten gendannes fra en overbelastet tilstand, og den vil fortsat blokere eller afvise anmodninger. Dette scenario resulterer i en ond cirkel, hvor der sendes flere og flere forespørgsler til ressourcen eller servicen. Derfor reduceres muligheden for gendannelse yderligere.

Overvej timeout for handlinger, når du vælger intervaller for nye forsøg, for at undgå straks at starte et efterfølgende forsøg (hvis f.eks. timeoutperioden svarer til intervallet for nye forsøg).

Brug fejltypen eller fejlkoderne og de meddelelser, der returneres fra tjenesten, til at optimere antallet af nye forsøg og intervallet mellem dem. Visse undtagelser eller fejlkoder (f.eks. HTTP-kode 503, Service ikke tilgængelig med headeren Prøv igen efter i svaret) kan f.eks. indikere, hvor lang tid fejlen kan vare, eller at tjenesten ikke lykkedes og ikke vil reagere på efterfølgende forsøg.

Undgå modmønstre

I de fleste tilfælde skal du undgå implementeringer, der indeholder duplikerede lag af gentagelseskode. Undgå design, der omfatter overlappende forsøgsmekanismer, eller som implementerer nyt forsøg i alle faser af en handling, der involverer et hierarki af forespørgsler, medmindre du har specifikke krav til at gøre det. I disse undtagelsessituationer kan du bruge politikker, der forhindrer for mange nye forsøg og forsinkelser, og sørge for, at du forstår konsekvenserne. Det kan f.eks. være én komponent, der foretager en anmodning til en anden, som derefter får adgang til måltjenesten. Hvis du implementerer flere forsøg med et antal af tre på begge kald, er der i alt ni forsøg på at udføre handlingen på tjenesten igen. Mange tjenester og ressourcer implementerer en indbygget mekanisme til flere forsøg. Du bør undersøge, hvordan du kan deaktivere eller ændre disse mekanismer, hvis du skal implementere nye forsøg på et højere niveau.

Implementer aldrig en mekanisme med uendelige forsøg. Hvis du gør det, vil det sandsynligvis forhindre, at ressourcen eller tjenesten kan gendannes efter overbelastningssituationer, og kan skabe begrænsning og afviste forbindelser, hvis det fortsætter i længere tid.

Udfør aldrig et omgående nye forsøg mere end én gang.

Undgå at bruge et fast gentagelsesinterval, når du får adgang til tjenester og ressourcer på Azure, især når du har et stort antal nye forsøg. Den bedste fremgangsmåde i dette scenario er en eksponentiel intervalstrategi.

Test strategien og implementeringen af nye forsøg

Test forsøgsstrategien fuldstændigt under så mange omstændigheder som muligt, især når både programmet og de målressourcer eller -tjenester, der bruges, er ekstremt belastet. Du kan kontrollere funktionsmåden under testen ved at gøre følgende:

  • Indfør midlertidige og ikke-midlertidige fejl i servicen. Du kan f.eks. sende ugyldige forespørgsler eller tilføje kode, der registrerer testanmodninger og svarer med forskellige typer fejl.

  • Opret en prøvekopi af ressourcen eller servicen, der returnerer en række fejl, som den rigtige service kan returnere. Dækker alle de typer fejl, som strategien for nye forsøg er udviklet til at registrere.

  • Til brugerdefinerede tjenester, du opretter og udruller, skal du gennemtvinge midlertidige fejl ved midlertidigt at deaktivere eller overbelaste tjenesten. (Du må ikke forsøge at overbelaste delte ressourcer eller delte tjenester i Azure).

  • Når du tester et klientwebprograms sårbarhed over for midlertidige fejl, skal du bruge browserens udviklerværktøjer eller din teststrukturs evne til at modellere eller blokere netværksanmodninger.

  • Udfør test med høj belastning og samtidige tests for at sikre, at forsøgsmekanismen og strategien fungerer korrekt under disse betingelser. Disse tests er også med til at sikre, at det nye forsøg ikke har en negativ indvirkning på klientens drift eller virker på tværs af forespørgsler.

Administrer konfigurationer af politik for nyt forsøg

En politik for nyt forsøg er en kombination af alle elementer i strategien for nye forsøg. Den definerer den registreringsmekanisme, der bestemmer, om en fejl sandsynligvis er midlertidig, den type interval, der skal bruges (f.eks. fast eller eksponentiel), de faktiske intervalværdier og det antal gange, der skal forsøges igen.

Udnyt de indbyggede strategier eller standardstrategier for nye forsøg, men kun, når de passer til dit scenario. Disse strategier er typisk generiske. I nogle scenarier er det måske alt, du har brug for, men i andre scenarier tilbyder de ikke alle muligheder, der opfylder dine specifikke behov. Hvis du vil fastslå de mest relevante værdier, skal du udføre test for at finde ud af, hvordan indstillingerne påvirker programmet.

Log og spor midlertidige og ikke-midlertidige fejl

Som en del af forsøgsstrategien skal du inkludere håndtering af undtagelser og andre instrumenter, der logfører nye forsøg. Der forventes lejlighedsvise midlertidige fejl og nye forsøg, og det indikerer ikke et problem. Regelmæssigt og stigende antal nye forsøg er dog ofte en indikator for et problem, der kan medføre fejl eller forringe programmets ydeevne og tilgængelighed.

Log midlertidige fejl som advarselsposter i stedet for som fejlposter, så overvågningssystemer ikke registrerer dem som programfejl, der kan udløse falske varslinger.

Overvej at gemme en værdi i logposterne, der angiver, om nye forsøg skyldes fejl begrænsning i tjenesten eller andre typer fejl, f.eks. fejl i forbindelsen, så du kan skelne mellem dem under analyse af dataene. En stigning i antallet af begrænsningsfejl er ofte en indikator for en designfejl i programmet eller behov for at føje premiumkapacitet til miljøet.

Overvej at implementere et telemetri- og overvågningssystem, der kan udløse varslinger, når antallet og hastigheden af fejl, det gennemsnitlige antal nye forsøg eller den samlede tid, der er gået, før handlingerne lykkes, er øget.

Administrer handlinger, der hele tiden mislykkes

Overvej, hvordan du håndterer handlinger, der fortsat mislykkes ved hvert forsøg. Situationer som denne er uundgåelige.

Selvom en ny forsøgsstrategi definerer det maksimale antal gange, en handling skal gentages, forhindrer den ikke, at handlingen gentages med det samme antal forsøg. Afsendelse af en formular i programmet kan f.eks. udløse et flow. Forsøgsstrategien registrerer måske timeout for en forbindelse og anser det for at være en midlertidig fejl. Flowet forsøger at udføre handlingen igen et angivet antal gange og giver derefter op. Men når den samme eller en ny bruger forsøger at sende formularen igen, forsøges handlingen igen, også selvom det kan fortsætte med at mislykkes.

Programmet kan jævnligt teste servicen periodisk og med lange intervaller mellem forespørgsler for at registrere, hvornår den bliver tilgængelig. Et passende interval afhænger af faktorer som driftens kritiske niveau og servicens karakter. Det kan tage mellem et par minutter og flere timer. Når testen lykkes, kan programmet genoptage de normale handlinger og sende anmodninger til den tjeneste, der netop er gendannet.

I mellemtiden kan du muligvis udføre nogle alternative handlinger ud fra et ønske om, at servicen snart bliver tilgængelig. Det kan f.eks. være passende at gemme anmodninger til servicen i en kø eller et datalager og prøve dem igen på et senere tidspunkt. Eller du skal måske returnere en meddelelse til brugeren for at angive, at programmet ikke er tilgængeligt.

Andre overvejelser

Når du beslutter dig for værdierne for antallet af nye forsøg og intervallerne for flere forsøg for en politik, skal du overveje, om handlingen på servicen eller ressourcen er en del af en længere kørsel eller en flertrinshandling. Det kan være svært eller vanskeligt at kompensere for alle de andre driftsmæssige trin, der allerede er udført korrekt, når der er fejl i den ene. I dette tilfælde kan et langt interval og et stort antal nye forsøg accepteres, så længe denne strategi ikke blokerer andre handlinger ved at holde på eller låse sparsomme ressourcer.

Overvej, om nye forsøg på den samme handling kan medføre inkonsistens i data. Hvis visse dele af en proces med flere trin gentages, og handlingerne ikke er idempotente, kan der opstå inkonsistens. Hvis en handling, der f.eks. indsætter en post i Microsoft Dataverse, gentages, kan det medføre forkerte værdier i tabellen. Hvis du gentager en handling, der sender en meddelelse til brugeren, modtager brugeren måske duplikerede meddelelser.

Overvej omfanget af handlinger, der gentages. Det kan f.eks. være nemmere at implementere kode til nyt forsøg på et niveau, der omfatter flere handlinger, og prøve at udføre dem alle igen, hvis der er fejl. Hvis du gør det, kan det medføre idempotentproblemer eller unødvendige tilbagerulningshandlinger.

Hvis du vælger et omfang af nye forsøg, der omfatter flere handlinger, skal du overveje den samlede ventetid for dem alle, når du bestemmer intervaller for nye forsøg, når du overvåger de forløbne driftstider, og før du giver besked om fejl.

Power Platform-processtyring

I følgende afsnit beskrives de mekanismer, du kan bruge til at håndtere midlertidige fejl.

Power Automate

Power Automate indeholder en funktion, der kan prøve en handling igen, hvis den mislykkes. Konfigurer denne på et handlingsniveau. Få mere at vide om at reducere risikoen og planlægge fejlhåndtering i et Power Automate projekt. Power Automate indeholder også handlinger, der returnerer brugerdefinerede fejl og data til den kaldende app eller det kaldende flow.

Nogle midlertidige flows kan skyldes grænser for gennemløb og anmodninger. Få mere at vide om grænserne for automatiserede, planlagte og øjeblikkelige flows og anmodningsgrænser og allokeringer.

Konfigurer fejl- og undtagelseshåndtering i cloudflow ved hjælp af områder og kørselsindstillinger.

Power Apps

Power Apps-lærredapps giver mulighed for at kontrollere forbindelsesstatus, så de kan have en anden funktionsmåde, hvis appen er offline. Få mere at vide om, hvordan du udvikler offlinekompatible lærredapps.

Du kan også bruge funktionerne Error, IfError, IsError, og IsBlankOrError i lærredapps til at bestemme, hvad der skal ske, hvis der opstår en fejl.

Få mere at vide om håndtering af midlertidige fejl i Power Apps:

Azure og brugerdefinerede connectorer

Hvis din arbejdsbelastning er forbundet med Azure-tjenester, kan du få mere at vide om, hvordan du håndterer midlertidige fejl ved hjælp af Azure Well-Architected Framework.

Hvis du vil administrere fejl i brugerdefinerede connectorer, skal du følge standarder for kodning.

Application Insights

Brug Application Insights-integrationerne til at logge fejl i Power Automate og Power Apps:

Forretningskontinuitet og it-katastrofeberedskab for Dynamics 365 SaaS-apps

Kontrolliste for bæredygtighed

Se det fuldstændige sæt anbefalinger.

Tjekliste for pålidelighed