Migruję do V2. O co zapytać?
Porozmawiajmy o migracji procesu / systemu / części produktu do nowej wersji. O czym pamiętać, na co zwracać uwagę, czego unikać? O tym piszę poniżej.
Migracja do nowszej wersji
W życiu każdego produktu, dochodzi do takiego momentu, że kolejną zmianę trudno jest przeprowadzić inkrementalnie. Chcemy zmigrować część procesu do nowego SaaSa. Może potrzebujemy zmienić platformę. Wykonujemy dużą zmianę na bazie danych. Przenosimy repozytorium do nowego hostingu. Brzmi znajomo, prawda? Niestety, temat jest nieco bardziej skomplikowany niż mogłoby się wydawać.
Migracja przeprowadzona po łebkach powoduje, że umyka nam wiele rzeczy. A to ostatecznie sprawia, że cały proces się nie udaje. Dlatego do migracji trzeba podejść, jak do każdej dużej zmiany – w sposób przemyślany.
Aby Ci w tym pomóc, przygotowałem listę pytań, jakie warto sobie zadać podczas planowania czy przeprowadzania procesu migracji.
Pytania wstępne
Poniżej przedstawiam pytania, jakie można sobie zadać podczas analizy migracji. Odpowiedzi wpłyną na plan i przyjęcie właściwego podejścia do migracji.
Zakres migracji
Co jest zmieniane / adaptowane podczas migracji?
Chcemy zebrać jak najwięcej informacji o tym, co faktycznie modyfikujemy.
Kod – zmiana języka, środowiska uruchomieniowego.
Procesy – aktualizacja sposobu pracy, dwa równoległe procesy.
Dane – duża modyfikacja schematu, przeniesienie danych.
Infrastruktura – przeniesienie do innej platformy, zmiana wersji bazy.
Serwisy – zaczynamy korzystać z zewnętrznego serwisu, migrujemy do innego serwisu.
Rzadko kiedy zmieniamy tylko jedną kategorię. “Rozplątanie” tych aspektów pozwoli nam migrację lepiej podzielić na etapy.
Czy istnieje wymiar, do którego można ograniczyć migrację?
Może być to przykładowo:
Wielkość klientów B2B – mali, średni, duzi
Kraje, regiony – Polska, Czechy, Niemcy, Europa, USA
Rynki – medyczny, automotive, prawniczy
Urządzenia – Android, iPhone, web, TV
To pozwoli nam podzielić migrację na kilka kroków i przenosić wymiary po kolei.
Wykorzystanie systemu
Jakie jest obecne wykorzystanie systemu?
Kilku klientów, niewielkie wykorzystanie
Kilku klientów, duże i częste wykorzystanie
Wielu różnorodnych klientów, niewielkie wykorzystanie
Wielu różnorodnych klientów, duże i częste wykorzystanie.
Odpowiedź na powyższe pytania stworzy nasze wstępne ramy działania. Jeśli nasza baza klientów jest stosunkowo homogeniczna i mało aktywna, to mamy większe pole do manewru. W przypadku różnorodnych klientów korzystających z systemu przez cały dzień, robi się bardziej ryzykownie.
Downtime
Jakie obszary / procesy mogą wejść w tryb niedostępności?
Cały produkt
Część procesów
Część klientów
Żadna część produktu nie może mieć downtime
To nam pozwala określić, na jaki poziom elastyczności możemy sobie poradzić w ramach planowania.
Jaki okres braku dostępności możemy zaakceptować?
Jeśli na poprzednie pytanie uzyskaliśmy odpowiedź twierdzącą, to możemy, idąc dalej, zapytać o zakres:
Kilka minut – mamy wąskie okno czasowe, w zasadzie zdążymy tylko z aktualizacją aktualizacja i na proda.
Kilka godzin – procesy mogą trwać dłużej, ale nie mamy pełnej swobody.
Kilka dni – na weekend możemy się zamknąć i pozmieniać wszystko tak, jak nam się podoba.
Im krótsza niedostępność, tym więcej złożonych wzorców trzeba zastosować.
Atrybuty jakościowe
Jakie atrybuty jakościowe zmieniają się w ramach migracji?
Wydajność – musimy obsłużyć większy ruch tymi samymi zasobami.
Elastyczność – musimy się wyskalować, gdy ruch wzrośnie w określonych godzinach.
Odporność na błędy – gdy dany problem wystąpi, system to udźwignie, zamiast upadać jak do tej pory.
Konfigurowalność – system poradzi sobie z nowymi układami parametrów.
Brak świadomości w tym obszarze spowoduje ryzyko, że migracja nie dowiezie wymaganych wymagań biznesowych. Tutaj nie będę tego tematu poszerzał, ale jeśli jesteś ciekaw, to w artykule o driverach architektonicznych, omawiam to bardziej wyczerpująco.
Split brain
Czy w ramach migracji będziemy musieli działać w V1 i V2 naraz?
Jeśli tak, to w jakim obszarze/obszarach?
Cały produkt
Kilka procesów / klientów
Brak takich obszarów
Praca w obu wersjach naraz jest o cały rząd wielkości trudniejsza. Jednocześnie może być nieunikniona, ze względu wymaganej dostępności.
Systemy zależne
Jakie inne systemy zależne wpływają / są pod wpływam migracji?
Brak takich systemów
Zależne systemy wewnętrzne
Zależne systemy zewnętrzne
Systemy wewnętrzne muszą funkcjnować w pełnej synchronizacji z naszymi pracami. W ramach ich wymagań, trzeba będzie więc zaplanować komunikację z dostawcami.
User experience
W jakim stopniu zmianę odczują nasi odbiorcy?
Migracja jest niewidoczna
Migracja wymaga od nich lekkiej zmiany pracy
Wszystko się wywraca do góry nogami
Im mocniej zmiana dotyczy odbiorców, tym więcej pracy organizacyjnej trzeba zaplanować w ramach przygotowania do migracji.
Znając odpowiedzi na wstępne pytania, możemy przejść do bardziej specyficznych zagadnień. Zaczniemy od problemu największego kalibru: migracji bazy.
Migracja danych
Największym problemem, z jakim się stykamy w ramach migracji bazy danych jest jej typowa zero-jedynkowosć. Wykonujemy migrację i mamy 50% szans. Albo się uda, albo się nie uda 😉
Żeby zmniejszyć złożoność takiej migracji i trochę przechylić szalę prawdopodobieństwa na naszą korzyść, można sobie zadać dodatkowe pytania:
Czas trwania migracji
Czy wiemy, ile może potrwać migracja danych?
Aby to sprawdzić, czy:
Możemy przetestować migrację
Nie ma możliwości wykonania testów
Druga sytuacja wydaje się dziwna, ale takie przypadki się zdarzają: przez rozmiar, brak repliki, niemożliwość wstrzymania ruchu i tym podobne scenariusze.
Jeśli zaś możemy przetestować migrację w bezpieczny sposób, to powinniśmy bez wahania z tej opcji skorzystać , a następnie zsumować z ogólnym czasem migracji. I wtedy zadać docelowe pytanie:
Jak długo potrwa migracja?
Przejdzie w czasie zakładanej niedostępności
Nie zmieści się w zakładanej niedostępności
Jeśli już wiemy, że proces potrwa zbyt długo, to trzeba przyjąć inne podejście i skupić się na stopniowej migracji bazy wykorzystując wzorce takie jak Zero Downtime Deployment.
Zmiana schematu
Jak mocno zmieni nam się schemat bazy podczas migracji?
Nie zmieni się w ogóle
Istotnie się zmieni
Abstrahując od niedostępności, zmiana schematu może zwiastować problemy związane z wydajnością czy skalowalnością. Warto wtedy dodatkowo rozważyć testy obciążeniowe.
Powstaje kolejne pytanie:
Jacy klienci korzystają z tej bazy?
Tylko nasza aplikacja
Inne aplikacje wewnętrzne
Systemy BI
Odpowiedź na to pytanie każe nam się zastanowić, jak duża jest siła rażenia zmiany na poziomie schematu. Systemy BI często się są pomijane i w efekcie wywalają się dzień po migracji.
Wymagania regulacyjne
Czy pracuję w środowisku, które ma wymagania dookoła zarządzania danymi? Czy to są takie dane?
Podstawowe wymagania bezpieczeństwa (jak szyfrowanie danych podczas transmisji)
Ścisłe wymagania regulacyjne (np. GDPR, HIPAA, PCI)
Druga odpowiedź mogą zwiastować konieczność wykorzystania praktyk szyfrowania, maskowania danych, audytów bezpieczeństwa.
Rollback
Czy jeśli migracja danych się nie powiedzie, to mam do czego wrócić?
Tak, mam dane w formie backupu i przetestowałem zawrócenie danych.
Tak, mam dane w formie backupu i wiem, że umiem zawrócić dane.
Nie mam takich danych.
Przyznaję się, drugie pytanie jest zarzutką Jeśli czegoś nie przetestowałeś, to Prawo Muprheygo mówi, że to na pewno nie zadziała. A więc przetestuj wcześniej opcję rollbacku.
Oczywiście nie wszystkie migracje będą potrzebowały rollbacków. Ale jeśli czytasz ten artykuł, to z dużym prawdopodobieństwem masz do czynienia z migracją, która tego potrzebuje.
Migracja obszarów bezstanowych
Po zajęciu się obszarem danych, można przejść do obszarów bezstanowych – serwisów / aplikacji.
Architektura
W jakim stopniu migracja wpłynie na architekturę?
Mamy wciąż tą samą architekturę.
Zmieni się kilka, mniej znaczących elementów.
Mamy kompletny redesign.
Im więcej zmienianych elementów, tym większa szansa, że całe rozwiązanie nie będzie działało poprawnie. Zalecane jest zmienianie po kolei i sprawdzanie kompatybilności.
Dostępy do zasobów
Jak zmieni się sposób dostępu do zasobów, innych serwisów?
Będziemy korzystali z tych samych mechanizmów / kluczy.
Trzeba będzie wygenerować nowe klucze.
Zmienia się mechanizm uwierzytelniania.
W ramach migracji może okazać się, że nie można wykorzystywać tych samych sposobów na uwierzytelnienie co dotychczas. Trzeba więc przygotować dodatkowe klucze czy zaplanować zmianę uprawnień na poziomie infrastruktury.
Konfiguracja
Czy zmieni się sposób zarządzania konfiguracją?
Konfiguracja będzie taka sama.
Będzie inna konfiguracja, ale będzie się znajdować tym samym miejscu.
Zmienia się miejsce trzymania konfiguracji i dostępu do niej.
Często podczas migracji chcemy również poprawić nieefektywne przechowywanie konfiguracji. Ale jeśli pominiemy odpowiednie testy, to nowy serwis się po prostu nie uruchomi.
Procesy CI/CD
Czy migracja wymaga aktualizacji na poziomie pipeline’u wdrożeniowego?
Brak zmian.
Trzeba zmienić adresy, ale poza tym nic.
Trzeba zmienić w zasadzie cały system testów i wdrożeń.Pamiętaj, że im bliżej trzeciej odpowiedzi, tym większy koszt związany z migracją.
Dwa systemy
Jeśli na produkcji działają już dwa systemy / dwie bazy / dwa procesy, to musimy mieć świadomość, że mocno utrudni to nam migrację, ponieważ zduplikuje (i tak już dużą) ilość problemów.
Utrzymanie spójności
Czy dane będą zmieniane w obu serwisach? Czy będą odczytywane w obu?
Zmiana tylko w nowym, odczyt tylko w starym.
Zmiana tylko w nowym, odczyt w obu.
Zmiana tylko w starym, odczyt w obu.
Zmiana i odczyt w obu.
Im więcej systemów naraz odczytuje i zapisuje dane, tym droższe są procesy utrzymywania spójności. Aby migracja się udała, wystąpi w tym przypadku konieczność zastosowania praktyk Dual Write, czy Change Data Capture (artykuły odnoszą się do bazy danych, ale to samo można przenieść na poziom całych systemów).
Zatrzymanie podziału
Jak długo taka sytuacja ma trwać?
Kilka dni
Kilka tygodni, miesięcy
Druga odpowiedź zwiastuje olbrzymie wydatki konieczne do utrzymywania procesów w obu systemach. Trzeba oczywiście też odpowiednio argumentować koszt takiego działania do interesariuszy.
Koszta utrzymania
Czy i jakie ponosimy koszty dookoła utrzymania dwóch wersji?
Brak kosztów.
Koszt jednorazowy – pracy zespołu technicznego.
Koszt jednorazowy – pracy zespołu operacyjnego.
Koszty stałe.
Brak zastanowienia się nad powyższym powoduje, że lekceważymy rosnące straty związane z utrzymaniem obu systemów w ruchu.
Elementy okołotechniczne
…czyli wszystko, co jest techniczne, ale nie spasowało wyżej 😃
Monitoring
> Jak sprawdzimy, czy migracja idzie dobrze, czy źle?
System logów
Sondy na bazie danych
Mechanizmy różnicowe bazy migrowanej i zmigrowanej
Alerting
Dobry system monitorowania pozwala nam szybko zareagować, gdy coś pójdzie nie po naszej myśli.
Weryfikacja sukcesu
Jak zweryfikujemy, że się udało? Jeśli migracja jest krokowa, jak potwierdzimy, że możemy kontynuować?
100% danych zostanie zmigrowanych.
Nie będzie żadnego żądania do starego serwisu.
Klient przez 2 tygodnie nie zgłosi problemu.
Wyznaczenie takich kroków pozwala nam osiągnąć 2 rzeczy. Raz, że lepiej wiemy co monitorować. Dwa, że zmniejsza paraliż decyzyjny organizacji.
Wstępne testy
Co możemy przetestować, zanim jeszcze zaczniemy na poważnie?
Migracja bazy, serwisu.
Uruchomienie procesów biznesowych.
Uruchomienie procesów raportowych.
Dużej części problemów możemy uniknąć, przeprowadzając testy na sucho. Możliwe, że migracja bazy przejdzie gładko, ale już uruchomienie typowego procesu klienta rozwali cały system. Tylko dzięki testom dowiemy się o tym zawczasu.
Aspekty organizacyjno-procesowe
Migracja to temat mniej lub bardziej związany z pracą wielu osób na różnych szczeblach. I to też trzeba przemyśleć.
Lider
Kto odpowiada za powodzenie migracji? Czy jest taka osoba?
Jest taka osoba
Jest to zbiór kilku osób
Nie ma takiej osoby
W przypadku kilku osób dobrze uzgodnić wcześniej odpowiedzialności. Inaczej część zadań zostanie pomiędzy i nikt ich nie podejmie.
A jeśli nie ma takiej osoby, to lepiej ją zorganizować 😉
Komunikacja
Jacy są interesariusze tej zmiany? Jakich informacji wymagają?
Biznes
Zespoły zależne
Dział bezpieczeństwa, prawny
Wyższe kierownictwo
Często w ramach komunikacji pomijane są określone grupy osób. A później pominięte osoby eskalują problemy. Wykorzystaj Stakeholder Mapping by nie pominąć nikogo.
Procesy
Czy klienci / pracownicy wewnętrzni będą inaczej korzystać z systemu po migracji? Jakie procesy się zmienią?
Nic się nie zmieni.
Zmieni się tylko część procesów.
Procesy na różnych poziomach będą działały inaczej.
Odpowiedź na to pytanie wskaże na jak dużą skalę musimy przygotować nowe instrukcje bądź przeprowadzić szkolenia. Brak jasnych reguł spowoduje znaczące koszty operacyjne po stronie firmy.
Dokumentacja
Czy trzeba dostosować dokumentację do nowego stanu rzeczy?
Nie trzeba dostosowywać dokumentacji.
Istnieją obszary, gdzie trzeba wykonać poprawki.
Nie ma dokumentacji – nie ma problemu 😃
Warto zaplanować aktualizacje dokumentacji - później nie mamy rozbieżności w informacjach. W przypadku ostatniego punktu może to być wskazówka, by jednak jakąś dokumentację stworzyć 😉
Wsparcie po migracji
Jakie jest wymagane wsparcie po zakończeniu migracji?
Zakładamy, że uczestnicy sami sobie ze wszystkim poradzą.
Kilka osób może nie działać efektywnie.
Jest duża szansa, że będzie spore zamieszanie.
Może się okazać, że musimy przeznaczyć znaczne środki na wsparcie naszych klientów czy pracowników po zakończeniu migracji. Dużo zależy od skali zmian jakie określiliśmy w poprzednich krokach – im większy zakres, tym potencjalnie większe potrzebne wsparcie.
Plan - nasz i zespołów zależnych
Z odpowiedzi na powyższe pytania, powinieneś być w stanie określić pulę tematów, którymi trzeba się zająć w ramach migracji. Trzeba to teraz zaplanować.
Osoby odpowiedzialne
Kto wykonuje poszczególne zadania?
Nasz zespół
Zespoły zależne
Zespoły spoza firmy
SRE
Gdy nie wiemy kto robi dane zadanie, to jest duża szansa, że zbyt późno powiadomimy tę grupę. A wtedy ona nie znajdzie dla nas czasu. I cała migracja się opóźni.
Zależności
Które zadania zależą od siebie? Jak na siebie wpływają?
Większość zadań jest niezależnych.
Kilka kwestii od siebie zależy.
Mamy ośmiornicę z mackami zależności do wszystkich zadań.
To pozwoli nam poznać miejsca, które mogą być najbardziej problematyczne do dowiezienia. Możemy też zauważyć miejsca, gdzie możemy zrównoleglić pracę. A to przełoży się na szybsze dowiezienie całości.
Priorytetyzacja
Które tematy muszą się rozpocząć najpierw? Jakie są deadline’y na poszczególne zadania?
Zadania, które są na początku.
Zadania mające zależności wstępne.
Zadania będące uwieńczeniem całości
Dzięki temu zbudujemy sobie harmonogram działań, który ułatwi nam zarządzanie całym procesem.
Formy komunikacji
W jaki sposób chcemy się komunikować w ramach postępu z planem
Kanały komunikacji na Teams / Slack
Spotkania cykliczne
Tablice do zarządzania zadaniami
To jest niby kwestia podstawowa, ale pominięta, wprowadza 10x więcej chaosu niż kosztuje nas dogranie tego na początku.
Podsumowanie
Mam nadzieję, żę powyższe opracowanie Cię nie przeraziło 😬
Niestety, migracje to cwane bestie i potrafią rozłożyć nawet najlepsze plany na łopatki. Jednocześnie, jak mówi przysłowie: Szczęście sprzyja przygotowanym. Więc im więcej przemyślisz wcześniej, tym większej ilości problemów uda Ci się uniknąć 😊
A Ty, jakie pytania sobie zadajesz dookoła migracji?