Hosting współdzielony, VPS czy serwer w chmurze: czego naprawdę potrzebuje Państwa strona

Hosting współdzielony, VPS i serwer w chmurze w cenniku wyglądają jak trzy poziomy wydajności, ale różnią się w trzech miejscach: co oddziela Państwa od sąsiadów na tej samej maszynie, gdzie konto się zatrzymuje i kto aktualizuje oprogramowanie.

W środę rano, koło dziesiątej, strona internetowa zwalnia — nie pada, tylko zwalnia: strona otwiera się pięć sekund, panel administracyjny odmawia zapisania wpisu, a po pół godzinie wszystko znowu działa, jakby nic się nie stało. Wsparcie dostawcy hostingu odpowiada po południu, że konto przekroczyło limity swojego planu, i proponuje przejście na kolejny poziom, który kosztuje trzy razy więcej i w cenniku nazywa się „serwer w chmurze”.

W tym momencie większość kupujących nie wie, co dokładnie kupuje, i to nie jest zarzut: hosting współdzielony, VPS i serwer w chmurze są w cenniku ułożone jeden pod drugim jak trzy poziomy wydajności tej samej usługi, choć to trzy różne rozwiązania techniczne, które różnią się w trzech konkretnych miejscach. Każde z tych trzech miejsc mogą Państwo sprawdzić, mając w ręku liczby ze swojej witryny, i żadnego nie da się odczytać z nazwy planu.

Trzy miejsca, w których plany naprawdę się różnią

Pierwsze to izolacja, to znaczy to, co dokładnie oddziela Państwa stronę od stron pozostałych klientów na tej samej fizycznej maszynie. W hostingu współdzielonym jest to konto w systemie operacyjnym razem z kontenerem zasobów osadzonym na poziomie jądra, w przypadku VPS osobna maszyna wirtualna z własnym systemem operacyjnym, a na serwerze w chmurze ta sama maszyna wirtualna, tylko zamówiona i opłacona inaczej. Praktyczna różnica między tymi trzema wariantami leży w tym, w jakim stopniu obciążenie sąsiada może wpłynąć na Państwa witrynę i jak dużo z maszyny wolno Państwu w ogóle zmienić, gdy okaże się, że domyślna konfiguracja Państwu nie pasuje.

Drugie miejsce to ograniczenie, to znaczy gdzie konto się zatrzymuje i jak się to objawia, i właśnie tu powstaje najwięcej nieporozumień, bo ludzie oczekują, że przeciążenie oznacza wolną stronę, choć w części przypadków oznacza stronę, która w ogóle się nie otwiera i zwraca kod błędu, którego kupujący w życiu nie widział ani razu. Trzecie miejsce to odpowiedzialność, to znaczy kto aktualizuje system operacyjny, kto serwer WWW, kto PHP i kto samą witrynę, i właśnie tu kupujący VPS przeliczają się najczęściej, bo dostęp root nie jest prezentem, który dostawca wręcza razem z mocniejszą maszyną — to przejście listy obowiązków z niego na Państwa, i dzieje się cicho, w tej samej minucie, w której wysyłane jest hasło.

Wszystko inne, co w tabeli porównania hostingu zajmuje wiersze, jest albo takie samo we wszystkich planach, albo nie jest tym, co zawodzi: dyski NVMe są dziś praktycznie wszędzie, ale „nielimitowany transfer” to twierdzenie o ilości przesłanych danych, nie o zasobach, i zwykle stoi dokładnie obok tabeli, w której zasoby są policzone do ostatniego megabajta. Natomiast 99,9% to liczba o precyzyjnym znaczeniu prawnym i z listą wyjątków pod spodem, a większość kupujących myśli, że pokrywa coś zupełnie innego, niż naprawdę pokrywa.

Hosting współdzielony: jeden serwer, wiele kont

Hosting współdzielony to konto użytkownika na maszynie, na której mieszkają jeszcze setki takich samych kont, a ten sam produkt bywa sprzedawany pod trzema etykietami, które brzmią jak trzy usługi. Technicznie we wszystkich trzech przypadkach oznacza to tę samą umowę — należy Państwu konto, nie maszyna, witryną zarządzają Państwo przez cPanel albo podobny panel, a wszystko, co jest pod tym panelem, należy do kogoś innego.

