Delen via

Aanbevelingen voor het omgaan met kortstondige fouten

  • Artikel

Van toepassing op deze aanbeveling voor de Well-Architected Reliability-checklist: Power Platform

RE:05 Vergroot de veerkracht van uw workload door foutafhandeling en kortstondige foutafhandeling te implementeren. Bouw mogelijkheden in de oplossing om onderdeelstoringen en kortstondige fouten op te lossen.

In deze gids worden de aanbevelingen beschreven voor het omgaan met kortstondige fouten in uw cloudtoepassingen. Alle toepassingen die communiceren met externe services en resources moeten gevoelig zijn voor kortstondige fouten. Dit geldt vooral voor toepassingen die in de cloud worden uitgevoerd, waar, vanwege de aard van de omgeving en de connectiviteit via internet, dit soort fouten waarschijnlijk vaker zullen voorkomen. Kortstondige fouten omvatten het tijdelijke verlies van netwerkconnectiviteit met onderdelen en services, de tijdelijke onbeschikbaarheid van een service en time-outs die optreden wanneer een service bezet is. Deze fouten corrigeren zichzelf vaak, dus als de actie na een passende vertraging wordt herhaald, is de kans groot dat deze slaagt.

Belangrijke ontwerpstrategieën

Kortstondige fouten kunnen in elke omgeving, op elk platform of besturingssysteem en in elke soort toepassing voorkomen.

Uitdagingen

Kortstondige fouten kunnen een aanzienlijk effect hebben op de waargenomen beschikbaarheid van een toepassing, zelfs als deze onder alle voorzienbare omstandigheden grondig is getest. Om ervoor te zorgen dat uw Power Platform-workload betrouwbaar kan functioneren, moet u ervoor zorgen dat deze kan reageren op de volgende uitdagingen:

  • De toepassing moet in staat zijn fouten te detecteren wanneer deze zich voordoen en te bepalen of de fouten waarschijnlijk van voorbijgaande aard, langdurig of fatale fouten zijn. Verschillende resources zullen waarschijnlijk verschillende reacties retourneren als er een fout optreedt, en deze reacties kunnen ook variëren afhankelijk van de context van de bewerking. Het antwoord op een fout wanneer de toepassing gegevens ophaalt uit een aangepaste connector kan bijvoorbeeld verschillen van het antwoord als de toepassing een cloudstroom uitvoert en op de respons wacht.

  • De toepassing moet de bewerking opnieuw kunnen proberen als wordt vastgesteld dat de fout waarschijnlijk van kortstondige aard is.

  • De toepassing moet gebruikmaken van een geschikte strategie voor nieuwe pogingen. De strategie specificeert het aantal keren dat de toepassing het opnieuw moet proberen, de vertraging tussen elke poging en de acties die moeten worden ondernomen na afloop van een mislukte poging. Het juiste aantal pogingen en de vertraging tussen elke poging zijn vaak moeilijk te bepalen. De strategie varieert afhankelijk van het type resource en van de huidige bedrijfsomstandigheden van de resource en de toepassing.

Algemene richtlijnen

De volgende richtlijnen kunnen u helpen bij het ontwerpen van geschikte mechanismen voor de afhandeling van kortstondige fouten voor uw toepassingen.

Bepalen of er een ingebouwd mechanisme voor opnieuw proberen bestaat

Sommige services waarmee u verbinding maakt, bieden mogelijk al een mechanisme voor kortstondige foutafhandeling. Het beleid voor opnieuw proberen wordt doorgaans afgestemd op de aard en vereisten van de doelservice. Als alternatief kunnen REST-interfaces voor services informatie retourneren die u kan helpen bepalen of een nieuwe poging passend is, en hoe lang u moet wachten voordat de volgende poging wordt uitgevoerd.

U moet het ingebouwde mechanisme voor opnieuw proberen gebruiken wanneer dit beschikbaar is, tenzij u te maken hebt met specifieke en goed begrepen vereisten die een ander gedrag voor opnieuw proberen geschikter maken.

Bepalen of de bewerking geschikt is om opnieuw te proberen

Voer alleen nieuwe pogingen uit als de fouten van kortstondige aard zijn (meestal aangegeven door de aard van de fout) en als er op zijn minst enige kans bestaat dat de bewerking zal slagen als deze opnieuw wordt geprobeerd. Het heeft geen zin om bewerkingen die een ongeldige bewerking proberen, opnieuw uit te voeren, zoals het bijwerken van een rij in Microsoft Dataverse die niet bestaat of waarvoor de gebruiker geen toestemming heeft, of het aanroepen van een API-eindpunt dat niet bestaat.

