Udostępnij za pośrednictwem

Rekomendacje dotyczące obsługi błędów przejściowych

  • Artykuł

Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej niezawodności Well-Architected Reliability:

RE:05 Wzmacnianie odporności obciążenia przez implementowanie obsługi błędów i błędów przejściowych. Funkcje należy tworzyć w rozwiązaniu w celu obsługi awarii składników i błędów przejściowych.

Ten przewodnik opisuje rekomendacje dotyczące obsługi błędów przejściowych w aplikacjach w chmurze. Wszystkie aplikacje, które komunikują się ze zdalnymi usługami i zasobami, muszą być wrażliwe na błędy przejściowe. Jest to przydatne w przypadku aplikacji uruchamianych w chmurze, gdzie ze względu na charakter środowiska i łączność za pośrednictwem Internetu ten typ awarii prawdopodobnie będzie spotykany częściej. Błędy przejściowe obejmują chwilową utratę połączeń sieciowych ze składnikami i usługami, tymczasową niedostępność usługi oraz przekroczenia limitów czasu, które występują podczas intensywnej pracy usługi. Te błędy często się poprawiają, więc jeśli akcja zostanie powtórzona po odpowiedniej opóźnieniu, prawdopodobnie się powiedzie.

Kluczowe strategie projektowania

Błędy przejściowe mogą występować w dowolnym środowisku, na dowolnej platformie lub w systemie operacyjnym i w każdym typie aplikacji.

Wyzwania

Błędy przejściowe mogą mieć znaczący wpływ na ograniczoną dostępność aplikacji, nawet jeśli została dokładnie przetestowana w wszystkich okolicznościach. Aby upewnić się, że obciążenie Power Platform może działać prawidłowo, należy się upewnić, że może ona odpowiadać na następujące problemy:

  • Aplikacja musi być w stanie wykrywać błędy podczas ich wystąpienia i określić, czy prawdopodobne są przejściowe, długotrwałe czy ostateczne. Różne zasoby prawdopodobnie zwracają różne odpowiedzi w momencie wystąpienia zdarzeń, a odpowiedzi te mogą się różnić w zależności od kontekstu operacji. Na przykład odpowiedź na błąd podczas pobierania przez aplikację danych z łącznika niestandardowego może być inna niż odpowiedź, gdy aplikacja uruchamia przepływ chmury i oczekuje na odpowiedź.

  • Aplikacja musi mieć możliwość ponownego wykonania operacji, jeśli ustali, że błąd jest prawdopodobne przejściowy.

  • Aplikacja musi używać odpowiedniej strategii na potrzeby ponownych prób. Strategia określa liczbę razy, kiedy aplikacja powinna ponowić próbę, opóźnienie między każdą próbą i akcje do podjęcia po nieudanej próbie. Często trudno jest określić odpowiednią liczbę prób i opóźnienie między nimi. Strategia zależy od typu zasobu oraz bieżących warunków działania zasobu i aplikacji.

Wytyczne ogólne

Poniższe wytyczne mogą ułatwić projektowanie odpowiednich mechanizmów obsługi aplikacji.

Określanie, czy jest wbudowany mechanizm ponawiania prób

Niektóre usługi, z które się łączysz, mogą już stanowić mechanizm obsługi błędów przejściowych. Używane zasady ponawiania jest zwykle dostosowana do charakteru i wymagań usługi docelowej. Alternatywnie, interfejsy REST dla usług mogą zwracać informacje, które mogą pomóc w określeniu, czy i jak długo należy poczekać przed kolejną próbą.

Gdy jest on dostępny, należy użyć wbudowanego mechanizmu ponawiania, chyba że są spełnione określone i dobrze zrozumiałe wymagania, które bardziej odpowiedniego zachowania ponawiania.

Określ, czy operacja jest odpowiednia do ponownego wykonania

Operacje ponowione należy wykonać tylko wtedy, gdy błędy są przejściowe (zazwyczaj wskazane przez charakter błędu) i jeśli istnieje co najmniej prawdopodobieństwo, że operacja zakończy się pomyślnie po kolejnej operacji. Nie ma sensu ponawianie nieprawidłowej operacji, takiej jak aktualizowanie nieistniejącego wiersza Microsoft Dataverse lub do którego użytkownik nie ma uprawnień, albo wywoływanie nieistniejącego punktu końcowego interfejsu API.

