Del via

Anbefalinger for håndtering av midlertidige feil

  • Artikkel

Gjelder denne Power Platform anbefalingen for sjekkliste for godt strukturert pålitelighet:

RE:05 Øk fleksibiliteten av arbeidsbelastningen ved å implementere feilhåndtering og håndtering av midlertidige feil. Bygg funksjoner i løsningen for å håndtere komponentfeil og midlertidige feil.

Denne veiledningen beskriver anbefalingene for håndtering av midlertidige feil i skyprogrammene. Alle programmer som kommuniserer med eksterne tjenester og ressurser, må være sensitive for midlertidige feil. Dette gjelder spesielt for programmer som kjører i skyen, der denne typen nettverkstilkobling sannsynligvis vil oppstå oftere på grunn av miljøets natur og tilkobling over Internett. Midlertidige feil omfatter midlertidig tap av nettverkstilkobling til komponenter og tjenester, midlertidig utilgjengelighet for en tjeneste og tidsavbrudd som oppstår når en tjeneste er opptatt. Slike feil kan ofte korrigeres selv, så hvis handlingen gjentas etter en passende forsinkelse, vil det sannsynligvis lykkes.

Viktige utformingsstrategier

Midlertidige feil kan forekomme i alle miljøer, på alle plattformer eller operativsystemer og i alle typer programmer.

Utfordringer

Midlertidige feil kan ha en betydelig innvirkning på det som oppfattes som tilgjengeligheten av et program, selv om det er grundig testet under alle mulige forhold. For å sikre at Power Platform-arbeidsbelastningen kan fungere pålitelig må du sørge for at den kan svare på følgende utfordringer:

  • Programmet må være i stand til å registrere feil når de inntreffer og avgjøre om sannsynligheten for at feilene er midlertidige, langvarige eller er uopprettelige. Ulike ressurser returnerer sannsynligvis forskjellige svar når en feil inntreffer, og disse svarene kan også variere avhengig av konteksten for operasjonen. Svaret på en feil når programmet henter data fra en egendefinert kobling, kan for eksempel være et annet enn svaret når programmet kjører en skyflyt og venter på svaret.

  • Programmet må kunne utføre operasjonen på nytt hvis det mener at feilen sannsynligvis er midlertidig.

  • Programmet må bruke en riktig strategi for nye forsøk. Strategien angir hvor mange ganger programmet skal prøve på nytt, forsinkelsen mellom hvert forsøk og handlingene som skal utføres etter et mislykket forsøk. Det riktige antallet forsøk og forsinkelsen mellom dem er ofte vanskelige å fastslå. Strategien varierer avhengig av ressurstypen og nåværende driftsbetingelse for ressursen og programmet.

Generelle retningslinjer

Retningslinjene nedenfor kan hjelpe deg med å utforme egnede mekanismer for håndtering av midlertidige feil i programmene.

Fastslå om det finnes en innebygd mekanisme for nye forsøk

Noen tjenester du kobler til, har kanskje allerede en mekanisme for håndtering av midlertidige feil. Policyen for nye forsøk den bruker, er vanligvis tilpasset naturen og kravene for måltjenesten. REST-grensesnitt for tjenester kan også returnere informasjon som kan hjelpe deg med å avgjøre om et nytt forsøk er hensiktsmessig, og hvor lenge du må vente før neste forsøk.

Du bør bruke den innebygde mekanismen for nye forsøk når en er tilgjengelig, med mindre du har spesifikke og forståtte krav som gjør et annet forsøk mer hensiktsmessig.

Fastslå om operasjonen er egnet for nytt forsøk

Utfør bare operasjoner for nye forsøk når feilen er midlertidig (vanligvis indikert av typen feil), og når det er minst en viss sannsynlighet for at operasjonen vil lykkes når du prøver på nytt. Det er ingen vits i å prøve å utføre operasjoner på nytt som prøver å utføre en ugyldig operasjon, for eksempel oppdatering av en rad i Microsoft Dataverse som ikke finnes, eller som brukeren ikke har tillatelse til, eller kalle et API-endepunkt som ikke finnes.