Implementeer nieuwe pogingen alleen als u het volledige effect hiervan kunt bepalen, en als de voorwaarden goed worden begrepen en kunnen worden gevalideerd. Houd er rekening mee dat de fouten die worden geretourneerd door resources en services waar u geen controle over heeft, in de loop der tijd kunnen evolueren, en dat u mogelijk uw logica voor kortstondige foutdetectie opnieuw moet bekijken.

Wanneer u afzonderlijke onderdelen of services ontwikkelt die vanuit uw toepassingen worden aangeroepen, zorg er dan voor dat u foutcodes en berichten retourneert waarmee clients kunnen bepalen of ze mislukte bewerkingen opnieuw moeten proberen. Overweeg om aan te geven of de client de bewerking opnieuw moet proberen, bijvoorbeeld door een isTransient-waarde te retourneren. Als u een webservice bouwt, kunt u overwegen aangepaste fouten te retourneren die zijn gedefinieerd in uw servicecontracten.

Een geschikt aantal nieuwe pogingen en een geschikt interval bepalen

Optimaliseer het aantal nieuwe pogingen en het interval voor het type gebruikersscenario. Als u het niet vaak genoeg opnieuw probeert, kan de toepassing de bewerking niet voltooien en zal deze waarschijnlijk mislukken. Als u het te vaak opnieuw probeert, of met een te kort interval tussen de pogingen, houdt de toepassing gedurende lange perioden mogelijk resources vast, wat een negatieve invloed heeft op de status van de toepassing.

Pas de waarden voor het tijdsinterval en het aantal nieuwe pogingen aan het type bewerking aan. Als de bewerking bijvoorbeeld deel uitmaakt van een gebruikersinteractie, moet het interval kort zijn en mogen slechts enkele nieuwe pogingen worden ondernomen. Door deze aanpak te gebruiken, kunt u voorkomen dat gebruikers op een respons moeten wachten. Als de bewerking deel uitmaakt van een langlopende of kritieke workflow, waarbij het annuleren en opnieuw starten van het proces duur of tijdrovend is, is het verstandig om langer te wachten tussen pogingen en het vaker opnieuw te proberen.

Houd er rekening mee dat het bepalen van de juiste intervallen tussen nieuwe pogingen het moeilijkste onderdeel is van het ontwikkelen van een succesvolle strategie. Typische strategieën gebruiken de volgende soorten interval voor een nieuwe poging:

  • Exponentieel interval. De toepassing wacht een korte tijd vóór de eerste nieuwe poging en verlengt vervolgens de tijd tussen elke volgende nieuwe poging exponentieel. Het kan de bewerking bijvoorbeeld na 3 seconden, 12 seconden, 30 seconden, enzovoort opnieuw proberen.

  • Vaste intervallen. De toepassing wacht tussen elke poging even lang.

  • Onmiddellijk opnieuw proberen. Soms is een kortstondige fout van korte duur, en is het verstandig om de bewerking onmiddellijk opnieuw uit te voeren, omdat deze kan slagen als de fout wordt verholpen in de tijd die de toepassing nodig heeft om de volgende aanvraag te verzenden. Er mag echter nooit meer dan één directe nieuwe poging worden ondernomen. U moet overstappen op alternatieve strategieën, zoals exponentieel interval of terugvalacties, als de directe nieuwe poging mislukt.

Gebruik als algemene richtlijn een exponentiële intervalstrategie voor achtergrondbewerkingen, en gebruik strategieën voor nieuwe pogingen met tussenliggende of vaste intervallen voor interactieve bewerkingen. In beide gevallen moet u de vertraging en het aantal nieuwe pogingen zo kiezen dat de maximale latentie voor alle nieuwe pogingen binnen de vereiste end-to-end latentievereiste valt.

Houd rekening met de combinatie van alle factoren die bijdragen aan de totale maximale time-out voor een nieuwe bewerking. Deze factoren zijn onder meer de tijd die nodig is voordat een mislukte verbinding een respons produceert, de vertraging tussen nieuwe pogingen en het maximale aantal nieuwe pogingen. Het totaal van al deze tijden kan resulteren in lange totale bewerkingstijden, vooral als u een exponentiële vertragingsstrategie gebruikt waarbij het interval tussen nieuwe pogingen snel toeneemt na elke fout. Als een proces moet voldoen aan een specifieke Service Level Agreement (SLA), moet de totale bewerkingstijd, inclusief alle time-outs en vertragingen, binnen de limieten liggen die in de SLA zijn gedefinieerd.