To, co oddziela Państwa od sąsiadów, jest konkretnym oprogramowaniem, nie obietnicą w cenniku, i warto znać je z nazwy. Większość dostawców z cPanelem pracuje na CloudLinux, w którym każde konto ma własną kopię systemu plików: dokumentacja CloudLinux o CageFS pisze, że użytkownicy nie mogą ani zobaczyć, ani wykryć innych użytkowników i ich nazw użytkowników na serwerze, nie mogą odczytać konfiguracji serwera WWW i widzą tylko obcięty wykaz procesów. Druga warstwa to LVE — kontener zasobów na poziomie jądra, który każdemu kontu wyznacza limity procesora, pamięci, wejścia-wyjścia i procesów właśnie po to, żeby, jak formułuje sama dokumentacja, żadna pojedyncza witryna nie mogła położyć całego serwera WWW.

Trzecia warstwa to ustawienie PHP open_basedir, i warto wiedzieć, co mówi sam podręcznik PHP, a nie marketing dostawcy: to dodatkowa siatka bezpieczeństwa, która w żadnym razie nie jest wyczerpująca i na której nie można polegać wtedy, gdy bezpieczeństwo jest naprawdę potrzebne. Tamże podręcznik ostrzega, że wyłączenie funkcji przez disable_functions też da się obejść i że we współdzielonym środowisku to nie jest wystarczające zabezpieczenie. Nic z tego nie jest argumentem przeciw hostingowi współdzielonemu; to argument za tym, że izolację daje tu jądro i system plików, nie jedna linijka w pliku konfiguracyjnym, i że dostawca, który na pytanie o izolację odpowiada słowem „bezpiecznie”, na to pytanie nie odpowiedział.

To, czego w hostingu współdzielonym wybrać nie można, jest równie ważne jak to, co można: jądro jest jedno dla wszystkich kont, więc wersji jądra Państwo nie zmienią, listę wersji PHP ustala dostawca i zwykle odstaje od najnowszej o jedną albo dwie, a serwer WWW jest taki, jaki został zainstalowany, więc na pytanie o pakiet, którego tam nie ma, odpowiedzią będzie „nie”, a nie „proszę zainstalować”. Współdzielony serwer to także miejsce, w którym po incydencie dostawca musi sprawdzić sąsiednie konta, bo atakujący, który wszedł na jedno, próbuje tego samego u sąsiadów; co robić, gdy to już się stało, opisaliśmy w artykule o zhakowanej stronie WordPress. Żadne z tych ograniczeń nie jest wadą: to właśnie ta umowa, która sprawia, że ten produkt jest tani, i kupujący, który to rozumie, na tym zyskuje.

Co się dzieje, gdy konto uderza w swój limit

Plan współdzielony ma kilka różnych granic, osiąga się je niezależnie od siebie i objawiają się zupełnie inaczej, więc objaw jest użytecznym narzędziem diagnostycznym. Domyślne limity CloudLinux na jedno konto to 100% jednego rdzenia procesora, 1 GB pamięci fizycznej, 1024 KB/s wejścia-wyjścia, sto procesów i dwadzieścia entry processes, i właśnie ta ostatnia liczba zaskakuje kupujących, bo dwadzieścia brzmi śmiesznie mało jak na witrynę, która w miesiącu przyjmuje dziesięć tysięcy odwiedzin.

Wyjaśnienie jest w tym, że entry process to nie odwiedzający: to proces, który wchodzi na konto z zewnątrz — nowe żądanie HTTP do skryptu PHP, sesja SSH albo zadanie cron — podczas gdy procesy, które powstają już wewnątrz, liczą się w zupełnie innym limicie. Gdy liczba entry processes jest osiągnięta, moduł Apache nie wpuszcza już następnego żądania i oddaje błąd 508 Resource Limit Reached, a CloudLinux w bazie wiedzy opisuje to bez owijania: witryna, która zużywa za dużo zasobów, przestaje działać, ale pozostali klienci na tym samym serwerze pracują dalej normalnie. Właśnie taki jest sens tego mechanizmu — odciąć jedno konto, żeby nie stanęła maszyna.

