Próby ponawiane przez agenta mnożą się po ponownym połączeniu, gdy kilku klientów, warstw workflow i operacji oczekujących w kolejce interpretuje tę samą awarię jako pozwolenie na kolejną próbę.
Agent domowy może podczas jednego planu wywoływać interfejs API serwera NAS, most inteligentnego domu, narzędzie przeglądarki i kolejkę komunikatów. Gdy Wi-Fi lub router wróci do działania, biblioteka klienta, opakowanie narzędzia, silnik workflow i interfejs użytkownika mogą każdy uruchomić ponowienie. Niepewność co do ukończenia, zsynchronizowane timery, buforowane zdarzenia i brak kluczy idempotencji zmieniają jeden przerwany krok w kilka pozornie prawidłowych prób.
Niezależne warstwy ponawiania mnożą jedną nieudaną operację
Żądanie agenta może przechodzić przez bramę, planistę, adapter narzędzia, bibliotekę HTTP i usługę urządzenia. Jeśli trzy warstwy dopuszczają po trzy próby, operacja po stronie docelowej może zobaczyć znacznie więcej niż trzy wywołania, ponieważ budżety ponowień składają się multiplikatywnie, a nie addytywnie.
wzmocnienie ponowień w warstwach wyjaśnia, jak ponowienia zwiększają obciążenie już przeciążonej zależności oraz dlaczego wykładnicze wycofywanie, jitter, limity czasu i jeden punkt ponawiania ograniczają to wzmocnienie. Wskazówki te bezpośrednio odnoszą się do stosów agentów z ukrytymi ponowieniami w bibliotekach klientów.
Ponowne połączenie często usuwa błąd transportu, ale nie usuwa oczekujących timerów ani dostaw z kolejki. Każda warstwa budzi się z niepełną wiedzą o pozostałych, dlatego centralne identyfikatory żądań i jeden wspólny budżet ponowień są bardziej niezawodne niż niezależne konfigurowanie podobnych zasad.
Przerwane połączenie ukrywa informację, czy narzędzie zadziałało
Odpowiedź może zostać utracona po ukończeniu działania przez serwer, ale przed otrzymaniem potwierdzenia przez agenta. Ponowienie odczytu jest zwykle nieszkodliwe; ponowienie odblokowania drzwi, wysłania powiadomienia, przeniesienia pliku lub działania przypominającego zakup może powtórzyć rzeczywisty efekt uboczny.
idempotentne identyfikatory żądań wykorzystują identyfikatory idempotencji dostarczane przez wywołującego, aby usługa mogła rozpoznać powtórzone żądania i zwrócić pierwotny wynik zamiast wykonywać działanie dwukrotnie. Pozwala to odróżnić bezpieczne odzyskiwanie od zwykłego ponownego wysłania tego samego ładunku.
Workflow musi zachować identyfikator operacji, cel, argumenty, stan próby i potwierdzony wynik podczas przerwy w sieci. Wygenerowanie nowego identyfikatora wywołania narzędzia po ponownym połączeniu uniemożliwia deduplikację, ponieważ usługa docelowa widzi nową operację, a nie kontynuację.
Zsynchronizowane odzyskiwanie może przerodzić się w burzę ponowień
Wiele urządzeń wykrywa tę samą przywróconą krawędź sieci i ponownie łączy się w ciągu kilku sekund. Bez losowego opóźnienia i kontroli przyjmowania ich oczekujące żądania agentów, subskrypcje i kontrole kondycji powodują skok obciążenia dokładnie wtedy, gdy usługi odbudowują stan.
Rozdział ograniczania obciążenia podczas odzyskiwania opisuje awarię kaskadową, gdy ponowienia, wyczerpanie zasobów i ruch związany z odzyskiwaniem wzajemnie się wzmacniają. Zaleca ograniczanie pracy, odrzucanie nadmiarowego obciążenia i testowanie zachowania pod przeciążeniem zamiast zakładania, że przywrócona zależność może od razu przyjąć całą zaległość.
Granica awarii polega na używaniu wycofywania jako substytutu bezpieczeństwa operacji. Jitter rozprasza wywołania, ale nie zapobiega powielaniu efektów ubocznych, a idempotencja nie sprawia, że nieaktualne działanie staje się pożądane. Przed odtworzeniem należy ponownie zweryfikować wygasłą intencję, bieżące uprawnienia i stan celu.
Przeprowadź test odtwarzania po ponownym połączeniu
Rozpocznij dziesięciostopniowy workflow agenta zawierający odczyty, idempotentne zapisy i jedno działanie niepowtarzalne. Odłącz sieć przed wysłaniem, po wysłaniu, w trakcie wykonywania oraz po ukończeniu, ale przed potwierdzeniem, a następnie ponownie połącz jednocześnie kilku klientów. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.
Zastosuj granicę efektów ubocznych opisaną w sekcji działania agentów niepowtarzalne. Zliczaj próby na każdej warstwie, unikalne identyfikatory operacji, zduplikowane efekty, wiek elementów w kolejce, rozkład wycofań, odrzucone nieaktualne działania oraz czas powrotu usługi do normalnego obciążenia. Wynik pośredni musi pozostać możliwy do skontrolowania, zanim automatyzacja będzie kontynuować.
Test uznaje się za zaliczony tylko wtedy, gdy jedna logiczna operacja powoduje najwyżej jeden zatwierdzony efekt uboczny, a praca związana z ponowieniami mieści się w globalnym budżecie. Jeśli agent nie potrafi ustalić wcześniejszego wyniku, należy wymagać uzgodnienia lub zgody człowieka zamiast zakładać, że kolejna próba jest bezpieczna.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Dlaczego pobór mocy GPU gwałtownie wzrasta na początku lokalnego żądania wnioskowania?
Zobacz, jak zwiększanie taktowania GPU, wstępne przetwarzanie modelu, inicjalizacja jądra, przydzielanie pamięci i odstępy między próbkowaniami powodują skoki poboru mocy na początku wnioskowania.

Dlaczego ranking wyszukiwania wektorowego zmienia się, gdy jednocześnie przeszukiwanych jest wiele segmentów indeksu?
Dowiedz się, jak limity kandydatów dla poszczególnych segmentów, przybliżone grafy, kalibracja wyników, aktualizacje i konsolidacja zmieniają ranking prywatnego wyszukiwania wektorowego.

Dlaczego grupy duplikatów zdjęć dzielą się po edycji metadanych?
Zobacz, jak dokładne skróty, skróty percepcyjne, orientacja EXIF, znaczniki czasu, wartości progowe i wersje potoku powodują podział prywatnych grup duplikatów zdjęć.

