Migracja serwerów do datacenter — jak zrobić to bez chaosu?

Dlaczego migracja bez planu kończy się źle

Najczęstszy scenariusz awarii podczas migracji wygląda tak: firma decyduje się przenieść serwery w weekend, wyznacza termin na piątek wieczór, okazuje się, że jeden z systemów ma zależność od lokalnego serwera DNS, który miał zostać przeniesiony jako ostatni. Przez całą sobotę aplikacja produkcyjna nie działa, bo nie może rozwiązywać nazw wewnętrznych. Nikomu nie przyszło do głowy, żeby tę zależność sprawdzić przed migracją.

Inne typowe błędy: brak pełnego backupu przed migracją, transport sprzętu bez opakowania ESD, uruchamianie systemów bez testów podstawowej łączności, brak planu rollback, brak osoby decyzyjnej dostępnej w nocy. Każdy z tych błędów z osobna jest poważny — razem gwarantują katastrofę. Migracja to projekt, który wymaga przygotowania proporcjonalnego do krytyczności migrowanej infrastruktury.

Faza 0: zakres i kolejność migracji

Zanim cokolwiek zaczniesz planować, ustal: co migrujemy, a co zostaje. Nie każdy system musi trafić do datacenter — część może zostać w biurze, część może trafić do chmury, część może zostać zlikwidowana, bo od lat nikt z niej nie korzysta. Inwentaryzacja zawsze ujawnia systemy, o których istnieniu połowa zespołu IT nie wiedziała.

Kolejność migracji ma znaczenie. Zasada ogólna: zacznij od systemów najmniej krytycznych i najmniej powiązanych z resztą środowiska. Daj sobie tydzień na obserwację, zanim przejdziesz do kolejnego systemu. Nie migruj wszystkiego naraz — to błąd, który zamienia projekt migracji w projekt odtwarzania środowiska po awarii.

Inwentaryzacja przed migracją

Sprzęt: model serwera, procesor, RAM, liczba i typ dysków, karty sieciowe (ile portów, prędkość, MAC), karty HBA, karty RAID i ich konfiguracja, firmware BIOS/IPMI/iDRAC. Dla każdego urządzenia sieciowego: model, wersja firmware, konfiguracja portów, VLANy, STP, LAG. Nie polegaj na tym, co jest w dokumentacji — sprawdź stan faktyczny.

Zależności między systemami: który serwer komunikuje się z którym, na jakich portach, przez jakie adresy. Narzędzia: netstat/ss na serwerach Linux, netflow na switchach, Wireshark jeśli musisz zrozumieć ruch aplikacyjny. Certyfikaty: sprawdź daty ważności wszystkich certyfikatów SSL/TLS — migracja to dobry moment, żeby nie odkryć, że certyfikat wygasł dwa tygodnie temu.

Adresy IP i DNS: udokumentuj każdy statyczny adres IP, każdy wpis DNS (wewnętrzny i zewnętrzny), każdy NAT/PAT na firewallach. Jeśli zmieniasz pule adresowe przy okazji migracji — zaplanuj przepisanie konfiguracji aplikacji z wyprzedzeniem. Zmiana adresu IP serwera bazy danych po migracji, gdy 15 aplikacji ma go w config.ini na sztywno, to praca na kilka godzin.

Planowanie okna serwisowego

Okno serwisowe to czas, w którym systemy mogą być niedostępne. Dla większości firm to noc z piątku na sobotę lub noc z soboty na niedzielę. Ustal długość okna i trzymaj się go — jeśli plan zakłada 4 godziny, a w połowie okazuje się, że idzie źle, masz czas na rollback i odtworzenie stanu przed migracją przed porankiem.

Kto musi być dostępny: co najmniej dwóch inżynierów (jeden w DC, jeden zdalnie lub na miejscu), osoba odpowiedzialna za decyzję o rollbacku, kontakty do providerów (DC, ISP, dostawca aplikacji, wsparcie sprzętu). Komunikacja z użytkownikami: wyślij powiadomienie minimum 48h przed oknem, opisz zakres, podaj czas planowanego przywrócenia, podaj numer kontaktowy.

Backup i punkt przywrócenia

