Zmiana hostingu albo serwera: gdzie firmy najczęściej tracą dane i klientów
Przenosiny strony albo systemu na nowy serwer wyglądają jak jedna czynność: skopiować dane i zmienić adres. W praktyce trzeba zsynchronizować domenę, pocztę, certyfikat i bazę danych tak, żeby żaden z nich nie przestał działać w trakcie przełączania. Niżej, gdzie w tym procesie najczęściej dochodzi do przestoju i utraty danych, których nie widać, dopóki nie jest już za późno.
Dlaczego zmiana hostingu rzadko jest jedną czynnością
Firma zmienia dostawcę z powodu ceny, powtarzających się awarii albo potrzeby większej wydajności. Migracja dotyka kilku niezależnych systemów naraz: domeny, poczty, bazy danych, certyfikatu HTTPS i samych plików. Błąd w jednym z nich bywa niewidoczny do chwili, aż klient zgłosi, że coś nie działa, a wtedy proces jest już w połowie, nie na starcie, gdzie poprawka kosztowałaby mniej.
DNS: zmiana działa od razu, ale świat dowiaduje się o niej stopniowo
Rekord DNS ma czas życia (TTL), czyli okres, przez jaki serwery na całym świecie zapamiętują starą wartość, zanim zapytają o nową. Przy TTL ustawionym na godzinę zmiana adresu serwera trafia do większości odwiedzających w ciągu godziny lub dwóch. Przy TTL ustawionym na dzień, częstej wartości domyślnej, ten czas sięga doby, a przy zmianie samych serwerów nazw, gdzie TTL bywa ustawiony wysoko przez sam rejestr domeny, bywa jeszcze dłuższy. W tym oknie część odwiedzających trafia na starą wersję strony, część na nową, a mail wysłany w złym momencie może trafić do serwera, który już nie odpowiada.
Poczta, która milczy, zamiast zgłosić błąd
Jeśli domena ma własną pocztę, przeniesienie serwera WWW bez skoordynowania rekordów pocztowych rozdziela na czas propagacji stronę od skrzynki: strona już działa na nowym serwerze, a maile wciąż próbują trafić na stary, który za chwilę zostanie wygaszony. Część takich wiadomości odbija się z komunikatem o błędzie, część trafia w pustkę bez żadnego powiadomienia którejkolwiek ze stron. O tym, co jeszcze psuje dostarczalność firmowej poczty, piszemy w artykule o SPF, DKIM i DMARC: migracja jest jednym z najczęstszych momentów, w którym te ustawienia trzeba przenieść razem z resztą, nie dopisać później, gdy klient już zgłosi niedostarczoną fakturę.
Baza danych nie lubi być kopiowana w trakcie pracy
Kopiowanie bazy danych działającego systemu w czasie, gdy klienci wciąż składają zamówienia, grozi tym, że kopia nie zgadza się z tym, co dzieje się na starym serwerze w międzyczasie: zamówienie złożone minutę po starcie eksportu nie trafia do nowej bazy, a dwa systemy zaczynają się rozjeżdżać. Bezpieczne przejście wymaga albo krótkiego okna, w którym system jest wstrzymany, albo mechanizmu, który dogania różnicę po starcie na nowym serwerze. Wybór między tymi podejściami zależy od tego, ile przestoju firma może sobie pozwolić.
Certyfikat HTTPS trzeba wystawić na nowo, nie przenieść
Certyfikat wydany dla starego serwera jest z nim związany. Na nowym trzeba wygenerować kolejny, zanim ruch zacznie do niego trafiać, inaczej przeglądarka wyświetli ostrzeżenie o niezaufanym połączeniu już w pierwszej minucie po przełączeniu. Kolejność ma znaczenie: certyfikat i konfiguracja nowego serwera gotowe przed zmianą DNS, nie po niej.
Plan powrotu, nie tylko plan przenosin
Migracja bez planu powrotu do starego serwera zakłada, że wszystko pójdzie zgodnie z planem przy pierwszej próbie. Stary serwer wygaszony zbyt szybko po przełączeniu nie daje żadnej możliwości powrotu, jeśli na nowym coś nie działa tak, jak powinno. Kopia danych z dnia migracji, zgodna z zasadami opisanymi w artykule o kopiach zapasowych, i stary serwer utrzymany jeszcze kilka dni po przełączeniu, to różnica między godziną poprawek a dniem odtwarzania wszystkiego od zera.
Sprawdź, zanim zmienisz dostawcę
- Czy ktoś obniżył TTL rekordów DNS kilka dni przed migracją, żeby skrócić okno niezgodności.
- Czy rekordy pocztowe są przeniesione razem z resztą, nie dopisywane po zgłoszeniu problemu przez klienta.
- Czy baza danych ma plan na różnicę powstałą w czasie samego przenoszenia, nie tylko jednorazowy eksport.
- Czy certyfikat HTTPS na nowym serwerze jest gotowy, zanim zacznie do niego trafiać ruch.
- Czy stary serwer zostaje aktywny jeszcze kilka dni po przełączeniu, na wypadek powrotu.
Co przejmujemy
W ramach serwerów i utrzymania przeprowadzamy migrację na nowy serwer albo do innego dostawcy hostingu: obniżamy TTL i koordynujemy zmianę DNS, przenosimy pocztę razem z jej uwierzytelnianiem, synchronizujemy bazę danych i wystawiamy certyfikat HTTPS przed przełączeniem ruchu, a stary serwer trzymamy w gotowości na wypadek powrotu. Zadzwoń pod 697 004 905 albo napisz na kontakt@apkarze.pl. Powiedz, skąd i dokąd chcesz przenieść swoją stronę albo system, a zaplanujemy to bez przestoju.