Implementeer geen al te agressieve strategieën voor nieuwe pogingen. Dit zijn strategieën met te korte intervallen of te frequente nieuwe pogingen. Ze kunnen een negatief effect hebben op de doelresource of -dienst. Deze strategieën kunnen voorkomen dat de resource of service herstelt van de overbelaste status, en daarom aanvragen blijven blokkeren of weigeren. Dit scenario resulteert in een vicieuze cirkel, waarbij steeds meer aanvragen naar de resource of service worden verzonden. Het herstelvermogen wordt daardoor verder verminderd.

Houd rekening met de time-out van de bewerkingen wanneer u intervallen voor nieuwe pogingen kiest, om te voorkomen dat u onmiddellijk een volgende poging start (bijvoorbeeld als de time-outperiode vergelijkbaar is met het interval voor nieuwe pogingen).

Gebruik het type fout of de foutcodes en berichten die door de service worden geretourneerd om het aantal nieuwe pogingen en het interval daartussen te optimaliseren. Sommige uitzonderingen of foutcodes (zoals de HTTP-code 503, Service niet beschikbaar, met een Retry-After-header in het antwoord) kunnen bijvoorbeeld aangeven hoe lang de fout kan duren, of dat de service is mislukt en niet zal reageren op een volgende poging.

Antipatronen vermijden

Vermijd in de meeste gevallen implementaties die dubbele lagen met code voor nieuwe pogingen bevatten. Vermijd ontwerpen die trapsgewijze mechanismen voor opnieuw proberen bevatten of die nieuwe pogingen implementeren in elke fase van een bewerking waarbij een hiërarchie van aanvragen betrokken is, tenzij u daarvoor specifieke vereisten hebt ingesteld. Gebruik in deze uitzonderlijke omstandigheden beleid dat buitensporige aantallen nieuwe pogingen en vertragingsperioden voorkomt, en zorg ervoor dat u de gevolgen begrijpt. Stel bijvoorbeeld dat het ene onderdeel een aanvraag indient bij de andere, die vervolgens toegang krijgt tot de doelservice. Als u voor beide oproepen een nieuwe poging implementeert met een telling van drie, zijn er in totaal negen nieuwe pogingen voor de service. Veel services en resources implementeren een ingebouwd mechanisme voor nieuwe pogingen. U moet onderzoeken hoe u deze mechanismen kunt uitschakelen of wijzigen als u nieuwe pogingen op een hoger niveau moet implementeren.

Implementeer nooit een mechanisme voor eindeloos opnieuw proberen. Als u dit wel doet, voorkomt u waarschijnlijk dat de resource of service zich herstelt van overbelastingssituaties en dat de beperking en geweigerde verbindingen langere tijd aanhouden.

Voer nooit meer dan één keer een directe nieuwe poging uit.

Vermijd het gebruik van een vast interval voor nieuwe pogingen wanneer u toegang krijgt tot services en resources in Azure, vooral als u een groot aantal nieuwe pogingen hebt ingesteld. De beste aanpak in dit scenario is een exponentiële intervalstrategie.

Uw strategie en implementatie testen voor nieuwe pogingen

Test uw strategie voor nieuwe pogingen volledig onder een zo breed mogelijke reeks omstandigheden, vooral wanneer zowel de toepassing als de bronresources of -services die deze strategie toepassen, onder extreme belasting staan. Om het gedrag tijdens het testen te controleren, kunt u:

  • Tijdelijke en niet-tijdelijke fouten in de service introduceren. Stuur bijvoorbeeld ongeldige aanvragen of voeg code toe die testverzoeken detecteert en reageert met verschillende soorten fouten.

  • Maak een model van de resource of service die een reeks fouten retourneert die de echte service zou kunnen retourneren. Handel alle soorten fouten af die uw strategie voor nieuwe pogingen moet detecteren.

  • Voor aangepaste services die u maakt en implementeert, forceert u kortstondige fouten door de service tijdelijk uit te schakelen of te overbelasten. (Probeer geen gedeelde resources of gedeelde services in Azure te overbelasten.)

  • Wanneer u de veerkracht van een clientwebtoepassing test op tijdelijke fouten, gebruikt u de ontwikkelaarstools van de browser of de mogelijkheid van uw testframework om netwerkaanvragen te stimuleren of blokkeren.

  • Voer tests met een hoge belastingsfactor en gelijktijdige tests uit om ervoor te zorgen dat het mechanisme en de strategie voor nieuwe pogingen onder deze omstandigheden correct werken. Deze tests helpen er ook voor te zorgen dat de nieuwe poging geen negatief effect heeft op de werking van de client of kruisbesmetting tussen aanvragen veroorzaakt.

