Strategia testowania migracji do chmury: fazy, rodzaje testów i lista kontrolna
Strategia testowania migracji do chmury określa, co testujesz przed każdą falą migracji, w jej trakcie i po niej, oraz kryteria zaliczenia lub niezaliczenia, które decydują, czy obciążenie trafia na produkcję. Obejmuje funkcjonalność, integralność danych, wydajność, bezpieczeństwo i wycofanie zmian. Metoda: zmierz punkt odniesienia na starej platformie, wykonaj migrację testową, porównaj i przełączaj dopiero wtedy, gdy liczby się zgadzają.
Najważniejsze wnioski
- Zbierz punkty odniesienia, zanim cokolwiek przeniesiesz: czasy odpowiedzi, odsetek błędów, czasy przebiegu zadań wsadowych i liczby wierszy.
- Uzgodnij kryteria zaliczenia i wyzwalacze wycofania przed pierwszą falą, a nie w trakcie przełączenia.
- Korzystaj z funkcji testowych samych narzędzi migracyjnych: migracje testowe Azure Migrate i walidacja danych AWS DMS istnieją właśnie do tego.
- Rodzaje testów zależą od ścieżki migracji. Lift-and-shift potrzebuje głównie kontroli zgodności; refaktoryzacja wymaga pełnych testów funkcjonalnych i integracyjnych.
- Migracje testowe uruchamiaj w odizolowanej sieci. Microsoft przestrzega przed testowymi migracjami do produkcyjnej sieci wirtualnej.
- Testuj także po przełączeniu: obserwuj wskaźniki poziomu usług (SLI) przez co najmniej jeden pełny cykl biznesowy.
Czym jest testowanie migracji do chmury?
Testowanie migracji do chmury to zestaw kontroli dowodzących, że aplikacja, jej dane i infrastruktura działają po przeniesieniu co najmniej tak dobrze jak przed nim. Przebiega przez całą migrację, nie tylko na końcu.
Różni się od zwykłego testowania wydań na trzy sposoby:
- Zmienia się platforma, nie kod. W lift-and-shift kod jest ten sam, więc testujesz środowisko: sieć, tożsamość, wydajność storage, DNS i strefy czasowe.
- Dane się przemieszczają. Musisz udowodnić, że każdy wiersz i plik dotarł niezmieniony i że bieżące zmiany synchronizowały się aż do przełączenia.
- Chmura zachowuje się inaczej. Autoskalowanie, limity usług zarządzanych, opóźnienia regionalne i współdzielona infrastruktura mogą zmienić wydajność, nawet gdy nic innego się nie zmieniło.
Kryteria sukcesu pozostają takie same jak lokalnie: funkcje muszą działać, dane muszą być kompletne i poprawne, a użytkownicy nie mogą zauważyć spadku szybkości.
Cztery fazy strategii testowania migracji
Podziel testowanie na cztery fazy, każda z własnymi dowodami i akceptacją.
| Faza | Cel | Główne kontrole | Dowody |
|---|---|---|---|
| 1. Planowanie i punkt odniesienia | Wiedzieć, jak wygląda „dobrze” dziś | Mapa zależności, krytyczne ścieżki użytkownika, bieżące czasy odpowiedzi, czasy zadań wsadowych, wolumeny danych | Raport punktu odniesienia, uzgodnione kryteria zaliczenia |
| 2. Migracja testowa | Udowodnić, że obciążenie działa na celu | Rozruch i łączność, funkcjonalne testy dymne, integracje, walidacja danych, wydajność pod obciążeniem | Wyniki testów dla każdego obciążenia, lista defektów |
| 3. Przełączenie | Przełączyć bezpiecznie, z drogą powrotu | Końcowa synchronizacja i walidacja danych, kontrole DNS i certyfikatów, testy dymne, go/no-go | Runbook przełączenia z czasami, podpisane go/no-go |
| 4. Po migracji | Potwierdzić stabilność i dostroić | Monitoring SLI, akceptacja użytkowników, test kopii zapasowej i odtworzenia, kontrola kosztów | Raport hypercare, zamknięte defekty |
Faza 1: planowanie i punkt odniesienia
Zacznij od inwentarza aplikacji, baz danych, interfejsów i zaplanowanych zadań, a następnie uszereguj je według ryzyka biznesowego. Dla każdego obciążenia zapisz liczby, z którymi później będziesz porównywać: czas odpowiedzi p95 kluczowych transakcji, odsetek błędów, czas nocnego zadania wsadowego, rozmiar bazy i liczby wierszy.
Zamień je w kryteria. Na przykład: „wyszukiwanie zamówień p95 w granicach 10% punktu odniesienia”, „zero niezgodności wierszy w tabelach finansowych”, „nocne zadanie kończy się przed 06:00”. Książka Google SRE definiuje SLI jako „starannie zdefiniowaną ilościową miarę pewnego aspektu poziomu usługi”, a SLO jako wartość docelową tej miary (Google SRE book; cytat w naszym tłumaczeniu). Zapisanie kryteriów w tej formie czyni decyzję go/no-go obiektywną.
Faza 2: migracja testowa
Przenieś kopię obciążenia na cel i testuj ją tam, podczas gdy źródło nadal działa. Obie główne platformy to wspierają:
- Azure Migrate oferuje migrację testową, która uruchamia zreplikowane maszyny wirtualne w wybranej przez Ciebie sieci wirtualnej. Wytyczne Microsoft mówią, że migracja testowa do produkcyjnej sieci wirtualnej nie jest zalecana, ponieważ otwarte połączenia z infrastrukturą lokalną mogą powodować duplikaty maszyn lub zmiany DNS.
- AWS Application Migration Service (MGN) uruchamia instancje testowe z ciągle replikowanych serwerów, a replikacja trwa po teście. AWS nazywa dobrą praktyką testowanie co najmniej dwa tygodnie przed planowanym przełączeniem, aby był czas na naprawę tego, co znajdziesz.
Wykorzystaj tę fazę, by znaleźć niespodzianki: zaszyte w kodzie adresy IP, brakujące reguły zapory, kontrole licencji związane ze sprzętem i zadania wywołujące serwery, o których zapomniano przy migracji.
Faza 3: przełączenie
Przełączenie to wyćwiczony runbook, a nie improwizacja. Zamroź zmiany, wykonaj końcową synchronizację danych, zwaliduj dane, przełącz DNS lub cele load balancera i uruchom testy dymne. Każdy krok ma właściciela, planowany czas i działanie wycofujące.
Z góry zdefiniuj wyzwalacze wycofania, na przykład: „jeśli testy dymne zawiodą lub walidacja danych pokaże niezgodności 60 minut po przełączeniu, przywróć DNS na źródło”. Przećwicz wycofanie co najmniej raz podczas migracji testowych.
Faza 4: walidacja po migracji
Po uruchomieniu produkcyjnym porównuj SLI z punktem odniesienia przez co najmniej jeden pełny cykl biznesowy, w miarę możliwości z końcem miesiąca lub dniami szczytu. Przeprowadź testy akceptacyjne użytkowników, sprawdź odtworzenie z nowych kopii zapasowych i porównaj pierwszy rachunek za chmurę z szacunkiem. Dopiero potem wycofaj źródło.
Jakie rodzaje testów uruchomić?
Dopasuj rodzaje testów do ryzyka każdego obciążenia. Nie każda aplikacja potrzebuje każdego testu.
| Rodzaj testu | Co dowodzi | Typowe narzędzia |
|---|---|---|
| Funkcjonalne i regresyjne | Funkcje i ścieżki użytkownika nadal działają | Selenium, Playwright, istniejące zestawy testów |
| Integracyjne | API, kolejki komunikatów, transfery plików i usługi zewnętrzne się łączą | Testy kontraktowe, narzędzia do testów API, transakcje syntetyczne |
| Walidacja danych | Każdy wiersz i plik dotarł i się zgadza | Walidacja danych AWS DMS, sumy kontrolne, liczby wierszy, narzędzia do porównywania baz |
| Wydajnościowe i obciążeniowe | Czasy odpowiedzi i przepustowość spełniają cele, autoskalowanie działa | JMeter, k6, Gatling |
| Bezpieczeństwa i zgodności | Dostęp, szyfrowanie, reguły sieciowe i logowanie są poprawne | Narzędzia do postawy bezpieczeństwa chmury, skany podatności, przeglądy IAM |
| Odporności i DR | Obciążenie przetrwa awarie i da się je odtworzyć | Ćwiczenia failover, odtwarzanie kopii, AWS Fault Injection Service |
| Akceptacyjne użytkowników | Użytkownicy biznesowi potwierdzają przydatność systemu | Skryptowane UAT z akceptacją |
Realistyczne testy obciążeniowe odpowiadające Twojemu szczytowemu ruchowi opisuje nasza usługa testów obciążeniowych.
Jak walidować dane podczas migracji?
Waliduj dane na trzech poziomach: liczby, sumy kontrolne i porównanie wiersz po wierszu dla tabel krytycznych.
- Liczby: wiersze na tabelę, pliki na bucket, łączna liczba bajtów. Szybkie i wychwytuje rażące błędy.
- Sumy kontrolne i agregaty: sumy kwot, skróty kluczowych kolumn. Wychwytuje obcięcia i problemy z kodowaniem.
- Porównanie na poziomie wiersza: dla baz danych walidacja danych AWS DMS porównuje każdy wiersz źródła z wierszem celu i raportuje niezgodności, w tym zmiany przechwycone podczas bieżącej replikacji.
Warto zaplanować dwa praktyczne ograniczenia z dokumentacji AWS: walidacja wymaga klucza głównego lub unikalnego indeksu w każdej tabeli i zwiększa obciążenie zapytaniami po stronie źródła i celu. Ciężkie przebiegi walidacji planuj poza godzinami pracy lub uruchamiaj jako osobne zadania tylko do walidacji.
Testuj też to, co zmienia się celowo. Jeśli konwertujesz z Oracle na PostgreSQL, typy danych, collation i kolejność sortowania się różnią, więc porównuj wyniki zapytań, a nie tylko przechowywane wartości. Te konwersje omawia nasza usługa migracji baz danych.
Jak testowanie zmienia się wraz ze ścieżką migracji
- Rehost (lift and shift): skup się na zgodności środowiska. Sprawdź sieć, DNS, tożsamość, przepustowość storage, zadania kopii zapasowych i agentów monitoringu. Testy funkcjonalne mogą ograniczyć się do testu dymnego i krytycznych ścieżek.
- Replatform: gdy przenosisz bazę do usługi zarządzanej lub aplikację do kontenerów, dodaj walidację danych, testy wydajności i kontrolę limitów usług zarządzanych, takich jak liczba połączeń.
- Refactor: traktuj to jak nowe oprogramowanie. Przeprowadź pełne testy funkcjonalne, integracyjne i wydajnościowe oraz użyj wydań canary lub blue/green z feature flagami, aby ograniczyć ekspozycję.
Lista kontrolna testowania migracji do chmury
- Inwentarz i mapa zależności gotowe dla fali
- Punkty odniesienia zapisane dla krytycznych ścieżek, zadań wsadowych i wolumenów danych
- Kryteria zaliczenia i wyzwalacze wycofania zatwierdzone przez właściciela biznesowego
- Środowisko testowe odizolowane od sieci produkcyjnych
- Infrastruktura zdefiniowana jako kod, aby test i produkcja były zgodne (zobacz naszą usługę infrastruktury jako kodu w Terraform)
- Dane testowe zamaskowane tam, gdzie zawierają dane osobowe
- Migracja testowa wykonana, defekty naprawione i ponownie przetestowane
- Walidacja danych zaliczona dla wszystkich tabel w zakresie
- Test obciążeniowy przy oczekiwanym szczycie zaliczony
- Przegląd bezpieczeństwa wykonany: IAM, szyfrowanie, grupy zabezpieczeń, logowanie
- Wycofanie przećwiczone i zmierzone w czasie
- Runbook przełączenia z właścicielami i czasami zatwierdzony
- Dashboardy monitoringu i alerty po migracji uruchomione
- Odtworzenie kopii zapasowej przetestowane na nowej platformie
Jak pomaga Opsio
Opsio planuje i prowadzi migracje do chmury z testowaniem wbudowanym w każdą falę. Dla SilverRail Technologies Opsio przeniosło nordycki oddział firmy do AWS i połączyło go z globalną organizacją. Faza Mobilize obejmowała pilotażową migrację testową wybranych obciążeń, a proces migracji i usługi AWS dostosowano na podstawie tych testów. Dane przeniesiono natywnymi narzędziami PostgreSQL według szczegółowego planu przełączenia, a przełączenia odbywały się w wąskich oknach serwisowych, aby ograniczyć wpływ na klientów. Przeczytaj studium przypadku SilverRail.
Najczęściej zadawane pytania
Czym jest strategia testowania migracji do chmury?
To plan określający, jakie testy są uruchamiane przed każdą falą migracji, w jej trakcie i po niej, kryteria zaliczenia dla każdego z nich oraz kto zatwierdza. Obejmuje funkcje, dane, wydajność, bezpieczeństwo i wycofanie.
Jakie są fazy testowania migracji do chmury?
Planowanie i punkt odniesienia, migracja testowa, przełączenie oraz walidacja po migracji. Każda faza daje dowody, takie jak raporty punktu odniesienia, wyniki testów, podpisane go/no-go i raport hypercare.
Jak testować dane po migracji do chmury?
Porównaj liczby wierszy i sumy kontrolne wszystkich tabel oraz wykonaj porównania na poziomie wiersza dla danych krytycznych. W AWS walidacja danych DMS porównuje wiersze źródła i celu oraz raportuje niezgodności; wymaga klucza głównego lub unikalnego indeksu w każdej tabeli.
Czym testowanie lift-and-shift różni się od refaktoryzacji?
Lift-and-shift potrzebuje głównie kontroli zgodności środowiska i krytycznych ścieżek, bo kod się nie zmienia. Refaktoryzacja wymaga pełnych testów funkcjonalnych, integracyjnych i wydajnościowych, ponieważ w istocie wydajesz nowe oprogramowanie.
Jak długo monitorować po przełączeniu?
Co najmniej jeden pełny cykl biznesowy, w tym dni szczytu, takie jak koniec miesiąca, zanim wycofasz systemy źródłowe. Utrzymuj możliwość wycofania, dopóki uzgodnione kryteria są spełnione.
O autorze
Zasady redakcyjne: Artykuł napisał certyfikowany praktyk wskazany powyżej jako autor. Aktualizujemy go, gdy zmienia się opisywana technologia lub regulacja; daty powyżej pokazują ostatnią aktualizację. Opsio zachowuje niezależność redakcyjną — rekomendujemy rozwiązania na podstawie ich wartości technicznej, a nie relacji handlowych.