Pozostałe limity objawiają się inaczej, i z objawu da się odczytać, który dokładnie został osiągnięty, zanim ktoś zacznie zgadywać: procesor i wejście-wyjście nie są odcinane, tylko hamowane, więc strona zwalnia i w końcu się otwiera, podczas gdy limity pamięci i procesów zwykle dają 500 albo 503, to znaczy stronę, która w ogóle się nie otwiera. Na serwerach LiteSpeed entry processes liczy się inaczej niż na Apache, więc tam tej samej liczby nie wolno przekładać na liczbę jednoczesnych odwiedzających, i to jeden z najczęstszych sposobów, w jakie poprawna liczba trafia do niewłaściwego zdania.

Jest jeszcze czwarty koniec, który z obciążeniem nie ma nic wspólnego i dlatego przychodzi znienacka: inode to rekord systemu plików o jednym pliku albo katalogu, więc liczba inode na koncie to po prostu liczba plików i katalogów, łącznie ze skrzynką pocztową, której nikt od lat nie czyścił. Hostnet w cenniku podaje inode wprost — w planie MINI 400 000, PLUS 600 000, PRO 800 000 — i w tej samej tabeli przy MINI i PLUS stoją obok 100% jednego rdzenia i 2048 MB pamięci, a przy PRO 200% i 3072 MB, przy czym wszystkim trzem przypisano 10 MB/s wejścia-wyjścia i 150 jednoczesnych połączeń, podczas gdy miesięczny transfer jest „nielimitowany”. Ten układ jest prawdziwą lekcją o słowie „nielimitowany” w cenniku hostingu: dotyczy ilości przesłanych danych, a wszystkie pozostałe limity stoją tuż obok, policzone do ostatniej liczby.

VPS: własny system operacyjny na współdzielonym sprzęcie

VPS to maszyna wirtualna, w której należy Państwu system operacyjny, dostęp root i możliwość zainstalowania tego, co potrzebne, a na rynku zapisuje się to i skrótem, i pełną nazwą: VPS (Virtual Private Server). To, czego ta nazwa nie mówi, to dwa pytania techniczne, które rozstrzygają, jak dużo z „własnego serwera” naprawdę jest Państwa.

Pierwsze pytanie brzmi, czy wirtualizacja jest na poziomie sprzętu, czy systemu operacyjnego. KVM to moduł jądra Linuksa, który korzysta z rozszerzeń wirtualizacji procesora i daje każdemu gościowi własny zwirtualizowany sprzęt — kartę sieciową, dysk, adapter wideo — i, co najważniejsze, własne jądro, więc da się na nim uruchomić także niezmieniony Windows. LXC i pokrewne kontenery to inny mechanizm: korzystają z przestrzeni nazw Linuksa, cgroups i ograniczania uprawnień, żeby zbudować środowisko możliwie bliskie osobnej instalacji Linuksa, ale bez osobnego jądra. Skutki są proste i praktyczne — w kontenerze wersja jądra, moduły jądra i podatności jądra zostają wspólne z maszyną hosta, więc część tego, co Państwo myśleli, że kupują, w rzeczywistości została u sąsiadów.

Drugie pytanie dotyczy procesora, bo słowa „własny serwer” nie oznaczają własnego procesora. Serwery w chmurze Hetznera mają dwie osobne linie produktów: w planach ze współdzielonymi zasobami moc obliczeniowa jest dzielona między wszystkie instancje na tym samym fizycznym serwerze, z wydajnością bazową i możliwością chwilowego jej przekroczenia, podczas gdy w planach z zasobami dedykowanymi jeden vCPU to jeden wątek fizycznego rdzenia i wyłącznie Państwa. DigitalOcean formułuje to jeszcze jaśniej: w planie współdzielonym wątek może być dzielony z innymi, i jeśli sąsiedzi mają duże obciążenie, instancja dostaje części wątku, nie pełny dostęp, więc w praktyce pełny dostęp jest możliwy, ale nie jest gwarantowany.