Beleidsconfiguraties voor opnieuw proberen beheren

Een beleid voor opnieuw proberen is een combinatie van alle elementen van uw strategie voor nieuwe pogingen. Het definieert het detectiemechanisme dat bepaalt of een fout waarschijnlijk van voorbijgaande aard is, het type interval dat moet worden gebruikt (zoals vast of exponentieel), de werkelijke intervalwaarden en het aantal keren dat opnieuw moet worden geprobeerd.

Profiteer van ingebouwde of standaardstrategieën voor nieuwe pogingen, maar alleen als deze geschikt zijn voor uw scenario. Deze strategieën zijn doorgaans generiek. In sommige scenario's voldoen ze misschien, maar in andere scenario's bieden ze niet het volledige scala aan opties om aan uw specifieke vereisten te voldoen. Om de meest geschikte waarden te bepalen, moet u tests uitvoeren om te begrijpen hoe de instellingen uw toepassing beïnvloeden.

Tijdelijke en niet-kortstondige fouten registreren en bijhouden

Als onderdeel van uw strategie voor opnieuw proberen, moet u de afhandeling van uitzonderingen en andere instrumentatie opnemen die nieuwe pogingen registreren. Er wordt af en toe een kortstondige fout en een nieuwe poging verwacht, wat niet op een probleem duidt. Regelmatige en toenemende aantallen nieuwe pogingen zijn echter vaak een indicatie van een probleem dat een fout kan veroorzaken of dat de prestaties en beschikbaarheid van toepassingen verslechtert.

Registreer tijdelijke fouten als waarschuwingsvermeldingen in plaats van als foutinvoer, zodat bewakingssystemen deze niet detecteren als toepassingsfouten die valse waarschuwingen kunnen veroorzaken.

Overweeg een waarde in uw logboekvermeldingen op te slaan die aangeeft of nieuwe pogingen worden veroorzaakt door beperking van de service of door andere soorten fouten, zoals verbindingsfouten, zodat u deze kunt onderscheiden tijdens de analyse van de gegevens. Een toename van het aantal aanvraagbeperkingsfouten is vaak een indicator van een ontwerpfout in de toepassing of de noodzaak om premiumcapaciteit aan de omgeving toe te voegen.

Overweeg de implementatie van een telemetrie- en monitoringsysteem dat waarschuwingen kan genereren wanneer het aantal en de frequentie van fouten, het gemiddelde aantal nieuwe pogingen of de totale tijd die verstrijkt voordat de bewerking slaagt, toeneemt.

Activiteiten die voortdurend mislukken beheren

Bedenk hoe u moet omgaan met bewerkingen die bij elke poging blijven mislukken. Dit soort situaties zijn onvermijdelijk.

Hoewel een strategie voor opnieuw proberen het maximale aantal keren definieert dat een bewerking opnieuw moet worden gestart, verhindert deze strategie niet dat de toepassing de bewerking herhaalt met hetzelfde aantal nieuwe pogingen. Als u bijvoorbeeld een formulier in uw aanvraag indient, kan er een stroom worden geactiveerd. De strategie voor opnieuw proberen kan een time-out voor de verbinding detecteren en beschouwen als een kortstondige fout. De stroom zal de bewerking een bepaald aantal keren opnieuw proberen en vervolgens opgeven. Wanneer dezelfde of een nieuwe gebruiker het formulier echter opnieuw probeert te verzenden, wordt de bewerking opnieuw geprobeerd, ook al blijft deze mogelijk mislukken.

De toepassing kan de service periodiek testen, met tussenpozen en met lange intervallen tussen aanvragen, om te detecteren wanneer deze beschikbaar komt. Een geschikt interval hangt af van factoren als de kriticiteit van de bewerking en de aard van de service. Het interval kan van alles zijn tussen een paar minuten en enkele uren. Wanneer de test slaagt, kan de toepassing de normale werking hervatten en aanvragen doorgeven aan de zojuist herstelde service.