Implementacja jest dostępna tylko wtedy, gdy można określić pełny efekt tej operacji oraz jeśli warunki są dobrze zrozumiałe i można je sprawdzić. Należy pamiętać, że błędy zwracane z zasobów i usług poza kontrolą mogą rozwinąć się w czasie i może okazać się konieczny powrót do logiki wykrywania błędów.

Podczas opracowywania poszczególnych składników lub usług wywoływanych z aplikacji należy zwrócić kody błędów i komunikaty pomocne przy ustalaniu, czy klienci mają ponowić operacje, których nie można wykonać. Rozważ wskazanie, czy klient ma ponowić operację, na przykład przez zwrócenie wartości isTransient. Podczas tworzenia usługi internetowej należy rozważyć zwrócenie błędów niestandardowych zdefiniowanych w kontraktach usługowych.

Określenie odpowiedniej liczby i interwału ponowień

Zoptymalizuj liczbę ponowień i interwał dla typu przykładu użycia. Jeśli wykonasz wystarczającej liczby ponowień, aplikacja nie może ukończyć operacji i prawdopodobnie zakończy się niepowodzeniem. Jeśli ponowisz próbę zbyt wiele razy lub jeśli interwały między kolejnymi próbami będą zbyt krótkie, aplikacja może przechowywać zasoby przez dłuższy okres, co może mieć niekorzystny wpływ na stan aplikacji.

Zaadaptuj wartości odstępu czasu i liczbę ponowień prób do typu operacji. Jeśli na przykład operacja jest częścią interakcji z użytkownikiem, interwał powinien być krótki i należy spróbować kilku różnych operacji. Korzystając z tego podejścia, można uniknąć oczekiwania użytkowników na odpowiedź. Jeśli operacja jest częścią długiego lub ważnego przepływu pracy, gdzie anulowanie i ponowne uruchomienie procesu jest drogie lub czasochłonne, należy poczekać dłużej między próbami i ponowić próbę.

Należy pamiętać, że określenie odpowiednich odstępów czasu między poszczególnymi elementami jest trudne w przypadku projektowania pomyślnie udanej strategii. Typowe strategie używają następujących typów interwałów ponawiania:

  • Interwał wykładniczy. Aplikacja oczekuje na krótki czas przed pierwszą ponowną próbą, a następnie zwiększa czas między kolejnymi próbami. Na przykład może ona wykonać operację po 3 sekundach, 12 sekundach i 30 sekundach itp.

  • Stałe interwały. Między każdą próbą aplikacja oczekuje na ten sam okres.

  • Natychmiastowe ponawianie próby. Czasami błąd przejściowy jest krótki i konieczne jest natychmiastowe ponowienie operacji, ponieważ może się ona zakończyć pomyślnie, jeśli błąd zostanie usunięty w czasie, gdy konieczne jest wysłanie następnego żądania przez aplikację. Nie należy jednak podejmować więcej niż jednej bezpośredniej ponownej próby. Jeśli bezpośrednia ponowna próba zakończy się niepowodzeniem, należy przejść do alternatywnych strategii, takich jak interwał wykładniczy lub akcje rezerwowe.

Ogólne wytyczne mówią, że należy użyć strategii interwału wykładniczego dla operacji w tle oraz użyć strategii natychmiastowego ponowienia lub stałego interwału dla operacji interaktywnych. W obu przypadkach należy wybrać opóźnienie i liczbę ponowień, aby maksymalny limit ponownych prób dla wszystkich prób pozostał w obrębie kompleksowych wymagań dotyczących opóźnienia.

Należy rozważyć kombinację wszystkich czynników, które wpływają na ogólny maksymalny limit czasu ponowionej operacji. Czynniki te obejmują czas, przez który niepowodzenie połączenia wymaga reakcji, opóźnienie między ponownymi próbami i maksymalną liczbę operacji. Suma tych wszystkich czasów może powodować długie ogólne czasy operacji, zwłaszcza gdy jest używana strategia opóźnienia wykładniczego, w której odstęp między kolejnymi operacjami rozwija się szybko po każdej awarii. Jeśli proces musi spełniać określoną umowę na poziomie usługi (SLA), ogólny czas operacji, w tym wszystkie limity czasu i opóźnienia, musi znajdować się w limitach zdefiniowanych w umowie SLA.

