Bezpieczna migracja agenta: zestaw wzorcowy i sprawdzony powrót

Zmiana zachowania po migracji często wychodzi na jaw dopiero wtedy, gdy klient zgłasza, że jego sprawa została obsłużona inaczej niż dotychczas. W automatyzacjach zbudowanych w wygaszanych narzędziach, bez testów i dokumentacji, zwykle brakuje definicji poprawności potrzebnej do oceny nowej wersji.

Dlatego pracę nad migracją zaczynamy od opisania poprawnych zachowań na podstawie starego systemu. Nowy kod powstaje dopiero później.

Zestaw wzorcowy ze starego systemu

W migracji środowiska wykonawczego agenta na podstawie zapisów starego systemu przygotowaliśmy 336 przypadków z danymi wejściowymi i oczekiwanymi decyzjami. Wersja demonstracyjna używa przygotowanego katalogu, bez danych i poświadczeń klienta. Rzeczywiste zachowanie starego systemu staje się zestawem wzorcowym oraz pierwszą pisemną specyfikacją procesu.

Raport zgodności porównuje z tym zestawem nowego agenta, przypadek po przypadku. Wynik jest listą: 288 ścisłych zgodności i 48 rozbieżności. Każdą rozbieżność przegląda człowiek i oznacza jako wadę starego systemu, zamierzoną zmianę albo błąd do naprawy. W chwili pomiaru 41 decyzji było zamkniętych, a 7 pozostawało otwartych.

Otwarte rozbieżności blokują pełne przełączenie. Każda z nich oznacza, że zespół nie ustalił jeszcze, które zachowanie jest poprawne.

Jak zbudować zestaw, któremu można ufać

Historia starego systemu jest punktem wyjścia, ale nie każda historyczna odpowiedź powinna stać się wzorcem. Próbkę trzeba podzielić według intencji, kanału, rodzaju klienta, użytych narzędzi, odmów i wyjątków. Rzadkie przypadki o dużym skutku wymagają celowego doboru, ponieważ losowa próbka może ich w ogóle nie zawierać.

Każdy przypadek powinien zachować wejście, istotny stan procesu, oczekiwaną decyzję, dozwolone działania i wynik widoczny dla użytkownika. Warto oddzielić zachowanie, które musi pozostać identyczne, od elementów prezentacji i treści, które mogą się zmienić bez skutku biznesowego. Porównywanie całych tekstów znak po znaku generuje szum, jeśli ważne są decyzja, narzędzie i przekazane dane.

Przed użyciem zestawu właściciel procesu powinien przejrzeć znane wady starego rozwiązania. Wadliwe zachowanie może pozostać w zbiorze jako udokumentowany przypadek do zmiany, ale nie powinno automatycznie stać się oczekiwanym wynikiem nowej wersji.

Jak prowadzić rejestr rozbieżności

Każda różnica potrzebuje właściciela, kategorii, oceny skutku i decyzji. Przydatne kategorie to błąd nowego rozwiązania, wada starego systemu, zamierzona zmiana, różnica neutralna oraz brak wystarczających danych. Decyzja powinna wskazywać, który wynik będzie od tej chwili obowiązującym wzorcem.

Procent zgodności bez tego rejestru bywa mylący. Jeden błąd w decyzji o płatności może mieć większe znaczenie niż setki różnic w sformułowaniu odpowiedzi. Warunek przełączenia powinien więc uwzględniać wagę i rodzaj otwartych pozycji, a nie tylko ich liczbę.

Po zamknięciu rozbieżności zestaw staje się regresją nowego systemu. Każda poprawka i zmiana modelu powinna przejść przez ten sam materiał. W ten sposób dokumentacja migracyjna zamienia się w trwały mechanizm kontroli kolejnych wydań.

Plan przełączenia i powrotu

Próba w środowisku docelowym powinna sprawdzić połączenia, uprawnienia, limity, obserwowalność i zachowanie wyjątków. Następnie warto prowadzić obserwację równoległą: nowy system przetwarza kopię wejścia, ale jego wynik nie wpływa na proces. Różnice można wtedy oceniać na aktualnym ruchu.

