Przeczytaj wersję webową.

Migruję do V2. O co zapytać?

Cześć!

W ramach dzisiejszego wydania newsletteru, weźmiemy na tapet bardzo życiowy, z perspektywy lidera technicznego, temat. Porozmawiamy 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.

Standardowo, czeka również, przygotowana specjalnie dla Ciebie, inżynierska prasówka.

A więc w dzisiaj mam dla Ciebie:

Miłego czytania 😀

Inżynierska prasówka

1. Dependencies In Fast(er) Growing Companies – John Cutler
   Zależności to temat, który potrafi rozłożyć niejedną organizację inżynierską. John Cutler, w swoim cyklu artykułów, opisuje wyczerpująco, jak sobie z nimi radzić: skąd biorą się problemy, jakie wyróżniamy poziomy zależności, jakie mamy możliwości na zmniejszenie problemów każdej z nich. Temat opisany w głęboki sposób, ale dla Johna warto poświęcić trochę więcej uwagi.
   https://cutlefish.substack.com/p/tbm-261-dependencies-in-faster-growing

2. Measuring developer productivity at Airbnb - Christopher Sanson
   Mierzenie to zagadnienie coraz bardziej dotyczące liderów technicznych. Kiedy stawiamy pierwsze kroki, warto uczyć od seniorów branży, jakich błędów nie popełniać. Chris z Airbnb opowiada, jak ten proces wygląda u nich: DORA, co i jak mierzyć, jakie eksperymenty przeprowadzać, skąd czerpać dane. Konkretnie, przystępnie, interesująco.
   https://open.spotify.com/episode/6Fw1mYobTWy2QJJm3jNglZ?si=GD840Qu9T2eTNa_wTTYMWg

3. DDD in large product portfolios - Andreas Pinhammer
   Ciekawych case studies nigdy dość. Szczególnie w temacie Domain-Driven Design. Na nagraniu z DDD Europe Andreas opowiada, jak dokonywali dużych zmian produktowych w swoim portfolio. I oczywiście, jak im w tym pomogły techniki dookoła DDD.
   https://youtu.be/FzycqiJVioI?si=mC585FFMWDRdIxX1

4. 11 microservices design patterns for better architecture - Capital One Tech
   Bardzo przystępne podsumowanie wzorców dookoła mikroserwisów. Bez nadmiaru technicznych detali, ale przecież nie zawsze o to chodzi. Artykuł w ramach inspiracji i bodźca do zgłębienia tematu na własną rękę.
   https://medium.com/capital-one-tech/10-microservices-design-patterns-for-better-architecture-befa810ca44e

5. Platform Strategy: Innovation Through Harmonization - Gregor Hohpe
   Odpowiedzialności zespołu platformowego coraz częściej pojawiają się na tapecie działów inżynierskich. Aby podejść do tematu na poważnie warto przyjrzeć się mu z perspektywy osób, które zjadły na nim zęby. Taką osobą jest na pewno Gregor z AWS, który pomaga wdrażać takie platformy w firmach.
   https://techleadjournal.dev/episodes/157/

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?

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)