Implementer nye forsøk bare når du kan fastslå den fullstendige effekten av dette, og når betingelsene er gode og kan valideres. Husk at feilene som returneres fra ressurser og tjenester utenfor kontrollen din, kan utvikle seg over tid, og det kan hende du må revidere den midlertidige logikken for registrering av duplikater.

Når du utvikler individuelle komponenter eller tjenester som kalles opp fra programmene, må du passe på å returnere feilkoder og meldinger som hjelper klienter med å avgjøre om de skal utføre mislykkede operasjoner på nytt. Vurder å angi om klienten skal utføre operasjonen på nytt, for eksempel ved å returnere en isTransient-verdi. Hvis du bygger en nettjeneste, bør du vurdere å returnere egendefinerte feil som er definert i servicekontraktene.

Fastslå riktig antall forsøk og intervaller

Optimaliser antall nye forsøk og intervallet til brukstypen. Hvis du ikke prøver på nytt mange nok ganger, kan ikke programmet fullføre operasjonen, og det vil sannsynligvis mislykkes. Hvis du prøver på nytt for mange ganger eller med et for kort intervall mellom forsøkene, kan det hende at programmet har ressurser i lange perioder, noe som har negativ innvirkning på tilstanden til programmet.

Tilpass verdier for tidsintervallet og antall forsøk på nytt til operasjonstypen. Hvis operasjonen for eksempel er en del av en brukersamhandling, bør intervallet være kort, og det bør bare utføres noen få forsøk. Ved å bruke denne metoden kan du unngå å få brukere til å vente på svar. Hvis operasjonen er en del av en arbeidsflyt som kjører lenge eller er avgjørende, der det er dyrere eller tidkrevende å avbryte og starte prosessen på nytt, er det hensiktsmessig å vente lenger mellom forsøkene og prøve på nytt flere ganger.

Husk at det er den vanskeligste delen av utformingen av en vellykket strategi å fastsette de riktige intervallene mellom forsøkene. Vanlige strategier bruker følgende typer intervaller for nye forsøk:

  • Eksponentielt intervall. Programmet venter kort tid før det første forsøket og deretter øker tiden mellom hvert påfølgende forsøk. Det kan for eksempel hende at operasjonen utføres på nytt etter 3 sekunder, 12 sekunder, 30 sekunder og så videre.

  • Faste intervaller. Programmet venter i samme tidsrom mellom hvert forsøk.

  • Prøv på nytt umiddelbart. Noen ganger er en midlertidig feil kort, og det er hensiktsmessig å utføre operasjonen på nytt umiddelbart fordi det kan lykkes hvis feilen blir fjernet i løpet av tiden programmet bruker på å sende neste forespørsel. Det bør imidlertid aldri være mer enn ett umiddelbart nytt forsøk. Du bør bytte til alternative strategier, for eksempel eksponentielle intervaller eller reservehandlinger, hvis det umiddelbare nye forsøket mislykkes.

Som en generell retningslinje bør du bruke en strategi for regelmessige intervaller for bakgrunnsoperasjoner, og du bør bruke strategier for regelmessige eller faste intervaller for interaktive operasjoner. I begge tilfeller bør du velge forsinkelsen og antallet nye forsøk, slik at maksimal ventetid for alle nye forsøk er innenfor det nødvendige kravet om ende-til-ende-ventetid.

Vurder kombinasjonen av alle faktorer som bidrar til det totale maksimale tidsavbruddet for et nytt forsøk. Disse faktorene inkluderer tiden det tar for en mislykket tilkobling å produsere et svar, forsinkelsen mellom nye forsøk og maksimalt antall nye forsøk. Summen av alle disse tidene kan føre til lange totale driftstider, spesielt når du bruker en strategi for regelmessig forsinkelse der intervallet mellom nye forsøkene raskt etter hver feil. Hvis en prosess må oppfylle en bestemt serviceavtale, må den totale driftstiden, inkludert alle tidsavbrudd og forsinkelser, være innenfor grensene som er definert i serviceavtalen.