Pełny backup PRZED migracją — to nie jest opcja. Backup musi być zrobiony, zweryfikowany i przechowywany w miejscu niezależnym od migrowanego środowiska. Weryfikacja oznacza: test odtworzenia przynajmniej jednej maszyny lub przynajmniej sprawdzenie integralności plików backupu (checksums). Backup, którego nie przetestowałeś, to backup, który może nie działać.

Gdzie jest kopia: jeśli cały sprzęt jedzie do DC ciężarówką, backup musi być w innym miejscu — na taśmie w biurze, w chmurze, na dedykowanym serwerze backupu. Najgorszy scenariusz: ciężarówka z serwerami i pendrivem z backupem rozbija się w drodze. Brzmi absurdalnie, ale zasada 3-2-1 istnieje właśnie po to, żeby takich sytuacji unikać.

Transport fizyczny sprzętu

Każdy serwer pakowany do transportu: dokumentacja zawartości pudła (zdjęcia przed spakowaniem, lista seriali), opakowanie ESD dla kart i dysków wyjętych z obudowy, taśma bąbelkowa lub pianka dla ochrony mechanicznej. Dyski SSD i HDD są wrażliwe na wibracje i wstrząsy — nie kładź serwerów na boku podczas transportu (chyba że są do tego przeznaczone).

Kto jedzie: co najmniej jedna osoba techniczna, która wie co jest w którym pudle i ma dostęp do dokumentacji. Nie wysyłaj serwerów kurierem, jeśli nie musisz — jeśli musisz, wybierz kuriera z ubezpieczeniem sprzętu IT i śledzeniem w czasie rzeczywistym. Czas dostarczenia sprzętu do DC musi być wliczony w okno serwisowe.

Uruchomienie w DC i testy

Kolejność uruchamiania: najpierw infrastruktura sieciowa (switche, firewall, router), potem storage i serwery backupu, potem AD/DNS/DHCP (jeśli migrujesz kontrolery domeny), potem pozostałe serwery według zależności. Uruchomienie serwera aplikacyjnego przed bazą danych, do której się łączy, to strata czasu na błędy, które i tak się pojawią.

Testy podstawowe: ping, połączenie SSH/RDP, rozwiązywanie DNS, dostępność usług na portach aplikacyjnych. Testy aplikacyjne: logowanie, operacja CRUD, raport z bazy danych, wysyłka e-maila, jeśli aplikacja to robi. Kto wykonuje testy: przedstawiciel biznesowy lub osoba znająca aplikację — inżynier może potwierdzić, że port 443 odpowiada, ale nie to, że faktura wystawia się poprawnie.

Rollback — kiedy i jak się wycofać

Rollback to decyzja, która musi być podjęta z wyprzedzeniem, nie w środku paniki. Ustal progi: jeśli do godziny X system nie jest uruchomiony i przetestowany, wracamy. Kto podejmuje decyzję o rollbacku? To musi być jedna osoba, z uprawnieniami, dostępna przez cały czas okna serwisowego. Dyskusja zbiorowa o rollbacku o 3:00 w nocy, gdy presja rośnie, nie prowadzi do dobrych decyzji.

Jak wracasz: zabranie sprzętu z powrotem do poprzedniej lokalizacji lub uruchomienie systemu z backupu w starej lokalizacji — zależy od tego, czy stara lokalizacja jest dostępna. Dlatego właśnie nie rozbieraj starego środowiska przed potwierdzeniem, że nowe działa. Zostaw je przez minimum 2 tygodnie jako fallback.

Monitoring przez pierwsze 72 godziny po migracji

Pierwsze 72 godziny po migracji to czas podwyższonej gotowości. Monitoruj: dostępność usług (HTTP, ICMP, SMTP), wykorzystanie CPU i RAM (nowe środowisko może mieć inne charakterystyki wydajnościowe), logi systemowe (błędy, które nie powodują awarii od razu, ale kumulują się), pojemność dysków (backup po migracji może być większy niż zakładałeś).

Obserwuj też zachowanie użytkowników: wolniejsze działanie aplikacji w godzinach szczytu, problemy z logowaniem, błędy przy specyficznych operacjach — to sygnały, że coś nie działa tak jak powinno. Lepiej wykryć problem w 48. godzinie niż gdy użytkownik eskaluje do zarządu. Po 72 godzinach możesz formalnie zamknąć projekt migracji — ale monitoring zostawiasz na stałe.