Ilu sąsiadów jest na jednej maszynie, nie publikuje żaden z dużych dostawców, a proporcja, którą Państwo znajdą na blogach, nie jest niczyim opublikowanym pomiarem, więc nie warto jej ani cytować, ani jej wierzyć. Jedyna udokumentowana wielkość, na którą można się powołać, to to, czy plan obiecuje zasoby dzielone, czy osobne, i ta różnica zwykle jest zapisana całkiem otwarcie — dwoma różnymi nazwami produktów, dwiema różnymi specyfikacjami i różnicą ceny, która jest wielokrotna.

Serwer w chmurze to ten sam VPS, kupiony inaczej

Serwer w chmurze jest technicznie maszyną wirtualną na hiperwizorze, to znaczy dokładnie tym samym, czym VPS, i dokumentacja Hetznera zaczyna od tego samego zdania — serwery w chmurze to maszyny wirtualne, które działają na serwerach fizycznych. Jeśli z dwóch ofert oczekują Państwo dwóch różnych sprzętów, to oczekiwanie nie ma podstaw.

Różnica nie leży w sprzęcie, tylko w sposobie kupowania, i najprecyzyjniej opisuje to definicja amerykańskiego Narodowego Instytutu Standaryzacji i Technologii NIST, którą branża wciąż cytuje: chmura ma pięć cech — samoobsługę na żądanie, dostęp przez sieć, pulę zasobów z wieloma najemcami, szybką elastyczność i mierzone zużycie. W praktyce oznacza to API, którym maszynę da się utworzyć i usunąć programowo, taryfę godzinową z miesięcznym limitem i dodatkowe elementy, które można podłączyć osobno: snapshoty, osobną pamięć blokową, przenośny adres IP i równoważnik obciążenia.

Każdy z tych elementów ma granice, które warto znać przed zakupem, a nie miesiąc po nim. Zmiana planu u Hetznera nie może zmniejszyć rozmiaru dysku nawet wtedy, gdy wykorzystywana jest tylko część; po powiększeniu dysku partycję trzeba rozszerzyć samemu w trybie rescue, a sama zmiana planu jest wymieniona jako wyjątek od gwarancji dostępności. Snapshot z kolei nie jest kopią zapasową, choć obu słów rynek używa jak synonimów: w snapshotach Hetznera nie mieszczą się podłączone wolumeny, a spójność nie jest gwarantowana, gdy serwer działa, więc to dobra rzecz przed aktualizacją i zła rzecz jako jedyna kopia danych. Przenośny adres IPv4 jest płatny osobno, tak samo jak główny adres IPv4 przy samej instancji.

Pięciostronicowa witryna firmowa zwykle nie korzysta z żadnego z tych elementów, i to najuczciwsze zdanie w tej części: jeśli witryna nigdy nie zmienia mocy, nigdy nie przełącza się na drugą maszynę i nigdy nie jest podłączana przez API, to serwer w chmurze i VPS tego samego rozmiaru to jedna i ta sama maszyna z dwoma różnymi rachunkami. To nie jest argument przeciw chmurze, bo tam, gdzie elastyczność jest używana, kosztuje mniej niż stale trzymana rezerwa. To argument za tym, że wybór jest między możliwościami, z których Państwo naprawdę skorzystają, a nie między słowami, które brzmią nowocześnie.

Kto aktualizuje co

Największa praktyczna różnica między trzema planami to nie szybkość, tylko podział obowiązków, i najjaśniej sformułowali to sami dostawcy chmury. Model wspólnej odpowiedzialności AWS dzieli wszystko na dwie części: bezpieczeństwo chmury jest odpowiedzialnością AWS — sprzęt, oprogramowanie, sieć i pomieszczenia, w których usługi działają — a bezpieczeństwo w chmurze jest odpowiedzialnością klienta. W sprawie łatek jest to nawet zapisane osobno i słowo w słowo: AWS odpowiada za łatki i usterki infrastruktury, a klient odpowiada za łatki systemu operacyjnego swojego gościa i swoich aplikacji.

