Przy większych migracjach problemem rzadko jest samo „przeniesienie maszyn”. Najwięcej ryzyka siedzi zwykle w zależnościach, kolejności działań, testach i założeniach, które wydają się oczywiste dopóki nie pojawi się pierwsza niespodzianka. Im większe środowisko, tym mniej miejsca na improwizację.

Co najczęściej bywa niedoszacowane

Przy migracji łatwo skupić się na warstwie technicznej i zapomnieć, że każda usługa ma swoje zależności:

  • DNS,
  • backup,
  • monitoring,
  • certyfikaty,
  • routingi,
  • integracje,
  • harmonogramy zadań,
  • skrypty administracyjne,
  • okna serwisowe i komunikację.

Sama maszyna wirtualna może zostać przeniesiona poprawnie, a mimo to usługa po zmianie będzie działać gorzej, bo zabrakło kontroli nad jednym z elementów dookoła.

Od czego zacząć planowanie

Najpierw trzeba podzielić środowisko nie według listy hostów, tylko według wpływu na usługi:

  • co jest krytyczne,
  • co jest zależnością,
  • co może być migrowane wcześnie,
  • co powinno iść dopiero po testach.

Dopiero potem ma sens układanie etapów.

Jeżeli migracja dotyczy środowiska produkcyjnego, dobrym oparciem jest administracja serwerami Linux, bo sama warstwa infrastruktury to za mało bez porządku w usługach, dostępach, backupie i planie zmian.

Co powinno znaleźć się w planie

Dobry plan migracji powinien zawierać:

  • kolejność przenosin,
  • warunki startu i warunki wstrzymania,
  • sposób weryfikacji po każdym etapie,
  • plan rollbacku,
  • listę zależności,
  • sposób monitorowania po zmianie,
  • wskazanie, kto odpowiada za decyzję o przejściu do następnego kroku.

To brzmi formalnie, ale właśnie taki porządek ogranicza chaos.

Co sprawdzić technicznie przed startem

Przed migracją warto przejść przez checklistę:

  • stan backupów i możliwość odtworzenia,
  • aktualność dokumentacji,
  • monitoring hostów i usług po zmianie,
  • wydajność po stronie storage i sieci,
  • zachowanie adresacji, DNS i certyfikatów,
  • wpływ na zadania cykliczne i integracje,
  • plan testów funkcjonalnych po migracji.

Warto też zawczasu ustalić, jak będzie wyglądał monitoring infrastruktury IT po przeniesieniu. To ważne, bo brak widoczności tuż po migracji bardzo szybko utrudnia ocenę, czy problem wynika z samej zmiany, czy z czegoś, co było w środowisku już wcześniej.

Co z wirtualizacją

W większych środowiskach dobrze przygotowana migracja warstwy wirtualizacyjnej daje duży efekt porządkowy i operacyjny. Z kolei w mniejszych firmach czasem nie potrzeba od razu rozbudowanej platformy z pełnym katalogiem funkcji. Jeżeli model działania jest prosty, a wymagania są rozsądne, środowisko oparte o prostszy host ESXi może znacząco ograniczyć koszt wejścia, pod warunkiem że nikt nie oczekuje po nim tego, co daje rozbudowana platforma klasy enterprise.

Tu najważniejsze jest uczciwe dopasowanie technologii do skali firmy, a nie wdrażanie „na wyrost”.

Co dzieje się po migracji

Największy błąd to uznać migrację za zakończoną w chwili uruchomienia usług po stronie nowej platformy. W praktyce bardzo ważny jest jeszcze okres po zmianie:

  • obserwacja wydajności,
  • potwierdzenie backupów,
  • potwierdzenie monitoringu,
  • weryfikacja harmonogramów i zadań,
  • sprawdzenie, czy nic nie działa „pozornie poprawnie”.

Podsumowanie

Duża migracja nie jest tylko projektem technicznym. To operacyjne przełożenie środowiska z jednego modelu pracy do drugiego. Im lepiej uporządkowany plan, tym mniej niepotrzebnego ryzyka i mniej improwizacji po drodze.

Powiązane artykuły

Jeżeli po migracji najważniejsze jest utrzymanie spokojnej widoczności usług, naturalnym uzupełnieniem będzie też tekst Monitoring infrastruktury IT bez szumu: jak ustawić alerty, które naprawdę pomagają.