Nie implementuj zbyt agresywnej strategii ponawiania prób. Są to strategie z interwałami, które są zbyt krótkie, lub zbyt częstymi próbami. Mogą one mieć niekorzystny wpływ na docelowe zasoby lub usługi. Takie strategie mogą uniemożliwić zasoby lub usługi do odzyskiwania po przeciążeniu stanu i nadal będą blokować lub odrzucać żądania. W tym scenariuszu powstaje błędne koło, w którym do zasobu lub usługi jest wysyłanych coraz więcej żądań. W konsekwencji możliwość odzyskiwania jest dalej pomniejszana.

Rozważ limit czasu operacji, jeśli wybierzesz interwały ponawiania prób, aby uniknąć natychmiastowego uruchomienia kolejnej próby (na przykład jeśli okres limitu czasu jest podobny do interwału ponawiania prób).

Użyj typu błędu lub kodów błędów i komunikatów zwróconych z usługi w celu zoptymalizowania liczby wystąpień i interwału między nimi. Na przykład niektóre wyjątki lub kody błędów (na przykład kod HTTP 503, Usługa jest niedostępna, z nagłówkiem odpowiedzi Ponów po) może wskazywać czas działania błędu lub niepowodzenie usługi i nie zareagować na kolejne próby.

Unikanie antywzorców

W większości przypadków należy unikać implementacji, które zawierają zduplikowane warstwy kodu ponawiania. Należy unikać projektów, które zawierają kaskadowe mechanizmy ponowień lub implementują ponowienie na każdym etapie operacji obejmującym hierarchię żądań, chyba że są spełnione określone wymagania. W tych wyjątkowo okolicznościach należy stosować zasady, które zapobiegają nadmiernego liczbie zmian i okresów opóźnieniem oraz mają pewność, że rozumieją państwo konsekwencje. Można na przykład jeden składnik zażądać od innego składnika, który następnie uzyskuje dostęp do usługi docelowej. Jeśli zaimplementowano trzy ponowne próby w obydwu wywołaniach, w sumie w przypadku usługi należy wykonać dziewięć ponownych prób. Wiele usług i zasobów implementuje wbudowany mechanizm ponowiania próby. Jeśli konieczne jest wdrożenie aplikacji na wyższym poziomie, należy sprawdzić, w jaki sposób można wyłączyć lub zmodyfikować te mechanizmy.

Nigdy nie należy implementować mechanizmu nieskończonego ponawiania prób. Prawdopodobnie uniemożliwi to sytuację, w której zasoby lub usługi nie będą mogły odzyskać zasobów i usług w sytuacjach przeciążenia, a problemy z połączeniami będą kontynuowane przez dłuższy czas.

Nigdy nie należy przeprowadzać natychmiastowej ponownej próby więcej niż raz.

Należy unikać używania stałego interwału ponowień podczas uzyskiwania dostępu do usług i zasobów na platformie Azure, zwłaszcza gdy masz dużą liczbę ponowień prób. Najlepszym podejściem w tym scenariuszu jest strategia interwału wykładniczego.

Testowanie strategii i implementacji ponowień

Przetestuj swoją strategię ponowione w możliwie najszerszej sytuacji, zwłaszcza gdy zarówno aplikacja, jak i zasoby docelowe i używane przez nie usługi są pod bardzo dużym obciążeniem. Aby sprawdzić zachowanie podczas testowania, można:

  • Wstrzyknąć błędy przejściowe i inne do usługi. Na przykład można wysłać nieprawidłowe żądania lub dodać kod, który wykrywa żądania testowe i odpowiada na różne typy błędów.

  • Utwórz zasoby lub usługi, które zwracają zakres błędów, które może zwrócić usługa rzeczywista. Obejmują wszystkie typy błędów, które ma wykrywać Twoja strategia ponawiania.

  • W przypadku niestandardowych usług, które zostały utworzone i wdrożone, należy wymusić wystąpienie błędów przejściowych przez tymczasowe wyłączenie lub przeciążenie usługi. (Nie należy przeciążać żadnych udostępnionych zasobów ani usług udostępnionych na platformie Azure).

  • Podczas testowania odporności klienckiej aplikacji internetowej na błędy przejściowe należy użyć funkcji narzędzi deweloperskich przeglądarki lub programu testowego w celu pozorowania lub blokowania żądań sieciowych.

  • Wykonaj testy z wysokim obciążeniem i jednoczesne testy, aby upewnić się, że mechanizm i strategia ponawiania działają poprawnie w tych warunkach. Te testy pomagają również zagwarantować, że ponawianie nie wpływa negatywnie na działanie klienta ani nie powoduje wzajemnych błędów między żądaniami.

