Spóźnione zdarzenie w automatyzacji: stary status nie powinien cofać sprawy

Na tablicy zleceń paczka rysunków jest już gotowa do pobrania. Minutę później wraca do „w przygotowaniu”. Nikt jej nie otworzył ani nie poprawił. Automatyzacja po prostu dostała zaległą wiadomość o rozpoczęciu pracy i potraktowała ją jak najnowszą prawdę. Paczka odbyła podróż w czasie bez pomocy działu badań.

W takim błędzie nie muszą wystąpić dwa identyczne komunikaty. Do systemu dotarły dwa różne zdarzenia, tylko w odwrotnej kolejności: najpierw informacja o gotowości, później o wcześniejszym rozpoczęciu. Zabezpieczenie przed powtórnym wykonaniem tej samej operacji nie rozstrzyga, co zrobić z osobną, spóźnioną zmianą stanu.

Rozważmy fikcyjny proces pracowni Rys. Klient zgłasza zestaw elementów ekspozycji, automat z pomocą AI przygotowuje opisy, człowiek je sprawdza, a system składa paczkę do odbioru. Różne etapy zgłaszają postęp przez zdarzenia, czyli komunikaty informujące o dokonanej zmianie. Przy odbiorze trzeba sprawdzić, które z nich mogą zmienić obecny status i co się stanie, gdy część historii dotrze później albo nie dotrze wcale.

Ustal porządek zmian, nie tylko czas ich dostarczenia

W próbce Rysu zdarzenie „rozpoczęto przygotowanie paczki” powstaje przed zdarzeniem „paczka gotowa”. To opis kolejności w procesie źródłowym. Odbiorca może jednak dostać je w innym porządku. Chwila odebrania komunikatu mówi, kiedy system go zobaczył, a nie kiedy nastąpiła opisana w nim zmiana.

Dokumentacja dostarczania zdarzeń Azure Event Grid zaznacza, że usługa nie gwarantuje kolejności dostarczenia. Odbiorca może dostać zdarzenia w innym porządku niż źródłowe zmiany. To właściwość wskazanego mechanizmu, którą trzeba uwzględnić w obsłudze; nie należy na tej podstawie przypisywać takiego samego zachowania każdej usłudze.

Także opis webhooków Shopify wskazuje brak gwarancji kolejności w ramach tematu oraz między tematami tego samego zasobu. Zaleca porządkowanie z wykorzystaniem udostępnianych znaczników czasu. Webhook to powiadomienie wysyłane do aplikacji po zdarzeniu; samo jego odebranie nie rozstrzyga, czy przedstawia najnowszy stan zasobu.

Pracownia powinna więc uzgodnić z wykonawcą, co w jej konkretnym mechanizmie określa nowszą zmianę. Może to być wersja rekordu, numer kolejny lub właściwie interpretowany znacznik czasu. Nie każda integracja udostępnia wszystkie te dane. Raport odbioru powinien nazwać wykorzystaną podstawę, jej zakres i przypadki, których nie rozstrzyga.

Numer wersji porównuj w ramach właściwej sprawy i źródła. Wersji dwunastej paczki P-17 nie porównasz z wersją drugą paczki P-18, żeby ustalić kolejność pracy; to dwa osobne ciągi zmian. Jeśli kilka systemów nadaje własne oznaczenia, ustal powiązanie między nimi. Przypadkowo większa liczba nie powinna rozstrzygać konfliktu.

Sam identyfikator zdarzenia odpowiada na inne pytanie: który to komunikat? Dwie różne zmiany tej samej paczki mogą mieć dwa różne identyfikatory i nadal przyjść w odwrotnej kolejności. Dlatego kontrola duplikatów i ponowień uzupełnia odbiór kolejności, lecz go nie zastępuje. W próbce trzeba uwzględnić obie sytuacje oddzielnie.

Nie wybieraj „najnowszego” przez sortowanie wyświetlanych dat bez ustalenia ich znaczenia. Data utworzenia zadania, aktualizacji rekordu, wysłania zdarzenia i przyjęcia go przez automat mogą opisywać inne chwile. Przy kilku źródłach dochodzą różnice sposobu nadawania czasu. Gdy danych nie wystarcza do bezpiecznego rozstrzygnięcia, proces potrzebuje jawnego sposobu wyjaśnienia stanu.

Przygotuj także dwa komunikaty z jednakową widoczną datą, ale inną udokumentowaną kolejnością zmian. Sprawdź, czy integracja ma dodatkową podstawę rozstrzygnięcia, czy uczciwie zgłasza brak rozróżnienia. Dopisanie ułamka sekundy przez odbiorcę nie naprawi informacji, której źródło nie dostarczyło. Użytkownik powinien rozpoznać przypadek wymagający potwierdzenia, zamiast zobaczyć pozornie precyzyjny wynik.

