Checklista migracji do chmury — plan, testy i rollback

1. Ustal zakres i przygotuj kartę migracji

Wypełniaj osobną checklistę dla konkretnego obciążenia, a nie dla „całej chmury”. Obciążeniem może być aplikacja wraz z bazą i zależnościami, usługa plikowa albo system analityczny. Zbyt szeroki zakres ukrywa różne poziomy krytyczności; zbyt wąski pomija komponenty niezbędne do działania.

2. Zrób inwentaryzację systemu, danych i zależności

Najczęstsza luka migracyjna nie dotyczy docelowej maszyny, lecz niewidocznej zależności: wpisu DNS, certyfikatu, serwera czasu, konta usługi, reguły IP, zadania nocnego albo wymiany plików z partnerem. Inwentaryzację trzeba potwierdzić obserwacją ruchu i rozmową z właścicielami, a nie tylko starym diagramem.

• Komponenty: spisz aplikacje, bazy, kolejki, magazyny, maszyny, kontenery, zadania okresowe, wersje i elementy po zakończeniu wsparcia.
• Przepływy: zmapuj połączenia przychodzące i wychodzące, porty, protokoły, wolumen, opóźnienie oraz wymagany kierunek inicjowania sesji.
• Tożsamości: zinwentaryzuj użytkowników, grupy, konta techniczne, klucze, certyfikaty, tokeny, integracje SSO i proces usuwania dostępu.
• Dane: wskaż właściciela każdego zbioru, klasyfikację, rozmiar, tempo wzrostu, retencję, format, miejsce kopii i wymagania lokalizacyjne.
• Zależności zewnętrzne: potwierdź DNS, pocztę, płatności, katalog tożsamości, monitoring, kopie, repozytoria, licencje, urządzenia i partnerów.
• Profil pracy: zmierz ruch, wykorzystanie zasobów, czasy odpowiedzi, błędy, szczyty sezonowe i typowy koszt obecnego środowiska.
• Stan odtworzenia: zapisz datę ostatniego pełnego testu kopii oraz rzeczywisty czas i punkt odzyskania.
• Właścicielstwo: do każdego elementu przypisz osobę odpowiedzialną i decyzję: przenieść, pozostawić, zastąpić albo wyłączyć.

3. Opisz środowisko docelowe i metodę migracji

Najpierw narysuj stan docelowy, potem wybierz ruch danych i kolejność. CISA podkreśla, że jedna organizacja może potrzebować różnych strategii dla różnych aplikacji. Przeniesienie bez zmian (rehost) skraca część prac, ale zachowuje ograniczenia źródła; replatforming lub refaktoryzacja zmieniają więcej elementów i wymagają szerszych testów.

• Wybierz dla każdego komponentu metodę: wycofanie, pozostawienie, zastąpienie usługą, rehost, replatforming albo refaktoryzacja — i zapisz uzasadnienie techniczne.
• Narysuj docelowe konta lub projekty, regiony, strefy, sieci, punkty wejścia, przepływy danych, tożsamości, logi, kopie i połączenie ze środowiskiem źródłowym.
• Potwierdź dostępność wybranej usługi, funkcji, limitów, typu wsparcia i SLA w docelowym regionie.
• Zgrupuj razem elementy, które nie tolerują opóźnienia albo nie mogą bezpiecznie działać w rozdzielonym środowisku.
• Zaplanuj mechanizm synchronizacji i rozstrzygania zmian w okresie, gdy źródło i cel działają równolegle.
• Oszacuj czas transferu na podstawie rzeczywistego wolumenu, przepustowości, narzutu szyfrowania i okna zmiany; wykonaj próbę na reprezentatywnej próbce.
• Sprawdź format eksportu danych i konfiguracji, zależności od usług własnościowych oraz koszt transferu wychodzącego.
• Zdefiniuj stan źródła po przełączeniu: tylko do odczytu, gotowy do rollbacku, archiwizowany albo wyłączany po zatwierdzonym okresie.

Przepływ6 etapów

Pobierz diagram SVG

4. Porównaj odpowiedzialność klienta i dostawcy

Dostawca zabezpiecza chmurę w zakresie opisanym dla produktu, a klient zabezpiecza własne użycie usługi. W IaaS po stronie klienta pozostaje więcej warstw niż w PaaS i SaaS, lecz dane, konta, uprawnienia i decyzje konfiguracyjne nie znikają w żadnym modelu. Poniższa macierz zamienia ogólną zasadę na dowody potrzebne przed produkcyjnym uruchomieniem.

Macierz jest punktem startowym, nie interpretacją umowy. Granicę należy potwierdzić osobno dla każdej używanej usługi, konfiguracji i podwykonawcy. Pełną macierz on-prem/IaaS/PaaS/SaaS zawiera model współdzielonej odpowiedzialności, a zakres usług wyjaśnia przewodnik po IaaS, PaaS i SaaS.

5. Przygotuj landing zone, tożsamość i zabezpieczenia

Produkcyjnego systemu nie należy przenosić do przypadkowego konta utworzonego na potrzeby testu. Landing zone stanowi przygotowany fundament organizacyjny i techniczny: hierarchię zasobów, konta, sieci, IAM, polityki, logowanie i rozliczenia. Zakres powinien odpowiadać pierwszemu obciążeniu, ale umożliwiać kontrolowane dodawanie następnych.

