Automatyzacja operacji nie zawsze oznacza jej wykonanie bez udziału człowieka. Jeśli działanie może zmienić ważne dane, uwzględnić warunki handlowe, przesunąć środki lub wpłynąć na osoby trzecie, być może powinno poczekać na autoryzację człowieka. Proces zatwierdzania przez człowieka w automatyzacjach PHP zapewnia taką kontrolę, nie zamieniając procesu w nieformalny łańcuch wiadomości i decyzji, które trudno później odtworzyć.
Nie chodzi o samo dodanie przycisku „zatwierdź”, lecz o określenie, co jest proponowane, kto może podjąć decyzję, na podstawie jakich informacji i w jakim czasie, a także co stanie się później. System musi umieć wyjaśnić każdy stan i zapobiegać temu, by stare lub zduplikowane zatwierdzenie uruchomiło inne działanie niż to, które poddano weryfikacji.
Określ, kiedy wstrzymać operację
Kontrola następcza pozwala wykryć problemy po wykonaniu działania. Z kolei zatwierdzenie przed wykonaniem wstrzymuje je do czasu podjęcia decyzji. Warto wymagać autoryzacji, gdy potencjalny wpływ, trudność odwrócenia działania lub niepewność przekraczają poziom akceptowany dla automatyzacji.
Oceń każdą operację, zadając konkretne pytania: Czy może zmienić dane, które trudno odzyskać? Czy wpływa na pieniądze, prawa, dostęp lub zobowiązania wobec klientów? Czy istnieje weryfikowalna reguła pozwalająca wykonać ją autonomicznie? Jakie szkody może spowodować błąd i ile jest czasu na reakcję? Rutynowa, odwracalna i ograniczona operacja może być wykonywana automatycznie i rejestrowana do późniejszej kontroli. Działanie wyjątkowe lub o dużym wpływie może wymagać autoryzacji przed wykonaniem.
Unikaj domyślnego obejmowania kontrolą człowieka każdej operacji. Przeciążona kolejka powoduje opóźnienia i sprzyja mechanicznemu zatwierdzaniu. Określ progi i wyjątki oraz mierz liczbę oczekujących spraw, czas oczekiwania, odrzucenia i wygaśnięcia, aby zidentyfikować reguły wymagające dostosowania. Decyzja powinna opierać się na rzeczywistym ryzyku, a nie wyłącznie na tym, czy dana operacja jest technicznie możliwa.
Określ, co jest proponowane i co można autoryzować
Osoba weryfikująca powinna rozumieć skutki operacji, a nie rozszyfrowywać wewnętrzny obiekt PHP. Przedstaw aktualną i proponowaną wartość, uzasadnienie, źródło danych, istotne konsekwencje i wszelkie ograniczenia. Jeśli decyzja zależy od reguły, pokaż wyjaśnienie potrzebne do jej zastosowania. Ukryj lub zabezpiecz dane osobowe, które nie są potrzebne.
Oddziel propozycję działania od autoryzacji. Propozycja opisuje działanie i jego parametry; autoryzacja pozwala wykonać tę konkretną propozycję. Nie powinna przyznawać ogólnych uprawnień ani umożliwiać osobie zatwierdzającej cichej edycji parametrów. Jeśli potrzebne są zmiany, osoba weryfikująca może o nie poprosić; system tworzy wtedy zaktualizowaną propozycję działania, która musi przejść odpowiednie reguły autoryzacji.
Stosuj zasadę najmniejszych uprawnień: ogranicz, kto może tworzyć, autoryzować, odrzucać lub anulować propozycje, i sprawdzaj te uprawnienia po stronie serwera przy każdej zmianie stanu. Gdy uzasadnia to ryzyko, wymagaj, by osoba składająca propozycję nie mogła autoryzować własnej operacji. Rozdzielenie obowiązków należy wdrożyć w logice uprawnień, a nie opierać wyłącznie na ukrywaniu przycisków w interfejsie.
Modeluj stany i jawne przejścia
Przedstaw proces jako maszynę stanów. Przydatny zestaw początkowy może obejmować pending, approved, executing, rejected, changes_requested, expired, cancelled i executed. Oczekująca propozycja może zostać zatwierdzona, odrzucona, anulowana lub wygasnąć; zatwierdzona może przejść do wykonania tylko wtedy, gdy nadal jest ważna. Operacja w stanie executing może zakończyć się jako wykonana albo wrócić do stanu umożliwiającego odzyskanie, jeśli ustalono, że nie wywołała skutku. Wykonanej propozycji nie można zatwierdzić ponownie.
Zapisuj bieżący stan wraz z niezmienną historią decyzji i przejść. Rejestruj identyfikator propozycji, poprzedni i nowy stan, aktora, datę i godzinę, uzasadnienie oraz odniesienie do wersji sprawdzonych danych. Nie zastępuj historii podczas aktualizowania rekordu: jest ona niezbędna do audytu przebiegu i diagnozowania awarii.
W PHP centralizuj przejścia w serwisie domenowym lub równoważnym komponencie. Nie pozwalaj różnym kontrolerom bezpośrednio zmieniać stanu za pomocą ogólnych aktualizacji. W razie potrzeby sprawdzaj poprawność przejścia i uprawnienia w ramach transakcji oraz odrzucaj działania niezgodne z bieżącym stanem. Taka struktura ogranicza błędy współbieżności i ułatwia testowanie reguł bez uzależniania się od interfejsu.
Zapobiegaj nieaktualnym zatwierdzeniom i wielokrotnemu wykonaniu
Dane mogą się zmienić, gdy propozycja oczekuje na decyzję. Nikt nie powinien zatwierdzać warunku, który nie odpowiada już operacji przeznaczonej do wykonania. Podczas tworzenia propozycji zapisuj wersję, datę aktualizacji lub sumę kontrolną istotnych pól. Przy zatwierdzaniu ponownie porównaj ją z aktualnym stanem.
Samo sprawdzenie podczas zatwierdzania nie wystarczy: dane mogą zmienić się jeszcze przed wykonaniem operacji. Bezpośrednio przed wykonaniem ponownie porównaj aktualną wersję lub sumę kontrolną z zatwierdzoną. Jeśli się różnią, zatrzymaj proces, unieważnij autoryzację dla tej propozycji i poproś o nową decyzję dotyczącą zaktualizowanych danych. W zależności od ryzyka możesz pokazać różnice i wymagać jawnego potwierdzenia, ale nie używaj automatycznie ponownie wcześniejszego zatwierdzenia.
Termin ważności ogranicza czas, przez jaki decyzja jest uznawana za ważną. Po jego upływie oznacz propozycję jako wygasłą i wymagaj nowej autoryzacji, aby kontynuować. Przy każdej ponownej próbie sprawdzaj, czy autoryzacja nadal jest ważna; nigdy nie używaj wygasłej autoryzacji do wznowienia lub powtórzenia wykonania.
Zatwierdzenie musi dotyczyć możliwej do zidentyfikowania propozycji i nie może być sygnałem wielokrotnego użytku. Aby zapobiec wykonaniu tej samej propozycji przez dwóch równoległych workerów, atomowo przejmij lub zablokuj jej przejście ze stanu approved do executing: tylko jeden worker może ją przejąć, jeśli propozycja nadal jest zatwierdzona i ważna. W ramach tej lokalnej ochrony sprawdź również idempotencję i przed kontynuowaniem zarejestruj unikatowy identyfikator operacji. Zapobiega to duplikatom w obrębie systemu, ale sama transakcja bazodanowa nie gwarantuje, że zewnętrzne API zastosuje skutek tylko raz.
Jeśli działanie odbywa się w innej usłudze, użyj klucza idempotencji, który ta usługa akceptuje i obsługuje idempotentnie, o ile jest dostępny. Rejestruj identyfikator korelacyjny, próbę i odpowiedzi. Jeśli odpowiedź zostanie utracona lub wynik będzie nieznany, nie powtarzaj działania bez sprawdzenia: odczytaj zdalny stan za pomocą tego identyfikatora lub uzgodnij wynik z wiarygodnymi danymi. Jeśli nie da się potwierdzić, czy skutek wystąpił, zatrzymaj kolejne automatyczne próby i przekaż sprawę operatorowi. Potwierdzona awaria przed wysłaniem żądania może pozwolić na ponowną próbę, pod warunkiem ponownego sprawdzenia stanu i autoryzacji.
Jeśli worker ulegnie awarii i pozostawi propozycję w stanie executing, nie oznaczaj jej automatycznie jako wykonanej ani nie ponawiaj operacji bez diagnozy. Proces odzyskiwania powinien ustalić, czy skutek wystąpił, na podstawie lokalnego rejestru i, w razie potrzeby, zapytania do usługi zdalnej. Jeśli potwierdzi, że skutek nie wystąpił, może przywrócić propozycję do stanu umożliwiającego wykonanie dopiero po ponownej weryfikacji ważności, danych i autoryzacji; jeśli wynik nadal jest nieznany, powinien pozostawić ją zablokowaną i eskalować sprawę.
Zaprojektuj kolejkę operacyjną i alternatywną ścieżkę ręczną
Kolejka powinna umożliwiać wyszukiwanie oczekujących spraw według czasu oczekiwania, wpływu, osoby odpowiedzialnej i terminu wygaśnięcia, a także pokazywać kontekst uzasadniający decyzję. Wyjaśnij, dlaczego sprawa jest zablokowana i jakie działanie należy podjąć: poczekać, poprosić o zmiany, anulować czy eskalować. Interfejs powinien też jasno wyjaśniać, co stanie się po zatwierdzeniu, a nie tylko udostępniać przyciski decyzyjne.
Określ alternatywną ścieżkę na wypadek awarii zależności, takiej jak usługa powiadomień lub integracja niezbędna do wykonania działania. Można pozostawić propozycję jako oczekującą i zapewnić kontrolowaną procedurę, w ramach której upoważniona osoba sprawdzi sprawę w dostępnym systemie. Ścieżka ręczna musi stosować te same kontrole, rejestrować aktora i uzasadnienie, zapobiegać równoległemu wykonaniu oraz uzgadniać wynik po przywróceniu integracji.
Nie zamieniaj awarii technicznej w domyślne zatwierdzenie. Jeśli nie można zweryfikować tożsamości, uprawnień lub wymaganych informacji, system powinien bezpiecznie przerwać działanie: wstrzymać proces, poinformować o problemie i eskalować sprawę. Określ, kto może odblokować proces, jak udokumentować tę interwencję i jakie zadania należy sprawdzić po przywróceniu usługi.
Testuj proces i monitoruj jego działanie
Testuj reguły domenowe i pełne ścieżki: zatwierdzanie, odrzucanie, prośbę o zmiany, wygaśnięcie, anulowanie i ponowne próby. Dodaj testy uprawnień, aby potwierdzić, że osoba bez uprawnień nie może zmienić stanu, oraz testy współbieżności, by dwie równoczesne decyzje nie doprowadziły do dwóch wykonań.
Uwzględnij przypadki, w których dane zmieniają się podczas oczekiwania lub tuż przed wykonaniem, zdalne wykonanie kończy się błędem po przyjęciu żądania albo odpowiedź zostaje utracona mimo wystąpienia skutku. Sprawdź, czy atomowe przejęcie pozwala wykonać propozycję tylko jednemu workerowi, ponowne próby odrzucają wygasłe autoryzacje, a każda ręczna interwencja pozostawia wystarczający zapis. W środowisku produkcyjnym monitoruj liczbę i wiek oczekujących spraw, wygaśnięcia, błędy wykonania oraz przypadki wymagające uzgodnienia.
Dobrze zaprojektowany proces zapewnia nadzór człowieka tam, gdzie rzeczywiście zwiększa kontrolę, zamiast pozostawiać bezpieczeństwo pamięci zespołu. Jawne stany, rozdzielone uprawnienia, aktualność weryfikowanych danych, idempotentne wykonanie i jasno określona ścieżka postępowania w razie awarii zmieniają nieformalne zatwierdzanie w weryfikowalny proces.
