Propozycja migracji może wydawać się kompletna, gdy zawiera listę serwerów i środowisko docelowe. Trudniejsze pytania dotyczą pracy, którą te serwery obsługują. Czy pracownicy będą mogli nadal przetwarzać zamówienia? Kiedy uruchamia się zaplanowany eksport? Kto sprawdzi rekordy po przeniesieniu? Plan migracji do chmury powinien łączyć decyzje infrastrukturalne z tymi codziennymi czynnościami. Poniższa kolejność pomoże przełożyć ogólny zamiar migracji na prace, które można poddać przeglądowi.
Na tej stronie
Określ usprawnienie operacyjne
Zastąp cel „przenieść się do chmury” powodem, który można ocenić. Być może wydania zależą od jednego ręcznie konfigurowanego serwera albo w okresie wzmożonego ruchu potrzebna jest wydajność, której obecne środowisko nie zapewnia. Opisz obecne działanie, zanim określisz przyszłe środowisko. Bez takiego punktu odniesienia trudno stwierdzić, czy migracja rozwiązała pierwotny problem, czy tylko zmieniła miejsce jego występowania.
- Wskaż proces, którego dotyczy zmiana, i osobę za niego odpowiedzialną.
- Opisz możliwą do zaobserwowania poprawę, na przykład powtarzalny proces wdrażania.
- Wymień ograniczenia, które migracja musi uwzględnić.
Zmapuj połączenia wokół każdej aplikacji
Dla każdej aplikacji spisz bazę danych, magazyn plików, zadania cykliczne, usługi zewnętrzne i wymagania dostępowe. Poproś osoby odpowiedzialne za jej utrzymanie o przegląd tej mapy. W inwentaryzacji serwerów łatwo przeoczyć nocny raport lub połączenie z dostawcą. Zaznacz, które zależne elementy trzeba przenieść razem, a które połączenia mogą pozostać bez zmian podczas etapowego przejścia.
Wybierz sposób migracji dla każdej aplikacji
Przykładowa decyzja: portal klienta korzysta ze wspieranego środowiska uruchomieniowego, lecz współdzieli bazę danych ze starszą aplikacją księgową. Przeniesienie portalu jako pierwszego może mieć sens tylko wtedy, gdy połączenie z pozostającą bazą spełnia uzgodnione wymagania dostępu i wydajności. W przeciwnym razie przenieś powiązane systemy razem lub najpierw rozwiąż zależność. Porównaj bezpośrednie przeniesienie, ukierunkowane zmiany i przebudowę z potrzebami danej aplikacji — całe środowisko nie musi korzystać z jednej metody.
Zaprojektuj utrzymanie nowego środowiska
Przypisz odpowiedzialność za dostęp, wdrożenia, alerty, kopie zapasowe i przeglądy wydatków. Oszacuj zapotrzebowanie na podstawie dostępnych danych o użyciu, uwzględniając spokojniejsze okresy i szczyty. Sprawdź, jak zmienia się szacunek wraz ze wzrostem ilości przechowywanych danych lub ich transferem między usługami. Użyteczna rozmowa o kosztach wyjaśnia założenia i to, co będzie monitorowane po uruchomieniu, zamiast traktować pierwsze oszacowanie jak stały rachunek za utrzymanie.
- Kto może zmieniać ustawienia środowiska produkcyjnego?
- Kto reaguje, gdy zadanie kończy się błędem?
- Jak będzie sprawdzane odtwarzanie z kopii zapasowych?
Ustal warunki wycofania przed przełączeniem
Dla przykładowego portalu uzgodnij, jak zespół zweryfikuje logowanie, składanie zamówień i liczbę rekordów przed udostępnieniem nowego środowiska. Określ, które błędy wstrzymują przejście i kto podejmuje tę decyzję. Jeżeli po przełączeniu użytkownicy mogą tworzyć nowe rekordy, samo skierowanie ruchu na stary serwer nie wystarczy — potrzebny jest uzgodniony plan postępowania z tymi rekordami. Przećwicz sekwencję działań, uwzględniając moment, po którym wycofanie wymaga dodatkowej pracy nad danymi.
Zamknij migrację weryfikacją działania
Po przeniesieniu porównaj procesy, zadania cykliczne, alerty i wzorce użycia z uzgodnionym punktem odniesienia. Przypisz osobę odpowiedzialną do każdego nierozwiązanego problemu. Wyłącz stare środowisko dopiero wtedy, gdy zespół zakończy kontrole związane z przejściem i zdecyduje, które dane lub konfiguracje trzeba zachować. Udostępnij mapę aplikacji i instrukcje odtwarzania osobom, które będą utrzymywać usługę.