Polityka ponawiania prób w automatyzacji

Polityka ponawiania prób, po angielsku retry policy, to reguły określające reakcję workflow na nieudaną operację. Odpowiada na cztery pytania: które błędy wolno powtórzyć, ile razy, jak długo czekać między próbami oraz gdzie trafia zadanie po wyczerpaniu limitu. Nie każdy błąd oznacza to samo. Chwilowa niedostępność usługi, przekroczony limit zapytań lub zerwane połączenie często są przejściowe. Niepoprawny adres e-mail, brak wymaganego pola albo odmowa dostępu zwykle nie znikną po trzeciej identycznej próbie. Dobra polityka nie maskuje błędów. Kieruje tylko takie przypadki do ponowienia, które mają realną szansę zakończyć się powodzeniem.

W automatyzacji AI retry nie dotyczy wyłącznie wywołania modelu. Może obejmować odebranie webhooka, pobranie danych z CRM, zapis pliku, utworzenie płatności lub wysłanie wiadomości po wygenerowaniu treści. Wybierz zdarzenie biznesowe, a nie tylko techniczny krok. Jeśli formularz konsultacji został przyjęty, ale zapis do CRM zwrócił timeout, celem jest jeden kompletny lead w CRM, nie trzy wywołania API. Właśnie dlatego polityka ponawiania musi być opisana razem z obserwowalnością: dla każdej próby zapisuj identyfikator sprawy, typ błędu, numer próby i końcowy rezultat.

Najczęściej stosuje się ograniczoną liczbę prób oraz rosnące odstępy, czyli wykładnicze opóźnienie. Google Cloud zaleca uwzględnić także jitter, losową część opóźnienia, aby wiele workflow nie uderzało równocześnie w usługę, która właśnie wraca po awarii. Przykład polityki dla błędu 429 lub 503: maksymalnie trzy ponowienia, pierwsze po minucie, kolejne z rosnącym opóźnieniem i limitem całkowitego czasu. Konkretne liczby zależą od obietnicy wobec klienta i dokumentacji dostawcy. Nie kopiuj ustawień z innej integracji, jeśli jej limit, koszt albo czas oczekiwania są inne.

Praktyczny przykład: agent AI tworzy streszczenie rozmowy, a potem zapisuje je w CRM i wysyła zadanie follow-up. Model zwrócił poprawny wynik, lecz CRM odpowiedział błędem 503. Workflow może bezpiecznie ponowić zapis, jeśli wysyła stabilny identyfikator rozmowy i CRM rozpoznaje go jako tę samą operację. Gdy zapis powiedzie się, dalszy krok uruchamia się raz. Jeśli po trzech próbach CRM nadal nie działa, workflow nie powinien po cichu zniknąć. Powinien trafić do kolejki błędów, stworzyć widoczny alert i dać właścicielowi procesu dane potrzebne do ręcznego odzyskania sprawy.

Idempotencja jest warunkiem bezpiecznego retry dla operacji powodujących skutki uboczne. To właściwość, dzięki której wielokrotne wykonanie tej samej intencji daje efekt równoważny jednemu wykonaniu. Bez niej timeout jest szczególnie zdradliwy: klient API nie dostał odpowiedzi, ale serwer mógł już wysłać e-mail, utworzyć płatność lub dodać kontakt. Kolejna próba może wtedy zdublować działanie. Używaj klucza idempotencji, unikalnego identyfikatora zdarzenia albo sprawdzenia stanu przed zapisem. Jeśli narzędzie nie wspiera takiej ochrony, nie ustawiaj automatycznego retry dla nieodwracalnej akcji bez dodatkowego kroku kontroli.

Polityka powinna mieć osobne ścieżki dla błędów przejściowych i trwałych. Błędy limitów, timeouty i część odpowiedzi 5xx mogą trafić do retry. Błędy walidacji 4xx, zły format danych, brak uprawnienia czy blokada biznesowa powinny zakończyć próbę szybciej i trafić do poprawy danych albo właściciela procesu. AWS Step Functions rozdziela retry i catch, czyli obsługę błędu po wyczerpaniu prób. To dobry model myślenia niezależnie od narzędzia: ponów tylko błąd, który może się zmienić, a dla reszty przygotuj jawny fallback, ręczną kolejkę lub bezpieczne zakończenie.

Najczęstszy błąd solopreneurki to włączenie domyślnego „retry on fail” bez limitu, klasyfikacji i alertu. Efektem może być zalanie API, wielokrotnie wysłana wiadomość albo rosnące koszty modelu. Drugi błąd to brak retry wszędzie, przez co pojedyncza chwilowa awaria gubi wartościowy lead. Zacznij od jednego krytycznego workflow. W tabeli zapisz: krok, błędy kwalifikujące do retry, maksymalną liczbę prób, strategię opóźnienia, ochronę przed duplikatem, właściciela oraz działanie po porażce. Następnie przetestuj scenariusz timeoutu i odpowiedzi 429 na danych testowych, zanim proces dostanie prawdziwy ruch.

Retry nie zastępuje kolejki błędów, circuit breakera ani fallbacku modelu. Kolejka błędów przechowuje sprawy, których automatycznie nie udało się obsłużyć. Circuit breaker może chwilowo zatrzymać kolejne wywołania, gdy usługa wyraźnie nie działa. Fallback modelu zmienia dostawcę lub model, gdy podstawowy nie jest dostępny. Polityka ponawiania jest jednym elementem tej układanki. Jej sukces mierz liczbą odzyskanych spraw bez duplikatów oraz czasem, w którym klient dostał obiecany rezultat. Jeśli tych danych nie masz, nie wiesz, czy retry zwiększa niezawodność, czy tylko ukrywa problem.