In de tussentijd kunt u mogelijk een aantal alternatieve bewerkingen uitvoeren, in de hoop dat de service binnenkort beschikbaar komt. Het kan bijvoorbeeld passend zijn om aanvragen voor de service op te slaan in een wachtrij of gegevensopslag, en deze later opnieuw te proberen. Of mogelijk moet u een bericht terugsturen naar de gebruiker om aan te geven dat de toepassing niet beschikbaar is.

Overige overwegingen

Wanneer u de waarden voor het aantal nieuwe pogingen en de intervallen voor nieuwe pogingen voor een beleid bepaalt, moet u overwegen of de bewerking op de service of resource deel uitmaakt van een langdurige of uit meerdere stappen bestaande bewerking. Het kan moeilijk of duur zijn om alle andere operationele stappen die al succesvol zijn geweest te compenseren als er één mislukt. In dit geval kunnen een lang interval en een groot aantal nieuwe pogingen acceptabel zijn, zolang die strategie andere bewerkingen niet blokkeert door schaarse resources vast te houden of te vergrendelen.

Bedenk of het opnieuw proberen van dezelfde bewerking inconsistenties in de gegevens kan veroorzaken. Als sommige delen van een uit meerdere stappen bestaand proces worden herhaald, en de bewerkingen niet idempotent zijn, kunnen er inconsistenties optreden. Als bijvoorbeeld een bewerking die een record in Microsoft Dataverse invoegt, wordt herhaald, kan dit tot onjuiste waarden in de tabel leiden. Of als u een bewerking herhaalt waarbij een melding naar de gebruiker wordt verzonden, ontvangt deze gebruiker mogelijk dubbele berichten.

Houd rekening met de reikwijdte van de bewerkingen die opnieuw worden geprobeerd. Het kan bijvoorbeeld eenvoudiger zijn om code voor opnieuw proberen te implementeren op een niveau dat meerdere bewerkingen omvat, en deze bewerkingen allemaal opnieuw uit te proberen als er één mislukt. Als u dit wel doet, kan dit echter leiden tot idempotentieproblemen of onnodige terugdraaibewerkingen.

Als u een bereik voor nieuwe pogingen kiest dat verschillende bewerkingen omvat, moet u rekening houden met de totale latentie van al deze bewerkingen wanneer u de intervallen voor nieuwe pogingen bepaalt, wanneer u de verstreken tijden van de bewerking bewaakt en voordat u waarschuwingen voor fouten genereert.

Power Platform faciliteren

In de volgende secties worden de mechanismen beschreven die u kunt toepassen om kortstondige fouten te beheren.

Power Automate

Power Automate bevat een functie om een ​​actie opnieuw uit te laten voeren als deze mislukt. Configureer dit op het niveau van een afzonderlijke actie. Leer hoe u risico's kunt beperken en hoe u kunt plannen voor foutbehandeling in een Power Automate project. Power Automate biedt ook acties om aangepaste fouten en gegevens terug te sturen naar de app of stroom die de aanroep doet.

Sommige tijdelijke stromen kunnen worden veroorzaakt door doorvoer- en aanvraaglimieten. Meer informatie over de limieten van geautomatiseerde, geplande en directe stromen en verzoeklimieten en toewijzingen.

Configureer fout- en uitzonderingsafhandeling in cloudstromen met behulp van scopes en run-after-instellingen.

Power Apps

Canvas-apps in Power Apps bieden de mogelijkheid om de verbindingsstatus te controleren, waardoor ze zich anders kunnen gedragen als de app offline is. Leer hoe u offline canvas-apps ontwikkelt.

U kunt ook de functies Error, IfError, IsError en IsBlankOrError in canvas-apps gebruiken om te beslissen wat u vervolgens moet doen als er een fout optreedt.

Meer informatie over de afhandeling van tijdelijke fouten in Power Apps:

Azure- en aangepaste connectors

Als uw workload verbinding maakt met Azure-services, vindt u hier meer informatie over hoe u tijdelijke fouten kunt afhandelen met behulp van het Azure Well-Architected Framework.

Als u aangepaste connectorreacties op fouten wilt beheren, volgt u coderingsnormen.

Application Insights

Gebruik de Application Insights-integraties om fouten te loggen in Power Automate en Power Apps:

Bedrijfscontinuïteit en noodherstel voor Dynamics 365 SaaS-apps

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige reeks aanbevelingen.

Controlelijst betrouwbaarheid