W hostingu współdzielonym ta warstwa należy do dostawcy, i to największa wartość tego produktu, o której rzadko kto myśli: jądro, serwer WWW i PHP aktualizują oni, a Państwo nie wiedzą o tym nic, dopóki coś się nie zepsuje. Na niezarządzanym VPS albo serwerze w chmurze wszystko to przeszło na Państwa razem z hasłem root, a Hetzner w swoich warunkach mówi to także z drugiej strony: oprogramowanie, konfiguracja i ustawienia systemu, które wprowadza klient, nie są uważane za zakłócenie dostępności, więc dostawca za nie nie odpowiada i nie wchodzą w żadne odszkodowanie.

Sama witryna zostaje Państwa odpowiedzialnością we wszystkich trzech przypadkach, i to ten punkt, w którym oferty trzeba czytać uważnie, bo słowo „Managed Hosting” (hosting zarządzany) w branży zwykle oznacza system operacyjny i oprogramowanie serwera, nie rdzeń WordPressa, wtyczki i motyw. Także w utrzymaniu naszego własnego wynajmu infrastruktury mieszczą się aktualizacje systemu operacyjnego i oprogramowania serwera, konfiguracja bezpieczeństwa, kopie zapasowe z testowanym odtwarzaniem, monitoring i reagowanie według SLA — i nie jest tam napisane, że aktualizujemy Państwa wtyczki, bo to inny wiersz w cenniku i inna umowa, i mówimy to wprost, żeby nikt nie odkrywał tej granicy w dniu incydentu.

Praktyczny test przed zamówieniem to jedno pytanie, zadane wprost i w trzech częściach: kto aktualizuje system operacyjny, kto serwer WWW i PHP, a kto kod witryny. Jeśli odpowiedź na któreś z trzech brzmi „Państwo sami”, to jest to praca, do której potrzeba albo człowieka z czasem, albo umowy z kimś innym, i żadne z tych dwóch nie jest darmowe. Nieodpowiedziane to pytanie nie znika — wraca po osiemnastu miesiącach jako system, w który nikt nie włożył ani jednej łatki, i wtedy to już nie jest pytanie o wybór planu.

Co znaczy 99,9% i czego ten wskaźnik nie obejmuje

Procent dostępności w cenniku wygląda jak obietnica, a w rzeczywistości jest formułą z listą wyjątków. Umowa o poziomie usług serwerów w chmurze Hetznera obiecuje 99,9% w miesiącu na jedną instancję, a sam Hetzner w wyjaśnieniu wylicza, co ta liczba znaczy w praktyce: w trzydziestodniowym miesiącu 43 minuty przestoju wciąż mieszczą się w granicach umowy, to znaczy nie są naruszeniem i nie przysługuje za nie żadne odszkodowanie.

Samo odszkodowanie jest równie konkretne i dużo mniejsze, niż ludzie oczekują: liczy się je z minut powyżej progu, przeliczonych na godziny i pomnożonych przez stawkę godzinową instancji, i wypłaca jako kredyt na dalsze zużycie, nie jako pieniądze. We własnym przykładzie Hetznera 185 minut przestoju daje 142 minuty powyżej progu, czyli 2,37 godziny, i kredyt w wysokości 0,87 €, co jest mniej, niż kosztuje godzina pracy przy tym wyliczeniu. Nieodzyskany obrót, utracone zamówienia i utracone pozycje w wynikach wyszukiwania nie mieszczą się tam nigdzie, i żadna umowa hostingowa, którą czytaliśmy, ich nie pokrywa.

Lista wyjątków jest równie ważna jak liczba, bo właśnie ona rozstrzyga, jak często ta liczba w ogóle jest stosowana: poza umową zostają wcześniej zapowiedziana konserwacja, oprogramowanie i konfiguracja samego klienta, zmiana planu na żądanie klienta, migracje na żywo ze względu na stabilność maszyny hosta oraz sieć poza siecią bazową dostawcy. Wszystko to jest zapisane uczciwie i otwarcie, i z tego wynika prosty wniosek: procent dotyczy maszyny, nie Państwa witryny, więc witryna, która padła po nieudanej aktualizacji, jest poza tą umową całkowicie.