Ikke implementer svært aggressive strategier for nye forsøk. Dette er strategier som har intervaller som er for korte eller nye forsøk som er for hyppige. De kan ha en negativ innvirkning på målressursen eller -tjenesten. Disse strategiene kan hindre at ressursen eller tjenesten gjenopprettes fra overbelastet tilstand, og den vil fortsette å blokkere eller avvise forespørsler. Dette scenarioet fører til en ond sirkel der flere og flere forespørsler sendes til ressursen eller tjenesten. Muligheten til å gjenopprette blir derfor ytterligere redusert.

Vurder tidsavbruddet for operasjonene når du velger intervaller for nye forsøk for å unngå å starte et påfølgende forsøk umiddelbart (f.eks. hvis tidsavbruddsperioden ligner på intervallet for nye forsøk).

Bruk feiltypen eller feilkodene og meldingene som returneres fra tjenesten, til å optimalisere antall nye forsøk og intervallet mellom dem. Noen unntak eller feilkoder (f.eks. HTTP-koden 503, Tjenesten er ikke tilgjengelig, med et nytt forsøk etter-hode i svaret) kan for eksempel angi hvor lenge feilen kan vare, eller at tjenesten mislyktes og ikke vil svare på påfølgende forsøk.

Unngå antimønstre

I de fleste tilfeller bør du unngå implementeringer som inkluderer dupliserte lag med kode for nye forsøk. Unngå utforminger som inkluderer overlappende mekanismer for nye forsøk, eller som implementerer et nytt forsøk i hver fase av en operasjon som omfatter et hierarki av forespørsler, med mindre du har spesielle krav til å gjøre dette. I slike spesielle tilfeller bør du bruke policyer som hindrer for stort antall nye forsøk og forsinkelser, og sørger for at du forstår konsekvensene. La oss for eksempel si at en komponent gjør en forespørsel til en annen, som deretter får tilgang til måltjenesten. Hvis du implementerer et nytt forsøk med antallet tre for begge samtalene, er det totalt ni forsøk på å prøve på nytt mot tjenesten. Mange tjenester og ressurser implementerer en innebygd mekanisme for nye forsøk. Du bør undersøke hvordan du kan deaktivere eller endre disse mekanismene hvis du trenger å implementere nye forsøk på et høyere nivå.

Ikke implementer en endeløs mekanisme for nye forsøk. Hvis du gjør dette, vil det sannsynligvis hindre at ressursen eller tjenesten gjenopprettes fra overbelastningssituasjoner og føre til begrensning og nektede tilkoblinger lenger.

Ikke utfør et umiddelbart nytt forsøk mer enn én gang.

Unngå å bruke et fast intervall for nye forsøk når du går til tjenester og ressurser på Azure, spesielt når du har et stort antall nye forsøk. Den beste metoden i dette scenarioet er en strategi for eksponentiell intervall.

Test strategien og implementeringen av nye forsøk

Test strategien for nye forsøk under så omfattende omstendigheter som mulig, spesielt når både programmet og målressursene eller -tjenestene den bruker, er svært belastende. Du kan kontrollere virkemåten under testing ved å gjøre følgende:

  • Injiser midlertidige og ikke-midlertidige feil i tjenesten. Send for eksempel ugyldige forespørsler eller legg til kode som registrerer testforespørsler og svarer med forskjellige typer feil.

  • Opprett et eksempel på ressursen eller tjenesten som returnerer en rekke feil som den virkelige tjenesten kan returnere. Dekk alle typer feil som strategien for nye forsøk er utformet for å oppdage.

  • For tilpassede tjenester som du oppretter og ruller ut, kan du fremtvinge midlertidige feil deaktivering eller overbelastning av tjenesten. (Ikke prøv å overbelaste delte ressurser eller delte tjenester i Azure.)

  • Når du tester et klientnettprograms fleksibilitet for midlertidige feil, bruker du nettleserens utviklerverktøy eller testrammeverkets mulighet til å etterligne eller blokkere nettverksforespørsler.

  • Utfør tester med høy belastningsfaktor og samtidige tester for å sikre at mekanismen for nye forsøk og strategien fungerer riktig under disse forholdene. Disse testene bidrar også til å sikre at det nye forsøket ikke har negativ innvirkning på driften av klienten eller forårsaker krysskontaminering mellom forespørsler.