Zarządzanie konfiguracjami zasad ponawiania

Zasady ponawiania to kombinacja wszystkich elementów strategii ponownej próby. Definiuje mechanizm wykrywania, który określa, czy błąd może być przejściowy, typ interwału do użycia (np. stały lub wykładniczy), wartości rzeczywistych interwałów i liczbę ponownych prób.

Można korzystać z wbudowanych lub domyślnych strategii ponownej próby, ale tylko wtedy, gdy są one odpowiednie dla scenariusza. Strategie te są zazwyczaj ogólne. W niektórych scenariuszach mogą być one wszystkie potrzebne, ale w innych scenariuszach nie oferują pełnego zakresu opcji dostępnych w celu użycia określonych wymagań. Aby określić najbardziej odpowiednie wartości, należy przetestować, aby sprawdzić, jaki wpływ mają ustawienia na aplikację.

Rejestrowanie i śledzenie błędów przejściowych i nieprzejściowych

W ramach strategii ponownej próby należy uwzględnić obsługę wyjątków i inną instrumentację, która rejestruje próby ponownego wykonania. Okresowe błędy przejściowe i ponowienia są oczekiwane i nie wskazują na problem. Regularna i zwiększana liczba ponownych prób jest jednak często wskaźnikiem problemu, który może spowodować niepowodzenie lub spowodować spadek wydajności i dostępności aplikacji.

Rejestruj błędy przejściowe jako wpisy ostrzegawcze, a nie jako wpisy błędów, dzięki czemu systemy monitorowania nie wykryje ich jako błędów aplikacji, które mogą wyzwalać fałszywe alerty.

Należy rozważyć przechowywanie w wpisach dziennika wartości wskazującej, czy ponowne próby są powodowane przez usługi, czy przez inne typy błędów, np. niepowodzenia połączenia, aby można było je rozróżniać podczas analizy danych. Zwiększenie liczby błędów ograniczania jest często wskaźnikiem błędu projektowego w aplikacji lub konieczności dodania wydajności Premium do środowiska.

Należy rozważyć wdrożenie systemu telemetrycznego i monitorowania, które może podsyłać alerty w momencie, gdy liczba i wskaźnik awarii, średnia liczba operacji lub ogólny czas wykonania operacji przed wykonaniem operacji zwiększa się.

Zarządzanie operacjami, w których stale występują błędy

Rozważ sposób obsługi operacji, które nadal są wykonywane z niepowodzeniem przy każdej próbie. Sytuacje, których to dotyczy, są nieuniknione.

Mimo że strategia ponawiania definiuje maksymalną liczbę razy, jaka ma być ponowiona operacja, nie zapobiega to powtarzaniu operacji przez aplikację przy użyciu tej samej liczby ponownych prób. Na przykład wysłanie formularza w aplikacji może spowodować przepływ pracy. Strategia ponawiania może wykryć limit czasu połączenia i uznać to za błąd przejściowy. Przepływ będzie ponawiać operację określoną liczbę razy, a następnie podda się. Jednak jeśli ten sam lub nowy użytkownik spróbuje przesłać formularz ponownie, operacja jest próbowana ponownie, nawet jeśli operacja może się nie powieść.

Aplikacja może okresowo testować usługę, sporadycznie i w długiej odstępach czasu między żądaniami, aby wykrywać jej dostęp. Odpowiedni interwał zależy od czynników, takich jak krytyczność operacji i charakter usługi. To wszystko może trwać od kilku minut do kilku godzin. Jeśli test zakończy się pomyślnie, aplikacja może wznowić normalne operacje i przekazać żądania do nowo utworzonej usługi.