Ponadto 99,9% nie jest stałą branży, choć często używa się jej tak, jakby była. Umowa Amazon EC2 na jedną instancję obiecuje 99,5%, a 99,99% tylko wtedy, gdy instancje są rozmieszczone w co najmniej dwóch strefach dostępności, to znaczy to dwie różne umowy z dwiema różnymi liczbami, a zdanie „w branży jest 99,9%” spłaszcza je obie do jednej. W hostingu współdzielonym takiego dokumentu zwykle nie ma w ogóle — jest tylko liczba na stronie bez definicji, bez metody pomiaru i bez skutków, i to twierdzenie, nie zobowiązanie.

Jak zmierzyć swoją stronę przed wyborem

Liczba, która rozstrzyga, to nie liczba odwiedzin w miesiącu, choć właśnie ją kupujący zna na pamięć i właśnie o nią sprzedawca pyta jako pierwszą. Rozstrzyga liczba jednoczesnych żądań PHP w chwili, gdy obciążenie jest największe, i to zupełnie inna wielkość, która z miesięczną oglądalnością koreluje słabo.

Dwie witryny o tej samej oglądalności mogą znaleźć się po różnych stronach tego samego limitu, a różnica leży w tym, jak długo każda strona trzyma proces. Statyczną, trzymaną w cache witrynę firmową w większości obsługuje serwer WWW bez PHP, więc entry processes prawie nie zużywa i dziesięć tysięcy odwiedzin miesięcznie nic dla niej nie znaczy. Sklep internetowy, w którym każdy koszyk, każde logowanie i każdy powrót z bramki płatności trzyma proces PHP dwie sekundy, ten sam limit może osiągnąć już przy dwudziestu jednoczesnych kupujących, i właśnie dlatego w pierwszej godzinie kampanii padają właśnie te sklepy, które kampanię opłaciły.

Razem z tą liczbą warto odczytać jeszcze trzy, i wszystkie trzy są dostępne bez pomocy programisty. Pierwsza to rozmiar bazy danych i najwolniejsze zapytanie w niej, bo właśnie to zwykle jest prawdziwą przyczyną spowolnienia, nie moc maszyny. Druga to liczba plików na koncie, bo witryny z dużymi bibliotekami mediów i ze starą skrzynką pocztową osiągają limit inode znienacka i bez ostrzeżenia. Trzecia to to, co witryna robi poza przeglądarką — zadania cron, wysyłka poczty, integracje z systemem księgowym — bo te procesy też wchodzą na konto z zewnątrz i liczą się w tym samym limicie, który właśnie zmierzyli Państwo na kupujących.

Wszystkie cztery liczby da się odczytać w jedno popołudnie ze statystyk panelu hostingowego i dzienników serwera, i to jedyne miejsce, w którym jest prawdziwe obciążenie Państwa witryny, a nie przeczucie o nim. Nazwa planu tych liczb nie zna, sprzedawca, który ich nie widział, też nie, a rozmowa, która od nich się zaczyna, zwykle kończy się tańszą odpowiedzią niż rozmowa, która zaczyna się od listy planów.

Kiedy przeniesienie pomaga, a kiedy niczego nie rozwiązuje

Przejście na większy plan jest właściwą odpowiedzią znacznie rzadziej, niż się je proponuje, a pierwszy przypadek, gdy nie pomaga, jest też najczęstszy. Jeśli witryna jest wolna dlatego, że jedno zapytanie czyta całą tabelę produktów przy każdym otwarciu strony, to mocniejsza maszyna wykona to szybciej, problem zostanie, i Państwo kupią czas, nie rozwiązanie. To samo dotyczy czterdziestu wtyczek, nieprzetworzonych obrazów w pełnym rozmiarze i motywu, który przy każdym żądaniu buduje menu od zera.