• Struktura: rozdziel środowiska produkcyjne i nieprodukcyjne, określ właścicieli kont, subskrypcji lub projektów oraz ścieżkę zatwierdzania nowych zasobów.
• Tożsamość: zintegruj katalog, używaj grup zamiast nadań osobowych, oddziel tożsamości ludzi i usług, wymuś MFA dla uprzywilejowanego dostępu.
• Konto awaryjne: przygotuj chroniony dostęp break-glass niezależny od typowej awarii logowania i sprawdź go w kontrolowanym teście.
• Najmniejsze uprawnienia: usuń role tymczasowe po migracji, ogranicz stałych administratorów i zaplanuj cykliczny przegląd dostępów.
• Sieć: zatwierdź trasy, DNS, zapory, dostęp administracyjny, egress i połączenia hybrydowe; przetestuj również zablokowane kierunki.
• Guardrails: ustaw polityki zapobiegające niedozwolonym regionom, publicznym zasobom albo wyłączeniu wymaganych logów — adekwatnie do projektu.
• Logi: włącz zdarzenia administracyjne, IAM, sieci i danych przed rozpoczęciem migracji; centralizuj je i ogranicz możliwość modyfikacji.
• Klucze i sekrety: przechowuj je w przeznaczonych usługach, ustal właścicieli, rotację, odzyskanie i sposób użycia przez automatyzację.
• IaC: wersjonuj definicje infrastruktury, wykonuj przegląd zmian, testuj je w środowisku nieprodukcyjnym i nie zapisuj sekretów w repozytorium.
• Koszt operacyjny: oznacz zasoby właścicielem, środowiskiem i centrum kosztu; ustaw budżety, alarmy oraz limity chroniące przed niekontrolowanym użyciem.
• Wsparcie: potwierdź aktywny poziom wsparcia, osoby uprawnione do zgłoszeń i kanał eskalacji działający również podczas awarii IAM.

6. Zabezpiecz transfer danych, kopie i odtwarzanie

Transfer jest zakończony dopiero wtedy, gdy można wykazać kompletność, spójność i możliwość użycia danych w systemie docelowym. CISA wskazuje kontrolę integralności podczas migracji; NIST zaleca planowanie ciągłości wraz z analizą wpływu, strategią odtworzenia, testami i utrzymaniem planu.

• Usuń z zakresu zbędne dane zgodnie z zatwierdzoną retencją; nie kopiuj automatycznie wszystkiego „na wszelki wypadek”.
• Ustal, kiedy źródło przejdzie w tryb tylko do odczytu albo jak będą synchronizowane zmiany powstające podczas transferu.
• Wykonaj pełną kopię przed zmianą i potwierdź możliwość odtworzenia bez użycia kont, kluczy lub narzędzi, które migracja może unieruchomić.
• Szyfruj kanał transferu, ogranicz dostęp do tymczasowych plików i ustal termin ich usunięcia.
• Porównaj sumy kontrolne, liczbę rekordów lub obiektów, kluczowe agregaty i relacje; sam zgodny rozmiar pliku jest niewystarczający.
• Sprawdź kodowanie, strefy czasowe, uprawnienia do obiektów, kolejność zdarzeń i zachowanie aplikacji na reprezentatywnej próbce.
• Włącz docelowy harmonogram kopii, retencję, ochronę przed usunięciem i alarm o nieudanym zadaniu przed go-live.
• Wykonaj pełny test odtworzenia w środowisku docelowym i zmierz rzeczywiste RTO oraz RPO.
• Zapisz, które dane pozostają w źródle, jak długo i kto po okresie stabilizacji może zatwierdzić ich archiwizację lub usunięcie.

7. Przeprowadź testy i podejmij decyzję go/no-go

Pilot powinien obejmować ten sam typ danych, połączeń i kontroli co produkcja, choć może działać w mniejszej skali. Test pozytywny pokazuje, że funkcja działa; test negatywny sprawdza, czy niedozwolony dostęp i błędna konfiguracja są blokowane albo wykrywane.

8. Wykonaj przełączenie z gotowym rollbackiem

Plan przełączenia powinien być sekwencją działań z właścicielami, oczekiwanym wynikiem i punktem kontroli. Nie zakładaj, że decyzję o powrocie można odłożyć do końca okna: po określonym czasie albo po zmianie schematu danych rollback może wymagać osobnej migracji wstecz.

Runbook powinien działać także bez głównego komunikatora, panelu administracyjnego lub katalogu tożsamości. Zapisz numery telefonów, alternatywny kanał, dane potrzebne do zgłoszenia u dostawcy i lokalizację instrukcji dostępną w sytuacji awarii.

9. Skontroluj środowisko po migracji

Migracja nie kończy się po zmianie DNS lub uruchomieniu aplikacji. Okres stabilizacji ma potwierdzić, że procesy operacyjne działają w nowym modelu odpowiedzialności i że środowisko źródłowe można bezpiecznie ograniczyć.

• Porównaj rzeczywiste zasoby, połączenia i dane z zatwierdzonym diagramem; usuń niekontrolowane elementy pilota.
• Cofnij tymczasowe role, klucze, wyjątki zapory, podwyższone limity i konta migracyjne.
• Sprawdź pierwsze wykonania kopii, zadań okresowych, rotacji sekretów, raportów, alarmów i integracji z partnerami.
• Porównaj wydajność, błędy, dostępność, użycie i koszt z progami z karty migracji.
• Zaktualizuj runbooki, inwentaryzację, diagramy, właścicieli, procedurę incydentu i instrukcję odtworzenia.
• Wykonaj przegląd odpowiedzialności dla każdej usługi, zwłaszcza jeśli pilot został zastąpiony innym wariantem produktu.
• Zamknij lub zarchiwizuj źródło dopiero po akceptacji właściciela danych, upływie okresu rollbacku i potwierdzeniu wymaganych kopii.
• Zaplanuj cykliczne testy odtworzenia, przeglądy dostępu, aktualizację obrazu/systemu, kontrolę kosztów i próbę eksportu.
• Przeprowadź retrospektywę i wprowadź poprawki do szablonu przed kolejną falą migracyjną.

Najczęstsze pytania o migrację do chmury