Behandle policykonfigurasjoner for nye forsøk

En policy for nye forsøk er en kombinasjon av alle elementene i strategien for nye forsøk. Den definerer registreringsmekanismen som avgjør om en feil sannsynligvis er midlertidig, intervalltypen som skal brukes (f.eks. fast eller eksponentielt), de faktiske intervallverdiene og antall ganger du vil utføre nye forsøk.

Dra nytte av de innebygde strategiene eller standardstrategiene for nye forsøk, men bare når de passer for ditt scenario. Disse strategiene er vanligvis generiske. I noen tilfeller er det kanskje alt du trenger, men i andre scenarier tilbyr de ikke hele utvalget av alternativer som passer til dine spesielle behov. Du må utføre testing for å finne ut hvilke verdier som passer best, slik at du forstår hvordan innstillingene påvirker programmet.

Logg og spor midlertidige og ikke-midlertidige feil

Som en del av strategien for nye forsøk bør du inkludere unntakshåndtering og annen instrumentering som logger nye forsøk. En tilfeldig midlertidig feil og nye forsøk forventes og ikke angir et problem. Regelmessig og økende antall nye forsøk er imidlertid ofte en indikator på et problem som kan føre til feil, eller som redusere ytelsen og tilgjengeligheten til programmet.

Logg midlertidige feil som advarselsoppføringer i stedet for som feiloppføringer, slik at overvåkingssystemer ikke registrerer dem som programfeil som kan utløse falske varsler.

Vurder å lagre en verdi i loggoppføringene som angir om nye forsøk er forårsaket av begrensning i tjenesten, eller av andre typer feil, for eksempel tilkoblingsfeil, slik at du kan skille dem under analyse av dataene. En økning i antall begrensningsfeil er ofte en indikator på en utformingsfeil i programmet, eller behovet for å legge til Premium-kapasitet i miljøet.

Vurder implementering av et telemetri- og overvåkingssystem som kan øke varsler når antall og frekvensen av feil, gjennomsnittlig antall nye forsøk eller de totale tidene som gikk før operasjonene lykkes, øker.

Administrer operasjoner som kontinuerlig mislykkes

Vurder hvordan operasjoner som fortsatt mislykkes, ved hvert forsøk. Situasjoner som dette er svært vanskelige å unngå.

Selv om en strategi for nye forsøk definerer maksimalt antall ganger en operasjon skal utføres på nytt, hindrer den ikke at programmet gjentar operasjonen med samme antall forsøk. Hvis du for eksempel sender et skjema i programmet, kan det utløse en flyt. Strategien for nye forsøk kan registrere et tidsavbrudd for tilkoblingen, og anse den som en midlertidig feil. Flyten prøver operasjonen på nytt et angitt antall ganger og gir opp. Når samme eller ny bruker prøver å sende skjemaet på nytt, blir imidlertid operasjonen forsøkt på nytt, selv om den kan fortsette å mislykkes.

Programmet kan regelmessig teste tjenesten, på uregelmessig basis og med lange intervaller mellom forespørsler, for å finne ut når den blir tilgjengelig. Et passende intervall avhenger av faktorer som viktighet for operasjonen og tjenestens art. Det kan være alt mellom et par minutter og flere timer. Når testen er vellykket, kan programmet fortsette vanlige operasjoner og sende forespørsler til den nylig gjenopprettede tjenesten.

