Migracje do chmury bez przestojów

Koszt przestoju rzadko sprowadza się do samej przerwy. To zamówienia, które nie zostały złożone, zgłoszenia, które przyjdą później, i fakt, że zaplanowane okno potrafi zamienić się w nieplanowane, gdy odtwarzanie danych trwa dłużej, niż zakładał harmonogram. Pytanie nie brzmi więc, jak zaplanować przestój. Brzmi: jak się bez niego obejść.

Cała praca tkwi w szczegółach. Nowe środowisko musi być faktycznym odpowiednikiem, a nie przybliżeniem: te same wersje runtime'u, te same zmienne środowiskowe, te same certyfikaty, te same zadania cykliczne. Dane muszą płynąć ze starego systemu do nowego na tyle sprawnie, żeby przełączenie było bezpieczne. Ruch musi dać się przenosić małymi porcjami, co zwykle oznacza load balancer, proxy albo DNS z krótkim TTL obniżonym kilka dni wcześniej, a nie godzinę przed.

Każdy etap musi też być odwracalny. Jeśli nowy system zaczyna zwracać błędy przy pięciu procentach ruchu, cofasz te pięć procent i szukasz przyczyny bez wpływu na klientów. To właśnie ta cecha sprawia, że dodatkowy nakład pracy się opłaca.

Osobną kwestią są sesje użytkowników i pliki, które aplikacja trzyma lokalnie. W układzie, w którym część ruchu idzie do starego systemu, a część do nowego, zalogowany klient nie może zostać wylogowany tylko dlatego, że trafił na inny serwer. Sesje muszą więc być wspólne dla obu środowisk, a przesyłane pliki dostępne z obu stron. To drobiazgi, które nie pojawiają się na schemacie architektury, a potrafią zepsuć dobrze zaplanowane przełączenie.

Z bazą danych jest odwrotnie. Jest jedna kopia uznawana za źródło prawdy, ciągle się zmienia, a w momencie, w którym dwa systemy uznają się za nadrzędne, masz problem z danymi, który kosztuje znacznie więcej niż awaria. To tutaj plan migracji się sprawdza albo rozsypuje.

Standardowe podejście to ciągła replikacja ze starej bazy do nowej, prowadzona wystarczająco długo, żeby opóźnienie było stabilnie niskie, a potem krótkie i dokładnie rozpisane przełączenie ścieżki zapisu. Tę sekwencję ćwiczymy wcześniej na odtworzonej kopii produkcji. Próba generalna nie jest tu opcjonalna. Tylko w ten sposób dowiesz się, ile przełączenie naprawdę trwa przy Twojej ilości danych, zamiast opierać się na szacunku.

Jeśli któregokolwiek z tych elementów brakuje, rozsądnie jest poczekać. Migracja przesunięta o tydzień kosztuje nieporównanie mniej niż taka, która ruszyła na systemie, którego nikt nie widzi.

Ustalamy też wcześniej, kto podejmuje decyzję o wycofaniu i przy jakich wartościach. Jeśli próg jest spisany przed startem, nikt nie negocjuje w trakcie, czy podwojony czas odpowiedzi to jeszcze norma, czy już powód do cofnięcia ruchu.

Do której kategorii należy Twój system, powiemy na etapie analizy. Część klientów przychodzi po projekt bez przestojów, a wychodzi z planem znacznie mniejszym, bo tyle w ich sytuacji wystarczy.