Jeśli sklep zwalnia przy kampaniach, a każde zamówienie musi być możliwe do odtworzenia, hosting współdzielony przestaje być bezpiecznym fundamentem sprzedaży. Przez kilka lat mógł działać wystarczająco dobrze. Strona się ładowała, płatności przechodziły, integracje wysyłały dane do magazynu. Aż przychodzi dzień promocji, ruch rośnie kilkukrotnie, koszyk zaczyna odpowiadać z opóźnieniem, panel administracyjny zamiera, a zespół nie wie, czy ostatnie zamówienia są już w bazie, w systemie płatności, czy tylko w skrzynce klienta.
Dla właściciela sklepu, dyrektora handlu internetowego i menedżera IT to nie jest problem techniczny w próżni. To ryzyko utraty przychodu, zaufania klientów i kontroli nad danymi sprzedażowymi. WooCommerce i Magento potrafią obsłużyć duży biznes, ale tylko wtedy, gdy środowisko nadąża za aplikacją, bazą danych, plikami mediów, integracjami i kopią zapasową. Migracja do prywatnej chmury w NSIX Data Center nie powinna więc zaczynać się od pytania, ile procesora i pamięci kupić. Powinna zaczynać się od pytania, gdzie dziś sprzedaż może pęknąć.
Pierwszy kosztowny błąd to migracja na ślepo.
Najgorszy scenariusz wygląda znajomo: ktoś przenosi pliki, importuje bazę, zmienia rekordy domeny i czeka, co się stanie. Taki model może zadziałać przy stronie firmowej, ale sklep internetowy jest organizmem transakcyjnym. W jednej chwili zmieniają się stany koszyka, zamówienia, statusy płatności, kody rabatowe, konta klientów, stany magazynowe i komunikaty poczty transakcyjnej. Jeśli nie wiadomo, co dokładnie trzeba zsynchronizować i w jakiej kolejności, krótkie okno techniczne zamienia się w nerwowe gaszenie pożaru.
Audyt przed migracją musi zejść niżej niż ogólne stwierdzenie, że sklep stoi na WooCommerce albo Magento. Trzeba spisać wersję aplikacji, wersję języka i bazy danych, wtyczki lub moduły, rozmiar bazy, strukturę katalogów mediów, mechanizmy cache, zadania cykliczne, integracje płatności, operatorów dostaw, system magazynowy, ERP lub CRM, pocztę transakcyjną oraz miejsca, w których powstają dane sprzedażowe. Dopiero wtedy widać, czy ryzykiem jest wydajność bazy, objętość zdjęć produktów, zbyt wiele zapytań z panelu administracyjnego, czy integracja, która zapisuje status zamówienia z opóźnieniem.
Wydajność trzeba dobrać do profilu sprzedaży, nie do średniego dnia.
Hosting współdzielony często wygląda dobrze w statystykach miesięcznych. Problem pojawia się w pikach: kampania płatna, mailing, kod rabatowy, sezon świąteczny, premiera kolekcji, duży ruch z porównywarki cen. Średnia liczba odwiedzin nie pokazuje, co dzieje się z bazą danych przy równoczesnych koszykach i płatnościach. Dlatego przed wyborem środowiska trzeba zebrać dane o godzinach szczytu, liczbie zamówień, wielkości katalogu, obciążeniu panelu administracyjnego i zapytaniach, które najmocniej obciążają bazę.
W sklepie, w którym baza danych i logika zamówień są ważniejsze niż sama statyczna warstwa strony, punktem odniesienia powinna być konfiguracja dobrana pod bazę i aplikację biznesową, a nie pod prostą witrynę. Takie środowisko potrzebuje dedykowanych zasobów — odpowiedniego procesora, pamięci i szybkiego, wydajnego storage pod bazę danych — dobranych do realnego obciążenia. Dobór nie powinien być zgadywaniem ani wyborem po nazwie pakietu. Sklep, który obsługuje sprzedaż, potrzebuje konfiguracji zestawionej z rzeczywistym ruchem w szczycie, a nie z domyślnym wariantem.
Migracja powinna mieć próbę generalną.
Bezpieczny model przeniesienia sklepu zaczyna się od środowiska testowego. Najpierw odtwarza się aplikację poza produkcją, importuje bazę, przenosi pliki mediów i sprawdza, czy sklep działa tak samo jak przed migracją. Następnie testuje się logowanie, koszyk, płatności, generowanie faktur, maile transakcyjne, integracje dostaw i statusy zamówień. To moment na wykrycie brakujących bibliotek, konfliktów wtyczek, zbyt wolnych zapytań i problemów z uprawnieniami do plików.
Dopiero po takim teście można zaplanować właściwe przełączenie. Zwykle potrzebna jest ostatnia synchronizacja plików i bazy, krótkie zamrożenie zmian w sklepie, kontrola zamówień z ostatnich minut oraz przełączenie rekordów domeny. Celem nie jest magiczna migracja bez żadnego ryzyka. Celem jest krótkie, przewidywalne okno, w którym wiadomo, kto wykonuje każdy ruch, co sprawdza po przełączeniu i kiedy można wrócić do poprzedniego stanu, jeśli testy końcowe pokażą błąd.
Kopie zapasowe zamówień muszą być przetestowane, nie tylko włączone.
W sklepie internetowym kopia zapasowa ma wartość dopiero wtedy, gdy da się z niej odtworzyć właściwe dane w akceptowalnym czasie. Dlatego przed migracją trzeba ustalić RTO i RPO. RTO odpowiada na pytanie, jak szybko sklep musi wrócić do działania po awarii. RPO mówi, ile danych można maksymalnie utracić, czyli na przykład ile minut lub godzin zamówień firma jest w stanie odtworzyć innymi metodami. Dla sklepu prowadzącego aktywną sprzedaż różnica między kopią sprzed doby a kopią sprzed godziny może oznaczać realny spór z klientami i ręczne uzgadnianie płatności.
Prywatna chmura powinna zapewniać regularny backup z możliwością samodzielnego odtworzenia oraz snapshoty, a w razie potrzeby wydłużoną retencję kopii i dodatkowe harmonogramy. Te mechanizmy trzeba jednak przełożyć na proces biznesowy: kiedy wykonywana jest kopia, czy obejmuje dane potrzebne do odtworzenia zamówień, jak wygląda test przywrócenia i kto podejmuje decyzję o odtworzeniu. Sama informacja, że kopie istnieją, nie wystarczy. Przed przełączeniem warto wykonać próbne odtworzenie i sprawdzić, czy sklep po takim procesie faktycznie wraca do obsługi sprzedaży.
Zapora sieciowa nie jest dodatkiem na koniec projektu.
Przy migracji sklepu łatwo skupić się na szybkości ładowania i zapomnieć o dostępie. Tymczasem zapora sieciowa powinna wynikać z mapy ruchu. Kto i skąd ma dostęp do panelu administracyjnego? Jak aplikacja łączy się z bazą danych? Jakie adresy wykorzystują operatorzy płatności, magazyn, system wysyłkowy i poczta transakcyjna? Czy dostęp administracyjny jest ograniczony, czy wystawiony szeroko na świat? Czy środowisko testowe jest widoczne publicznie, mimo że nie powinno?
Wymagania dla zapory warto spisać przed migracją, bo wtedy łatwiej uniknąć dwóch skrajności. Pierwsza to zbyt luźne reguły, które zostawiają otwarte panele i usługi. Druga to zbyt agresywne blokady, które po przełączeniu zatrzymują płatności, wysyłkę wiadomości albo integrację z magazynem. Dobra lista reguł nie jest długa dla samej długości. Jest czytelna, przypisana do konkretnej usługi i możliwa do sprawdzenia po migracji.
Koszt migracji to nie tylko koszt infrastruktury.
Właściciele sklepów często porównują cenę hostingu z ceną nowego środowiska i widzą wyłącznie wyższą pozycję na fakturze. To zbyt płaska kalkulacja. Trzeba doliczyć koszt utraty zamówień, pracy ręcznej po awarii, reklamacji, przestojów w kampanii, nieudanej aktualizacji i braku pewności, czy dane można odtworzyć. Prywatna chmura nie ma być droższym miejscem na te same pliki. Ma dać większą kontrolę nad zasobami, kopią, odtwarzaniem i sposobem przełączenia środowiska.
Dlatego plan migracji powinien kończyć się listą decyzji, a nie tylko terminem przenosin. Jakie dane są krytyczne? Jaki jest akceptowalny RTO i RPO? Kiedy wykonujemy próbne odtworzenie? Jak wygląda zamrożenie zmian? Kto sprawdza płatności po przełączeniu? Jakie reguły zapory są wymagane? Jaki wariant środowiska odpowiada profilowi obciążenia sklepu? Dopiero taka lista pozwala przejść z hostingu współdzielonego bez improwizacji.
Jeżeli Twój sklep na WooCommerce lub Magento zaczyna zwalniać przy kampaniach, nie czekaj na awarię w najgorszym momencie. Poproś o ocenę gotowości migracji sklepu i listę ryzyk dla kopii zapasowych, RTO, RPO oraz kosztów utrzymania. Najlepszy moment na test odtworzenia zamówień jest przed przełączeniem sprzedaży, nie wtedy, gdy klienci już piszą, że nie mogą dokończyć zakupu.