Migracja serwera do Microsoft Azure w firmie logistycznej spod Poznania
Jak po awarii klimatyzacji w lokalnej serwerowni przenieśliśmy TMS, kontroler domeny i serwer plików do chmury Azure
Snapshot
Kim był klient?
Klient prowadzi firmę logistyczną z flotą kilkudziesięciu pojazdów obsługujących transport krajowy i międzynarodowy. Struktura organizacyjna obejmuje siedzibę główną pod Poznaniem oraz dwa biura terenowe w innych miastach. Codzienna praca to zarządzanie flotą, śledzenie GPS pojazdów, integracje z platformami spedycyjnymi, wymiana EDI z kontrahentami, telematyka, aplikacje mobilne dla kierowców i raportowanie do organów państwowych. Wszystko to wymaga środowiska o gwarantowanej dostępności 24/7.
Infrastruktura serwerowa była zlokalizowana wyłącznie w siedzibie głównej, w pomieszczeniu pełniącym funkcję serwerowni – adaptowanym z dotychczasowego pomieszczenia gospodarczego. Konfiguracja sprzętowa obejmowała: klimatyzację instalowaną doraźnie kilka lat wcześniej, UPS bez aktualnej diagnostyki stanu baterii, dwa serwery fizyczne (aplikacyjny z bazą danych oraz kontroler domeny z serwerem plików) i pojedyncze łącze internetowe bez redundancji. Każdy z tych elementów stanowił pojedynczy punkt awarii.
Wyzwanie
Bezpośrednim impulsem do podjęcia decyzji o migracji była awaria klimatyzacji w lipcu, która – spotęgowana przez niewydolne wentylatory serwera – spowodowała przegrzanie i kilkugodzinną przerwę w funkcjonowaniu systemów. Analiza kosztów tego incydentu (utracone zlecenia, opóźnienia operacyjne, koszt nadgodzin pracowników, straty wizerunkowe) pokazała coś, co zatrzymało właściciela: pojedynczy taki przestój może przewyższać roczny koszt utrzymania infrastruktury chmurowej.
Pod warstwą tego jednego incydentu czaiły się systemowe problemy: brak redundancji łącza, brak prawdziwej diagnostyki UPS-a, serwerownia bez kontroli środowiskowej, brak gwarancji odtworzenia po awarii sprzętowej. Klient zdecydował o przeprowadzeniu kompleksowej migracji do chmury Microsoft Azure.
Analiza opcji – chmura publiczna, prywatna czy hybrydowa?
Pierwszym etapem projektu była analiza dostępnych modeli wdrożenia. Migracja do chmury nie zawsze oznacza pełne porzucenie lokalnej infrastruktury – istnieje kilka modeli, z których każdy ma określone zastosowanie.
- Chmura publiczna – wynajem zasobów obliczeniowych u dużego dostawcy. Klient płaci za rzeczywiste zużycie i otrzymuje gwarantowaną dostępność. Dane są przechowywane na infrastrukturze dostawcy.
- Chmura prywatna – dedykowana infrastruktura działająca w modelu chmurowym, fizycznie pozostająca własnością firmy lub jej dostawcy. Wyższy koszt początkowy i mniej elastyczne skalowanie.
- Model hybrydowy – łączy oba podejścia. Stosowany przy wymogach regulacyjnych lub w sytuacji, gdy część danych musi pozostać w siedzibie.
Dla klienta wybraliśmy chmurę publiczną Microsoft Azure z elementami hybrydowymi. Większość systemów została przeniesiona do chmury, natomiast jeden lokalny kontroler domeny pozostał w siedzibie w celu zapewnienia szybkiego logowania pracowników biurowych.
Argumentami za wyborem Azure były:
- istniejąca u klienta subskrypcja Microsoft 365, co umożliwiało naturalną integrację i ujednolicenie kont użytkowników,
- lokalizacja centrów danych w Europie (zgodność z RODO),
- wysoki poziom inwestycji Microsoft w bezpieczeństwo platformy,
- rozbudowany ekosystem usług dedykowanych branży logistycznej (analiza dużych zbiorów danych, integracje z systemami GPS).
Przed podjęciem decyzji wykonaliśmy szczegółową kalkulację TCO w trzech wariantach (minimalnym, zalecanym, premium) i porównaliśmy je z pełnym kosztem utrzymania lokalnej infrastruktury, korzystając między innymi z oficjalnego kalkulatora Azure. W rachunku lokalnym uwzględniliśmy nie tylko amortyzację sprzętu, ale również koszty energii elektrycznej, klimatyzacji, awarii, czasu administracyjnego oraz prognozowany koszt wymiany sprzętu w piątym roku eksploatacji. Analiza wykazała, że dla firmy o tej skali chmura w pełnym rachunku TCO wychodzi taniej niż lokalna infrastruktura. Dodatkowo zamienia inwestycję kapitałową (CAPEX) na przewidywalny koszt operacyjny (OPEX).
Plan migracji do Azure
Wdrożenie podzieliliśmy na cztery etapy.
Etap 1: Audyt i kategoryzacja systemów
Sporządziliśmy kompletną listę systemów, baz danych, aplikacji i zasobów plikowych. Dla każdego systemu oszacowaliśmy wymagane parametry środowiska docelowego – moc obliczeniową, pamięć operacyjną, przestrzeń dyskową oraz przepustowość sieciową. Zidentyfikowaliśmy zależności między systemami: relacje z bazami danych, integracje zewnętrzne, wymagania komunikacyjne.
Systemy sklasyfikowaliśmy w trzech kategoriach krytyczności:
- Krytyczne – których niedostępność zatrzymuje działalność operacyjną. Tu znalazły się system TMS oraz baza klientów.
- Ważne – których niedostępność istotnie utrudnia pracę, ale nie blokuje firmy w krótkim okresie. Należą do nich system kadrowo-płacowy, archiwum dokumentów oraz narzędzia raportowe.
- Pomocnicze – kilkugodzinna lub kilkudniowa niedostępność nie wpływa znacząco na działalność. Drukarki sieciowe, wewnętrzne narzędzia analityczne, repozytoria szablonów.
Klasyfikacja krytyczności określiła kolejność migracji oraz wymagany poziom redundancji w środowisku docelowym. Systemy krytyczne zostały zaplanowane w konfiguracji wysokiej dostępności z automatycznym przełączaniem między strefami Azure; systemy pomocnicze wdrożono w prostszej, ekonomicznej konfiguracji.
Etap 2: Konfiguracja środowiska docelowego w Azure
Pierwszym etapem technicznym była konfiguracja środowiska Azure: utworzenie subskrypcji, definicja struktury grup zasobów (osobnych dla środowiska produkcyjnego, testowego i kopii zapasowych), konfiguracja sieci wirtualnej, ustawień bezpieczeństwa, ról administracyjnych oraz polityk dostępu.
Bezpieczeństwo w chmurze zaczyna się od poprawnej konfiguracji środowiska – niewłaściwie skonfigurowana chmura stanowi zagrożenie porównywalne z błędnie skonfigurowanym serwerem lokalnym. Dlatego strukturę grup zasobów, segmentację sieci i polityki dostępu projektowaliśmy zanim ruszyliśmy z jakąkolwiek migracją danych.
Etap 3: Migracja systemów (serwer plików → TMS → reszta)
Migrację rozpoczęliśmy od serwera plików. Wybór ten był uzasadniony trzema kryteriami: największy wolumen danych umożliwiał weryfikację założonej przepustowości, brak krytycznych zależności od innych systemów ułatwiał diagnostykę, a relatywna prostota typu zasobu pozwalała zespołowi klienta zapoznać się z procesem migracyjnym przed bardziej złożonymi etapami. Wykorzystaliśmy mechanizm Azure File Sync, umożliwiający synchronizację danych między lokalnym serwerem a chmurą oraz stopniowe ich przeniesienie. Migracja danych odbyła się w trybie ciągłym, bez przerywania pracy użytkowników.
System TMS stanowił kluczowy element infrastruktury klienta. Zawierał setki tysięcy rekordów (zlecenia, kontrahenci, kierowcy, pojazdy) i był wykorzystywany nieprzerwanie w godzinach pracy. Migracja wymagała ścisłej koordynacji z dostawcą oprogramowania oraz przeprowadzenia w ramach okna serwisowego. Harmonogram weekendowy wyglądał tak:
- Piątek wieczór – wykonanie ostatniej kopii bazy danych z lokalnego serwera.
- Sobota – przygotowanie środowiska docelowego, import bazy, instalacja aplikacji, konfiguracja integracji.
- Niedziela – testy funkcjonalne z udziałem kluczowych użytkowników, korekta wykrytych problemów konfiguracyjnych.
- Niedziela wieczór – przełączenie ruchu produkcyjnego na środowisko docelowe, wyłączenie infrastruktury lokalnej.
- Poniedziałek rano – rozpoczęcie pracy w nowym środowisku.
Przełączenie odbyło się bez zakłóceń. Wydajność systemu po migracji uległa poprawie, co zostało odnotowane przez użytkowników.
Kontroler domeny, system kadrowy, archiwum dokumentów oraz narzędzia raportowe przeniesiono w kolejnych tygodniach. System kadrowy wymagał szczególnej uwagi ze względu na wymogi RODO i przepisy rachunkowe – zweryfikowaliśmy z dostawcą oprogramowania zgodność warunków licencyjnych z pracą w chmurze oraz spełnienie wymogów audytowych. Archiwum dokumentów, charakteryzujące się dużym wolumenem przy niskich wymaganiach wydajnościowych, skonfigurowaliśmy w ekonomicznej warstwie przechowywania. Każda migracja była planowana indywidualnie, z testami akceptacyjnymi przed przełączeniem produkcyjnym.
Etap 4: Sieć i dostęp zdalny
Skonfigurowaliśmy VPN site-to-site łączące siedzibę główną oraz biura terenowe bezpośrednio z infrastrukturą Azure. Każda lokalizacja uzyskała dostęp do zasobów chmurowych w trybie analogicznym do dostępu lokalnego – bez konieczności logowania przez Internet, bez utraty wydajności, przy zachowaniu pełnego bezpieczeństwa szyfrowanego tunelu. Wydajność pracy spedytorów w biurach terenowych zrównała się z wydajnością w siedzibie głównej, a w niektórych przypadkach uległa poprawie z uwagi na bliższą lokalizację centrum danych Microsoft względem biura.
Dla aplikacji mobilnych wykorzystywanych przez kierowców skonfigurowaliśmy bezpieczny dostęp do systemu TMS. Komunikacja odbywa się przez szyfrowane połączenia z uwierzytelnianiem dwuskładnikowym (2FA) dla każdego użytkownika. Stabilność połączenia jest niezależna od lokalizacji geograficznej kierowcy w obrębie zasięgu sieci komórkowych – to rozwiązało wcześniejsze problemy z dostępem do systemów podczas tras zagranicznych.
Bezpieczeństwo, backup i plan disaster recovery
W modelu chmurowym bezpieczeństwo opiera się na zasadzie współodpowiedzialności. Microsoft odpowiada za bezpieczeństwo platformy: fizyczne centra danych, infrastrukturę sprzętową, podstawowe mechanizmy izolacji. Klient (we współpracy z partnerem technicznym) odpowiada za bezpieczeństwo konfiguracji: zarządzanie dostępami, polityki haseł, integracje, segmentację sieci – zestaw dobrych praktyk w tym obszarze opisujemy w artykule o cyberbezpieczeństwie w małej firmie.
W ramach projektu wdrożyliśmy kompleksową warstwę bezpieczeństwa konfiguracyjnego:
- szyfrowanie danych w spoczynku (na dyskach Azure) i w transporcie (podczas wymiany między systemami),
- uwierzytelnianie dwuskładnikowe dla wszystkich kont administracyjnych,
- segmentacja sieci z regułami firewall według zasady minimalnego dostępu – domyślnie ruch jest zablokowany, dopuszczany tylko w uzasadnionych przypadkach,
- ciągłe skanowanie podatności z systemem alertowania.
Obecność danych w chmurze nie stanowi automatycznie kopii zapasowej – to częste nieporozumienie, które rozwijamy w artykule o backupie danych firmowych. Microsoft chroni przed awarią własnej infrastruktury, ale nie przed przypadkowym usunięciem danych przez użytkownika, atakami ransomware czy uszkodzeniem bazy danych. Wdrożyliśmy Azure Backup zgodnie z zasadą 3-2-1 dostosowaną do realiów chmurowych: kopie w wielu strefach geograficznych Azure plus dodatkowy backup do osobnego konta przechowywania pełniącego funkcję długoterminowego archiwum. Czas retencji ustawiliśmy na 24 miesiące dla danych krytycznych oraz 6 miesięcy dla danych pomocniczych. Wprowadziliśmy procedurę miesięcznych testów odzyskiwania wybranych plików, bo backup, którego nie poddaje się okresowej weryfikacji, nie zapewnia rzeczywistej ochrony.
Sporządziliśmy szczegółowy plan disaster recovery opisujący scenariusze awaryjne wraz z procedurami reakcji:
- Awaria centrum danych Azure – automatyczne przełączenie na drugie centrum danych w Europie dla systemów krytycznych, ręczne dla pozostałych.
- Awaria pojedynczego systemu – odtworzenie z kopii zapasowej z określonym maksymalnym czasem odzyskiwania (RTO).
- Atak ransomware – odtworzenie z kopii sprzed incydentu, izolacja zainfekowanych zasobów, zgłoszenie do właściwych organów.
- Błąd ludzki (usunięcie lub uszkodzenie danych) – odzyskanie z migawek systemowych, weryfikacja integralności.
Po awarii klimatyzacji w serwerowni baliśmy się, że to się powtórzy w najgorszym momencie i staniemy z transportem. Przeniesienie systemów do Azure zdjęło nam ten problem z głowy. Wszystko ruszyło bez przestoju, a my przestaliśmy martwić się o własny sprzęt.
Efekty wdrożenia
Pierwsze tygodnie po migracji obejmowały standardowe korekty powdrożeniowe: dostosowanie ustawień indywidualnych użytkowników, naprawę pojedynczych integracji niewykrytych w testach, wsparcie pracowników w adaptacji do nowych procedur (np. uwierzytelniania dwuskładnikowego). Okres ten trwał około trzech tygodni, zgodnie z przewidywaniami dla migracji tej skali.
Po zakończeniu okresu adaptacyjnego wyniki ułożyły się następująco:
- Dostępność systemów – Microsoft gwarantuje dostępność platformy Azure na poziomie 99,9% lub wyższym, w zależności od konfiguracji konkretnej usługi. Klimatyzacja, zasilanie awaryjne, awarie dysków i konserwacja sprzętu przestały być obszarem zarządzania klienta.
- Praca rozproszona – wydajność pracy w biurach terenowych zrównała się z siedzibą główną. Kierowcy uzyskali stabilny dostęp do systemów niezależnie od lokalizacji w Europie. Praca zdalna z odstępstwa stała się standardem operacyjnym.
- Skalowalność – dodanie nowego użytkownika zajmuje minuty zamiast godzin. Zwiększenie mocy obliczeniowej w odpowiedzi na nowy kontrakt nie wymaga inwestycji sprzętowych. Decyzje strategiczne firmy nie są już ograniczane wydajnością posiadanej infrastruktury IT.
- Koniec ryzyka jednorazowego wydatku inwestycyjnego co kilka lat – chmura zamieniła CAPEX na przewidywalny OPEX w comiesięcznym budżecie.
Wykorzystane technologie
Migracja danych: Azure File Sync (serwer plików), migracja bazy TMS w oknie weekendowym z koordynacją z dostawcą oprogramowania.
Sieć i dostęp zdalny: VPN site-to-site dla siedziby i biur terenowych, szyfrowany dostęp aplikacji mobilnych kierowców z 2FA.
Bezpieczeństwo: szyfrowanie danych w spoczynku i w transporcie, segmentacja sieci z firewall, polityka minimalnego dostępu, ciągłe skanowanie podatności.
Backup i ciągłość: Azure Backup w modelu 3-2-1, retencja 24 mies. (krytyczne) / 6 mies. (pomocnicze), miesięczne testy odzyskiwania, plan disaster recovery z procedurami per scenariusz.
Integracja z M365: ujednolicenie kont użytkowników z istniejącą subskrypcją Microsoft 365.
Najczęstsze pytania o migrację do Microsoft Azure
Ile trwała migracja do Azure?
Czy firma musiała przerwać pracę?
Ile kosztuje migracja do chmury?
Co z backupem i ciągłością działania?
Microsoft Azure czy własna serwerownia – co tańsze?
RODO i dane w chmurze Microsoft – jak to jest?
Dla jakich firm migracja do Azure ma sens?
Realizujemy projekty migracji do Microsoft Azure dla firm średniej wielkości – od fazy planowania, przez wykonanie, po stałą obsługę powdrożeniową. Zobacz pełną ofertę usług IT, dowiedz się więcej o outsourcingu IT lub naszym podejściu do obsługi MŚP. Sprawdź też ofertę cyberbezpieczeństwa i powiązaną realizację: outsourcing IT w firmie usługowej z Poznania.