Przeniesienie jest właściwą odpowiedzią wtedy, gdy limit został osiągnięty przy poprawnym kodzie: jeśli witryna jest w cache, zapytania są w porządku, a konto i tak uderza w liczbę entry processes, to jest to limit planu, nie defekt w kodzie, i nie ma już czego optymalizować. Tak samo przeniesienie jest jedyną odpowiedzią wtedy, gdy potrzeba czegoś, czego na współdzielonym koncie zainstalować się nie da — innej wersji PHP, workera kolejki, Redis, własnego crona z krokiem co minutę — albo gdy wymóg branżowy, przetargowy albo klienta określa, w którym kraju dane fizycznie leżą.

Jest też trzeci przypadek, o którym sprzedawcy mówią rzadko, bo zmniejsza rachunek: czasem właściwym ruchem jest w dół. Witryna, która trzy lata temu została przeniesiona na VPS z powodu jednej kampanii reklamowej i od tamtej pory przyjmuje dwieście odwiedzin dziennie, płaci za maszynę, której nie wykorzystuje, i płaci za to dwa razy — pieniędzmi na rachunku i czasem człowieka, bo system operacyjny VPS ktoś musi aktualizować także wtedy, gdy nikt tam nie wchodzi.

Przed jakimkolwiek przeniesieniem warto jeszcze rozstrzygnąć jedno pytanie, które z mocą nie ma nic wspólnego: na czyje nazwisko jest zarejestrowana domena i na czyje nazwisko jest konto hostingowe. Pisaliśmy o tym osobno w artykule o błędach przy zamawianiu strony internetowej, i to jedno z tych pytań, których w dniu migracji nie da się już szybko naprawić, bo odpowiedź zależy od człowieka, z którym Państwo może już nie rozmawiają.

Co Państwo kupują, gdy plan nazywa się Managed Hosting

Różnica ceny między maszyną niezarządzaną a zarządzaną jest duża, i to nie marża na ten sam towar, więc obie liczby trzeba uczciwie położyć obok siebie. W cenniku Hetznera, który wszedł w życie 15 czerwca 2026 roku, serwer w chmurze CX23 z dwoma vCPU, czterema gigabajtami pamięci i dyskiem 40 GB kosztuje 5,49 € miesięcznie bez VAT, a główny adres IPv4 dochodzi do tego za 0,50 € miesięcznie. Nasz zarządzany hosting zaczyna się od 45 € / mies., i różnica między tymi dwiema liczbami jest dokładnie tym, o czym jest ta część.

Różnica to praca, i da się ją wyliczyć po jednej: aktualizacje systemu operacyjnego i oprogramowania serwera, konfiguracja bezpieczeństwa, monitoring Zabbix przez całą dobę i reagowanie według SLA, kopie zapasowe codziennie z przechowywaniem 30 dni i regularnie testowanym odtwarzaniem, a przy szczególnie krytycznej infrastrukturze — do 365 dni i w dwóch różnych krajach Unii Europejskiej. Przygotowanie środowiska i przeniesienie zajmuje 3–10 dni, migrację prowadzimy równolegle i DNS przełączamy w zaplanowanym oknie, a potem mają Państwo jeden odpowiedzialny kontakt, nie zgłoszenie do wsparcia w innej strefie czasowej.

Uczciwie trzeba powiedzieć także drugą stronę, bo bez niej ta część byłaby cennikiem z artykułem dookoła. Jeśli Państwa witryna jest statyczna, odwiedziny niewielkie i nikt nigdy nie prosi o wersję PHP, której dostawca nie ma, to hosting współdzielony za kilka euro miesięcznie jest właściwą odpowiedzią, a zarządzane środowisko byłoby opłatą za spokój, który i tak już Państwo mają. Mówimy to także tym, którzy dzwonią z tym pytaniem, bo sprzedać środowisko, które nie jest używane, to transakcja krótkoterminowa — po roku wraca jako pytanie, za co właściwie płacono, i nie ma na nie dobrej odpowiedzi.

Jeśli nie są Państwo pewni, po której stronie tej granicy jest Państwa witryna, te cztery liczby da się odczytać razem: proszę do nas napisać, a powiemy, co pokazuje statystyka Państwa obecnego konta i który limit jest najbliższy — także wtedy, gdy odpowiedź brzmi, że przenosić się nie ma żadnej potrzeby i pieniądze lepiej włożyć w szybkość witryny.