Trzy przebiegi tej samej paczki

Do odbioru przygotuj sztuczną paczkę P-17 i opis jej dozwolonych etapów. W Rysie są to: przyjęta do przygotowania, w sprawdzeniu, gotowa do odbioru. Status „gotowa” ma oznaczać, że wskazany plik przeszedł uzgodnioną kontrolę i można udostępnić go odbiorcy. Nie może wynikać wyłącznie z płynnego komentarza asystenta.

Pierwszy przebieg dostarcza zdarzenia w zwykłej kolejności. Potwierdza, że podstawowy proces w ogóle działa. Zapisz stan po każdym komunikacie oraz wykonane dodatkowe działania, takie jak utworzenie pliku lub powiadomienia. Jeżeli już ta próba daje niewłaściwy stan, nie da się z niej ocenić poprawności obsługi opóźnienia.

Drugi przebieg zmienia kolejność dostarczenia dwóch różnych zdarzeń. Informacja o gotowości dociera przed wcześniejszą informacją o rozpoczęciu. Oczekiwany wynik należy ustalić przed próbą: paczka nie wraca do przygotowania tylko dlatego, że dawny komunikat został odebrany później. Historia powinna jednak pozwalać rozpoznać, że taki komunikat nadszedł i jak go potraktowano.

Przykładowo: zdarzenie dla wersji trzeciej potwierdza gotowość, a później dociera opis rozpoczęcia dotyczący wersji drugiej. W kluczu próby zapisz pozostawienie gotowości wersji trzeciej oraz odnotowanie dawnego komunikatu bez cofnięcia stanu. To własna próbka procesu Rysu, nie opis numeracji stosowanej przez Azure ani Shopify. Wykonawca powinien odtworzyć ją z polami dostępnymi w rzeczywistej integracji.

Trzeci przebieg dotyczy nowszej, rzeczywistej zmiany. Po udostępnieniu paczki sprawdzający wykrywa błąd i uruchamia poprawkę. Powrót do pracy jest wtedy uzasadniony, jeśli tak opisano proces. Reguła „nigdy nie cofaj statusu” byłaby równie myląca jak bezwarunkowe przyjmowanie ostatnio dostarczonego komunikatu. System musi odróżnić spóźniony opis dawnej pracy od aktualnej decyzji o poprawieniu materiału.

Przy każdym przebiegu sprawdź również tożsamość paczki. P-17 w pierwszej wersji i P-17 po poprawce nie muszą oznaczać tego samego pliku. Jeśli gotowość dotyczy starej wersji, nie powinna zatwierdzać nowego materiału. Podobną granicę opisuje wiązanie wyniku zadania wsadowego z rekordem: wynik musi trafić do właściwego wejścia i wersji.

Warto rozdzielić status samej czynności od statusu całej sprawy. AI może skończyć opis, podczas gdy człowiek nadal sprawdza rysunki. Zdarzenie „opis ukończony” nie powinno automatycznie zamknąć zlecenia, jeżeli pozostały warunki odbioru. Lista etapów powinna wskazywać, które sygnały są tylko informacją o części pracy, a które uprawniają do przejścia dalej.

Po przestawieniu kolejności sprawdź nie tylko końcową etykietę, lecz także działania wykonane po drodze. System mógł na moment cofnąć paczkę, wysłać błędne powiadomienie, a potem przywrócić właściwy status. Ostatni ekran wygląda wtedy poprawnie, choć odbiorca dostał sprzeczne informacje. Klucz próby powinien określać dozwolone powiadomienia i utworzone artefakty dla każdego przebiegu.

Brakującej historii nie dopisuj z wyobraźni

Czwarta próba pomija jedno zdarzenie. Automat dostaje informację o gotowości paczki, ale nie widział wcześniejszego rozpoczęcia. Zespół ustala, czy może zweryfikować aktualny stan w źródłowym systemie, czy musi skierować przypadek do wyjaśnienia. Nie powinien sam dopowiadać, że brakujący etap na pewno przebiegł poprawnie.

Osobno dostarcz komunikat o nieznanej paczce. Ustal, czy uprawnia do utworzenia sprawy, czy wymaga sprawdzenia jej istnienia w źródle. To zależy od znaczenia zdarzenia i przyjętego procesu. Automatyczne założenie pustego zlecenia po dowolnym sygnale „gotowe” może ukryć błędny identyfikator oraz stworzyć pracownikowi sprawę, której nikt rzeczywiście nie zamówił.