W tym czasie może być możliwe wykonanie pewnych alternatywnych operacji w oparciu o nadzieję, że usługa będzie dostępna wkrótce. Na przykład może się okazać, że żądania usługi będą przechowywane w kolejce lub w magazynie danych, i można później ponowić próbę. Może też być konieczne zwrócenie do użytkownika komunikatu o tym, że aplikacja jest dostępna.

Inne kwestie wymagające rozważenia

Podczas decydowania o wartościach liczby ponownych prób i długości kolejnych interwałów dla zasad należy określić, czy operacja w ramach usługi lub zasobu jest częścią operacji długotrwałej, czy wieloetapowej. Może być trudne lub drogie do zrekompensowania dla wszystkich innych kroków operacyjnych, które udało się już wykonać w przypadku awarii. W tym przypadku długie odstępy czasu i duża liczba zasobów może być dopuszczalna, jeśli strategia ta nie blokuje innych operacji przez wstrzymanie lub zablokowanie zasobów.

Należy rozważyć, czy ponowna próba tej samej operacji może spowodować niespójności w danych. Jeśli niektóre części procesu wieloetapowego zostaną powtórzone i operacje nie będą idempotentne, mogą wystąpić niespójności. Jeśli na przykład operacja wstawiania rekordu do Microsoft Dataverse zostanie powtórzona, może to spowodować nieprawidłowe wartości w tabeli. Jeśli powtórzysz operację wysyłaną do użytkownika, może on otrzymać zduplikowane wiadomości.

Należy wziąć pod uwagę zakres operacji wykonywanych ponownie. Na przykład łatwiej jest zaimplementować ponownie kod na poziomie obejmującym kilka operacji i ponowić wszystkie w razie awarii. Może to jednak powodować problemy z identyfikatorem lub niepotrzebnymi operacjami wycofywania.

W przypadku wybrania zakresu ponowień obejmującego kilka operacji należy rozważyć sumę różnych operacji przy ustalaniu ponowień odstępów czasu, monitorowaniu czasu operacji i przed podjęciem alertów o niepowodzeniach.

Ułatwienia Power Platform

W poniższych sekcjach przedstawiono mechanizmy, których można używać do zarządzania błędami przejściowymi.

Power Automate

Power Automate zawiera funkcję ponownego wykonania akcji, jeśli akcja nie powiedzie się. Należy skonfigurować tę usługę na poziomie każdej z akcji. Dowiedz się, jak zmniejszyć ryzyko i zaplanować obsługę błędów w Power Automate projekcie. Power Automate oferuje również akcje służące do zwracania niestandardowych błędów i danych do aplikacji lub przepływu wywołującego.

Niektóre przepływy przejściowe mogą być powodowane przez przepływność i ograniczenia żądań. Dowiedz się o ograniczeniach przepływów automatycznych, zaplanowanych i natychmiastowych oraz o limitach i alokacjach żądań.

Konfigurowanie obsługi błędów i wyjątków w przepływach w chmurze przy użyciu zakresów i ustawień uruchamiania.

Power Apps

Aplikacje kanwy Power Apps zapewniają możliwość sprawdzania stanu połączenia, co pozwala im zachowywać się inaczej, jeśli aplikacja jest w trybie offline. Dowiedz się, jak tworzyć aplikacje kanwy z obsługą trybu offline.

Możesz również używać funkcji Error, IfError, IsError i IsBlankOrError w aplikacjach kanwy, aby zdecydować, co zrobić w przypadku wystąpienia błędu.

Więcej informacji o obsłudze błędów przejściowych w Power Apps::

Azure i łączniki niestandardowe

Jeśli Twoje obciążenie łączy się z usługami Azure, dowiedz się, jak obsługiwać błędy przejściowe w dobrze zaprojektowanym środowisku platformy Azure.

Aby zarządzać odpowiedziami łącznika niestandardowego na błędy, należy postępować zgodnie ze standardami kodowania.

Application Insights

Korzystaj z integracji Application Insights w celu rejestrowania błędów w Power Automate i Power Apps:

Ciągłość działania i odzyskiwanie po awarii dla aplikacji Dynamics 365 SaaS

Lista kontrolna niezawodności

Zapoznaj się z kompletną zestawem zaleceń.

Lista kontrolna niezawodności