I mellomtiden kan det hende du kan utføre noen alternative operasjoner basert på håpet om at tjenesten vil være tilgjengelig snart. Det kan for eksempel være hensiktsmessig å lagre forespørsler om tjenesten i en kø, datalager og prøver på nytt senere. Det kan også hende du må returnere en melding til brukeren for å angi at programmet ikke er tilgjengelig.

Andre hensyn

Når du skal bestemme deg for verdiene for antall nye forsøk og intervallene for nye forsøk for en policy, må du vurdere om operasjonen på tjenesten eller ressursen er en del av en langvarig operasjon eller flertrinnsoperasjon. Det kan være vanskelig eller dyrere å kompensere for alle de andre driftstrinnene som allerede har lyktes når en svikter. I dette tilfellet kan et langt intervall og et stort antall nye forsøk godtas, så lenge denne strategien ikke blokkerer andre operasjoner ved å holde eller låse ressurser.

Vurder om et nytt forsøk på den samme operasjonen kan føre til inkonsekvenser i data. Hvis noen deler av en flertrinnsprosess gjentas og operasjonene ikke er uavhengige, kan det oppstå inkonsekvenser. Hvis for eksempel en operasjon som setter inn en oppføring i Microsoft Dataverse, gjentas, kan det føre til feil verdier i tabellen. Hvis du gjentar en operasjon som sender et varsel til brukeren, kan det hende at de mottar dupliserte meldinger.

Vurder omfanget av operasjoner som skal prøves på nytt. Det kan for eksempel være enklere å implementere ny kode på et nivå som omfatter flere operasjoner, og prøve dem alle på nytt hvis en mislykkes. Hvis du gjør dette, kan det imidlertid føre til uavhengighetsproblemer eller unødvendige tilbakerullingsoperasjoner.

Hvis du velger et område for nye forsøk som omfatter flere operasjoner, må du ta hensyn til den totale ventetiden for alle når du fastsetter intervaller for nye forsøk, når du overvåker de forløpte tidspunktene for operasjonen, og før du varsler om feil.

Tilrettelegging for Power Platform

Avsnittene nedenfor beskriver mekanismene du kan bruke til å administrere midlertidige feil.

Power Automate

Power Automate inneholder en funksjon for å prøve en handling på nytt hvis den mislykkes. Konfigurer dette på et per handling-nivå. Lær om å redusere risiko og planlegge for feilhåndtering i et Power Automate prosjekt. Power Automate tilbyr også handlinger for å returnere egendefinerte feil og data til ringeappen eller -flyten.

Noen midlertidige flyter kan forårsakes av gjennomstrømning og forespørselsbegrensninger. Lær om grensene for automatiske flyter, planlagte flyter og direkteflyter og be om begrensninger og tildelinger.

Konfigurer feil- og unntakshåndtering i skyflyter ved hjelp av omfang og kjøreinnstillinger.

Power Apps

Power Apps-lerretsapper gir funksjonen for å kontrollere tilkoblingsstatusen, slik at de kan fungere på en annen måte hvis appen er frakoblet. Finn ut hvordan du utvikler lerretsapper som kan brukes i frakoblet modus.

Du kan også funksjonene Feil, IfError, IsError og IsBlankOrError i lerretsapper til å bestemme hva du vil gjøre hvis det oppstår en feil.

Lær mer om håndtering av midlertidige feil i Power Apps:

Azure og egendefinerte koblinger

Hvis arbeidsbelastningen kobler til Azure-tjenester, kan du lære hvordan du håndterer midlertidige feil ved hjelp av Azure Well-Architected Framework.

Hvis du vil administrere egendefinerte tilkoblingssvar på feil, følger du kodestandarder.

Application Insights

Bruk Application Insights-integrasjonene til å logge feil i Power Automate og Power Apps:

Forretningskontinuitet og nødgjenoppretting for Dynamics 365 SaaS-apper

Sjekkliste for pålitelighet

Se hele settet med anbefalinger.

Sjekkliste for pålitelighet