W tym miejscu określ, gdzie znajduje się rozstrzygający stan sprawy. Jeżeli to system źródłowy, odczyt jego aktualnych danych może służyć uzgodnieniu rozbieżności. Taka czynność wymaga własnej obsługi błędu: źródło może być niedostępne albo zwrócić niepełną informację. Wtedy stan „oczekuje na potwierdzenie” powinien być odróżnialny od „gotowa do odbioru”.

Nie wystarczy zachować komunikatu gdzieś w technicznym logu. Osoba odpowiadająca za sprawę powinna wiedzieć, że automatyzacja nie rozstrzygnęła stanu, kto ma go wyjaśnić i co wolno zrobić do tego czasu. Przy logach AI bez nadmiaru danych przydatne są identyfikatory pozwalające połączyć ślad z paczką oraz przyczyna decyzji, nie kolejna pełna kopia materiałów klienta.

Próba powinna też pokazać powrót do normalnej pracy. Po odzyskaniu brakującej informacji wyjaśniona paczka przechodzi dalej według uzgodnionej reguły. Nie pozostaje na zawsze w kolejce wyjątków, ale też nie przeskakuje do końca na podstawie ręcznego odhaczenia ostrzeżenia. Zapisz, co zostało potwierdzone i kto podjął decyzję.

Przy ręcznym ponowieniu zachowaj pierwotne oznaczenie zdarzenia oraz jego relację do źródłowej zmiany. Nowa chwila dostarczenia nie powinna zmieniać dawnej informacji w nową decyzję biznesową. Jeśli potrzebna jest faktyczna korekta, powinna mieć własną podstawę i autora. W próbie sprawdź, czy operator potrafi odróżnić odtworzenie komunikatu od zatwierdzenia nowego stanu.

Człowiek może zmienić stan, gdy automat jeszcze czeka

Spóźnienie dotyczy również wyniku rozpoczętej analizy. Pracownik Rysu poprawia rekord, zanim automat otrzyma zakończenie zadania opartego na dawnej wersji. Jeśli przychodzący wynik bezwarunkowo nadpisze obecne dane, kolejność dostarczenia zacznie rządzić decyzją biznesową. Przypadek wymaga sprawdzenia wersji, z której wykonano pracę.

W odbiorze przyda się kontrola równoczesnej zmiany rekordu przez AI i człowieka. Rozstrzygnięcie może oznaczać odrzucenie dawnego wyniku, ponowne przygotowanie propozycji albo przedstawienie konfliktu pracownikowi. Wybór zależy od konkretnego procesu; milczące nadpisanie nie powinno być przypadkowym skutkiem opóźnienia.

Podobne zasady obowiązują przy przekazaniu zadania między agentami. Drugi wykonawca musi dostać oznaczenie sprawy, wersję materiału i stan istotny dla jego kroku. Samo streszczenie „paczka w przygotowaniu” może być już nieaktualne w chwili rozpoczęcia pracy. Odbiorca przekazania powinien umieć rozpoznać tę granicę.

W Rysie właściciel procesu określa znaczenie statusów, wykonawca integracji opisuje dostępne informacje o kolejności, a osoba odbierająca sprawdza próbki z uzgodnionym wynikiem. Gdy te role uznają różne zdarzenia za rozstrzygające, najpierw trzeba wyjaśnić regułę. Dodatkowe polecenie dla modelu nie zastąpi wspólnej decyzji o tym, kto może ponownie otworzyć gotową paczkę.

Do uzgodnień dodaj przypadek anulowania. Późniejszy komunikat o zakończeniu dawno rozpoczętej pracy nie powinien sam przywrócić anulowanego zlecenia. Ustal, czy wynik zostaje zachowany wyłącznie jako ślad wykonania, czy wymaga osobnej decyzji. To pozwala sprawdzić regułę także wtedy, gdy najwyższy numer wersji nie oznacza zgody na dalszą obsługę.

Dla zespołu przygotuj czytelne rozstrzygnięcia: komunikat zastosowany, pominięty jako dawny, rozpoznany jako powtórzenie albo przekazany do wyjaśnienia. Do każdego wyniku dodaj oznaczenie paczki i podstawę decyzji. Osoba obsługująca wyjątek nie powinna rekonstruować logiki przez porównywanie kilku ekranów bez wspólnego identyfikatora.

W ramach oferty Aeneia Audit warto zacząć od takiej próbki oraz opisu tego, co ma oznaczać końcowy status. Pozwala to znaleźć przerwę między działaniem narzędzia a odpowiedzialnością za wynik. Odbiorca ma dostać właściwą wersję paczki, a pracownik widzieć, dlaczego system uznał ją za gotową.