Przełączenie zaczyna się od małego, odwracalnego zakresu z jasno określonym czasem obserwacji. Plan powrotu wskazuje osobę decyzyjną, sygnały uruchamiające powrót, sposób przełączenia, postępowanie z pracą rozpoczętą przez nową wersję oraz kontrolę spójności po powrocie. Sam pomiar czasu technicznego przełączenia nie dowodzi, że rozpoczęte sprawy i dane zostaną poprawnie rozliczone.

Jak czytać dowody i koszt

Zgodność zestawu pokazuje zachowanie na zapisanych przypadkach. Próba w środowisku docelowym pokazuje działanie wybranych intencji w konkretnej konfiguracji. Test powrotu potwierdza jedną wykonaną ścieżkę techniczną. Żaden z tych dowodów osobno nie zastępuje obserwacji na ruchu, oceny wydajności ani próby awarii zależności.

Zapisany przebieg 12 przypadków w środowisku docelowym kosztował 0,030373 USD, czyli 0,002531 USD za przypadek. Taka wartość pomaga oszacować koszt powtarzania testów regresyjnych. Do rachunku migracji trzeba dodać przygotowanie zestawu, przegląd rozbieżności, pracę równoległą, utrzymanie dwóch środowisk i gotowość zespołu podczas przełączenia. Największym kosztem bywa wiedza osób, które potrafią rozstrzygnąć zachowanie procesu.

Lista kontrolna gotowości do migracji

1. Czy zestaw obejmuje główne intencje, odmowy i rzadkie wyjątki o dużym skutku?
2. Czy znane wady starego systemu są oznaczone przed porównaniem?
3. Które pola i decyzje wymagają ścisłej zgodności, a które mogą się różnić?
4. Czy każda rozbieżność ma właściciela, kategorię i zatwierdzoną decyzję?
5. Jakie otwarte różnice bezwzględnie blokują przełączenie?
6. Czy nowy system przeszedł obserwację równoległą na aktualnym ruchu?
7. Co stanie się ze sprawami rozpoczętymi w chwili powrotu?
8. Kto podejmuje decyzję o powrocie i na podstawie jakich sygnałów?

Kontrola w środowisku docelowym i przećwiczony powrót

Zgodność z zapisanym zestawem nie potwierdza jeszcze działania nowego systemu w środowisku docelowym. Dlatego druga kontrola obejmuje po dwa przypadki dla każdej z sześciu intencji, uruchomione w docelowym środowisku wykonawczym, z przeglądem człowieka i narzędziem tylko do odczytu. Wszystkie sprawdzane intencje oraz granice zadziałały zgodnie z oczekiwaniem.

Trzecia kontrola sprawdza powrót do starego systemu. Lokalny test przełącza ruch na nową wersję, potwierdza działanie właściwego środowiska i wraca do poprzedniego systemu. Czas oraz niezawodność tego mechanizmu trzeba ponownie zmierzyć w infrastrukturze klienta i pod obciążeniem. Powrót jest ćwiczeniem wykonanym przed przełączeniem, a nie wyłącznie zapisem w procedurze awaryjnej.

Dokumentacja decyzji migracyjnej

Właściciel automatyzacji dostaje zestaw wzorcowy, listę rozbieżności wraz z decyzjami, zapis próby w środowisku docelowym oraz dowód powrotu do starej wersji. Jeden ekran pokazuje, które warunki zostały spełnione i co nadal blokuje przełączenie ruchu.

Siedem otwartych decyzji nadal blokuje pełne przełączenie ruchu. Pojedynczy sprawdzony powrót nie potwierdza też niezawodności mechanizmu pod obciążeniem. Te ograniczenia pozostają widoczne razem z wynikami kontroli.

Szczegóły znajdziesz na karcie systemu. Jeżeli krytyczny proces działa w wygaszanym narzędziu, bezpłatny przegląd procesów pomoże zaplanować zestaw wzorcowy przed rozpoczęciem migracji.