Najdroższy hosting to nie ten, który ma najwyższy abonament, tylko ten, który psuje się w złym momencie. Przestój sklepu w środku kampanii, przejęte konto panelu i podmieniona strona, „backupy”, których nie da się odtworzyć, albo zablokowana poczta – to scenariusze, które w firmie szybko zamieniają się w utracone zamówienia, telefony od klientów i nerwowe szukanie winnego. Problem polega na tym, że wiele ofert hostingowych wygląda podobnie: „szybkie SSD”, „bezpieczeństwo”, „wsparcie 24/7”. Różnice wychodzą dopiero wtedy, gdy coś się sypie.
Da się jednak ograniczyć ryzyko już na etapie wyboru. Kluczem jest patrzenie na hosting i usługi serwerowe jak na łańcuch mechanizmów: co ma zadziałać podczas awarii, kto ma dostęp, jak są robione kopie, jak wygląda eskalacja, ile realnie trwa przywrócenie usług i czy dostawca potrafi to udowodnić procedurami, a nie sloganami.
SLA hosting, RPO RTO backup, VPS czy chmura dla firmy, hosting managed, ochrona DDoS WAF, test odtworzenia kopii, bezpieczeństwo konta MFA 2FA, migracja DNS TTL, status page i post-mortem, overselling hostingu, SPF DKIM DMARC poczta
Gdy hosting „siada” w najgorszym momencie: typowe scenariusze strat w firmie
Przestój strony lub sklepu: utracone leady i spadek zaufania
Najbardziej „bolesny” przestój to nie awaria w nocy, tylko w godzinach, kiedy klient ma kupić, wysłać formularz albo opłacić fakturę. Efekt biznesowy pojawia się natychmiast: porzucone koszyki, niedziałające płatności, telefony na infolinię, a czasem też konsekwencje SEO (częste błędy 5xx i długie czasy odpowiedzi potrafią osłabić widoczność).
Żeby taki scenariusz nie kończył się wielogodzinnym blackoutem, dostawca powinien mieć nie tylko „dobry serwer”, ale monitoring i procedury: automatyczne wykrycie awarii, dyżur (on-call) i możliwość eskalacji, a do tego komunikację (status page). W praktyce liczy się, czy w SLA i warunkach wsparcia jest rozróżnienie na czas reakcji i czas przywrócenia, a nie tylko ogólne „pomagamy szybko”.
Co ma zadziałać po stronie dostawcy: monitoring usług (HTTP, DB, DNS), redundancja kluczowych elementów (np. macierze, zasilanie), szybkie przełączanie lub odtworzenie, klarowne priorytety incydentów i ścieżka eskalacji poza pierwszą linię supportu.
Przejęte konto panelu/FTP/SSH: podmiana treści, malware i blokady
Włamania do paneli hostingowych często zaczynają się banalnie: wyciek hasła, brak MFA/2FA, konto współdzielone „na firmę” (jedno hasło dla kilku osób), logowanie z niezaufanego urządzenia. Potem jest już gorzej: podmiana plików, wstrzyknięty skrypt, przekierowania na strony phishingowe, wysyłka spamu z serwera i w konsekwencji blacklisty, blokady poczty lub ostrzeżenia w przeglądarce.
Dostawca nie zabezpieczy aplikacji w 100% (np. źle napisanej wtyczki), ale może mocno ograniczyć ryzyko przejęcia konta i skutki incydentu. MFA/2FA w panelu, role i uprawnienia (RBAC), logi zmian, alerty o podejrzanych logowaniach, ograniczenia IP, wsparcie dla kluczy SSH oraz możliwość szybkiego „zamrożenia” dostępu – to elementy, które realnie robią różnicę.
Uwaga: jeśli dostawca oferuje „zabezpieczenia antywirusowe”, ale panel nie ma MFA i nie ma historii logowań ani zmian, to jest to bezpieczeństwo bardziej marketingowe niż operacyjne.
„Backup był”, ale nie da się go odtworzyć: najgorszy rodzaj niespodzianki
Jedna z najbardziej kosztownych awarii to taka, w której backup istnieje tylko w folderze „backup” albo jako snapshot na tej samej macierzy. W teorii kopie są, w praktyce są niekompletne (brak bazy danych), nadpisane, zaszyfrowane razem z serwerem przez ransomware albo niedostępne, bo awaria dotyczy całej platformy.
Tu wchodzą pojęcia, które powinny padać w rozmowie z dostawcą: RPO (Recovery Point Objective – ile danych firma może stracić) i RTO (Recovery Time Objective – jak szybko usługa ma wrócić). Jeśli dostawca nie potrafi powiedzieć, jak często robi kopie, ile trzyma (retencja), gdzie są składowane (off-site) i czy robi testy odtworzenia, to ryzyko przerzuca na klienta.
Co powinno działać: kopie w innej lokalizacji (off-site), rozdzielenie snapshotów od backupów, możliwość odtworzenia konkretnego punktu w czasie, oraz procedura restore opisana tak, żeby dało się ją przećwiczyć na środowisku testowym.
Poczta firmowa zablokowana albo w spamie: paraliż komunikacji i sprzedaży
Wiele firm traktuje pocztę jako „dodatek do hostingu”, a potem okazuje się, że to najbardziej krytyczna usługa: oferty handlowe nie dochodzą, faktury wracają, klient pisze, a firma nie odpowiada, bo nikt nie widzi wiadomości. Do tego dochodzą blokady za spam (czasem spowodowane „sąsiadem” na współdzielonym IP) oraz ryzyko podszywania się pod domenę.
Minimalny zestaw technicznych zabezpieczeń to SPF (deklaracja, które serwery mogą wysyłać pocztę dla domeny), DKIM (podpis kryptograficzny wiadomości) i DMARC (polityka weryfikacji i raporty). Dostawca powinien ułatwiać konfigurację tych rekordów i jasno komunikować, jak wygląda ochrona antyspamowa/antyphishingowa oraz co się dzieje, gdy konto wysyła podejrzany ruch (czy jest miękka kwarantanna, czy natychmiastowa blokada).
Tip: rozważ separację: WWW na jednym hostingu, a poczta w usłudze typowo pocztowej (lub u innego dostawcy). To zmniejsza ryzyko, że awaria serwera WWW „położy” też komunikację.
Błędna migracja DNS i certyfikatów TLS: część klientów widzi starą wersję lub błędy HTTPS
Migracje potrafią wyglądać idealnie w testach, a potem w realnym świecie część klientów wchodzi na starą wersję strony albo dostaje ostrzeżenie o certyfikacie. Zwykle winny jest DNS: zbyt wysokie TTL (czas życia rekordu w cache), przełączenie bez okresu równoległego działania, pomyłka w rekordach (A/AAAA/CNAME), albo brak planu rollbacku.
Drugi klasyk to TLS (HTTPS): certyfikat „wystawiony”, ale nie obejmuje wszystkich subdomen, nie odnowił się automatycznie albo serwer nie podał pełnego łańcucha certyfikatów. Dostawca powinien oferować automatyczne odnowienia (np. Let’s Encrypt) oraz narzędzia do monitorowania wygasania certyfikatów.
Co powinno zadziałać: plan przełączenia DNS z obniżeniem TTL przed migracją, środowisko tymczasowe/staging do testów, checklisty rekordów (MX, SPF/DKIM/DMARC, A/AAAA, CNAME), plus mechanizm szybkiego cofnięcia zmian, jeśli pojawi się błąd.
Skąd biorą się awarie i „znikające wsparcie” — przyczyny, które da się wykryć przed zakupem
Infrastruktura vs procesy: co częściej zawodzi w praktyce
Intuicyjnie łatwo obwiniać sprzęt: „padł dysk”, „spalił się serwer”. W dobrze prowadzonych usługach to rzadko jest główny problem, bo sprzęt i centra danych mają redundancję. Częściej zawodzi proces: brak dyżuru, brak procedur odtwarzania, chaotyczne aktualizacje, brak komunikacji, a czasem brak uprawnień po stronie supportu (pierwsza linia może tylko odpisywać szablonami).
Dlatego pytania do dostawcy powinny dotyczyć nie tylko parametrów serwera, ale też „operacji”: jak wygląda obsługa incydentów, czy jest status page, jak wygląda post-mortem (opis przyczyn po awarii), czy klienci dostają komunikaty o oknach serwisowych i czy da się zgłosić incydent telefonicznie w krytycznych sytuacjach.
Overselling i „fair use”: skąd biorą się losowe spadki wydajności
Na hostingu współdzielonym i czasem na tanich VPS-ach problemem bywa overselling: sprzedanie większej ilości zasobów niż realnie dostępne, licząc, że nie wszyscy wykorzystają je jednocześnie. Objawy są specyficzne: strona raz działa szybko, raz wolno, w panelu „wszystko OK”, a support sugeruje optymalizację strony, mimo że problem jest w I/O (dysku) lub CPU współdzielonym z innymi.
W ofertach szukaj konkretów: czy są limity CPU/RAM/IOPS, jak dostawca informuje o throttlingu, czy jest monitoring zużycia zasobów dla klienta i czy w razie „noisy neighbor” (hałaśliwego sąsiada) jest automatyczna migracja konta na inny węzeł lub izolacja kontenerowa.
Czerwona flaga: „nielimitowane” zasoby bez jasnej definicji. W praktyce limit istnieje, tylko jest ukryty w regulaminie jako „uczciwe użycie”.
Brak izolacji tenantów: gdy cudzy problem staje się twoim
Współdzielony hosting jest wygodny, ale ryzyko rośnie, gdy izolacja między klientami jest słaba. W skrajnym przypadku podatność w jednym koncie może pozwolić na dostęp do danych innego klienta lub na zjedzenie zasobów całego serwera. Nawet bez włamania – wystarczy, że sąsiad uruchomi ciężkie procesy i twoja strona zaczyna „zamykać” połączenia.
Weryfikuj, czy dostawca stosuje mechanizmy izolacji (np. kontenery, chroot, separacja użytkowników, limity per proces) i jak rozwiązuje problemy „noisy neighbor”. Jeśli odpowiedź brzmi „u nas się to nie zdarza”, to nie jest odpowiedź techniczna.
Aktualizacje i podatności: kto patchuje system i środowisko uruchomieniowe
W usługach serwerowych kluczowe pytanie brzmi: kto odpowiada za patching (łatki bezpieczeństwa) systemu, panelu administracyjnego, środowiska (PHP/Node/Python), baz danych i komponentów typu Redis czy Nginx. Na hostingu współdzielonym zwykle robi to dostawca, na VPS-ie – często klient (chyba że to hosting managed).
Ryzyko pojawia się wtedy, gdy zakres odpowiedzialności jest niejasny. Firma zakłada, że „dostawca dba o bezpieczeństwo”, a dostawca zakłada, że klient jest administratorem. Efekt: serwer stoi miesiącami bez aktualizacji, bo nikt nie chce „dotknąć” produkcji.
Poproś o informację, jak wyglądają okna serwisowe, czy łatki krytyczne są wdrażane poza standardowym harmonogramem, oraz czy dostawca ma politykę informowania o incydentach bezpieczeństwa.
Kopie zapasowe „na papierze”: snapshot to nie backup
Snapshot (migawka) bywa szybkim sposobem na cofnięcie zmian, ale często jest zależny od tej samej infrastruktury. Jeśli padnie macierz albo cały region u dostawcy – snapshot znika razem z nim. Backup ma sens dopiero wtedy, gdy jest przechowywany niezależnie i da się go odtworzyć bez dostępu do pierwotnej maszyny.
Weryfikuj: częstotliwość (co ile?), retencję (jak długo?), zakres (pliki + bazy + konfiguracje), lokalizację (off-site), szyfrowanie kopii oraz to, czy klient ma samodzielny dostęp do przywracania (i czy restore jest wliczony w cenę, czy „na zlecenie”).
Słabe procedury incydentowe: gdy support „odbija piłeczkę”
„Proszę wyczyścić cache”, „to na pewno wina strony”, „u nas działa” – te komunikaty w krytycznym incydencie są znakiem, że support jest oderwany od infrastruktury. Dobrze działająca obsługa incydentów ma: priorytety, definicje awarii, dyżur, możliwość eskalacji, oraz jasne komunikaty o postępie prac.
Jeśli dostawca nie prowadzi status page albo nie publikuje informacji o awariach, firma nie ma jak komunikować się z klientami („czy to u nas, czy u nich?”). A brak post-mortem utrudnia ocenę, czy problem był jednorazowy, czy systemowy.
Jak dobrać model usługi do ryzyka i kompetencji w firmie (współdzielony / VPS / dedyk / chmura / managed)
Hosting współdzielony: minimalny próg wejścia, maksymalna zależność
Współdzielony hosting kusi prostotą: panel, e-mail, baza, „klik i działa”. Dla strony wizytówki albo małego serwisu bywa wystarczający, ale w firmie problemem staje się przewidywalność. Nie kontrolujesz wersji systemu, polityk bezpieczeństwa, często masz ograniczone logi i brak wpływu na parametry wydajnościowe.
Najczęstsze pułapki to „nielimitowane” zasoby, współdzielone IP (ważne dla reputacji poczty), brak przejrzystości w kwestii izolacji oraz ograniczenia w backupie (np. tylko pliki, brak spójnych kopii baz). Jeśli biznes zależy od stałej dostępności, współdzielony hosting trzeba traktować jak rozwiązanie „best effort”, chyba że dostawca oferuje naprawdę twarde warunki wsparcia i odtwarzania.
VPS: więcej kontroli, ale rośnie odpowiedzialność operacyjna
VPS daje izolację zasobów i większą swobodę: własna konfiguracja, możliwość wdrożenia dodatkowych zabezpieczeń, osobne IP, własne logi. To dobry krok, gdy firma rośnie, a aplikacja potrzebuje stabilności. Jednocześnie VPS przerzuca na firmę sporą część odpowiedzialności: aktualizacje, hardening (utwardzenie), monitoring, kopie, reagowanie na incydenty.
Jeśli w firmie nie ma osoby, która „lubi grzebać w serwerze”, VPS potrafi stać się tykającą bombą. Najczęstszy scenariusz: wszystko działa miesiącami, po czym pojawia się krytyczna podatność w OpenSSL/SSH lub w panelu, a nikt nie chce robić aktualizacji „bo może się wywali”. To nie złośliwość, tylko brak procesu: okien serwisowych, środowiska testowego i planu cofki (rollback) dla zmian systemowych.
Uwaga: różnica między VPS-em „unmanaged” i „managed” bywa schowana w regulaminie. W managed dostawca zwykle bierze na siebie patching OS, podstawowy hardening, monitoring i reakcję na incydenty. W unmanaged dostajesz maszynę i dostęp root, a reszta to twoja odpowiedzialność. Dopytaj też o granice wsparcia: czy pomogą przy problemach aplikacji (np. błędach 502/504), czy tylko „serwer działa, ping odpowiada”.
Tip: już na etapie wyboru ustal minimalny pakiet operacyjny, który musi istnieć, żeby VPS był bezpieczny i przewidywalny. Przykładowo: automatyczne aktualizacje bezpieczeństwa (tam, gdzie to ma sens), firewall z whitelistą usług, logowanie tylko kluczem SSH, monitoring portów i miejsca na dysku, alerty o wygasaniu certyfikatów, oraz backup off-site z testem odtwarzania. Bez tego VPS daje złudzenie kontroli, a w praktyce produkuje incydenty „z zaskoczenia”.
Serwer dedykowany: przewidywalność i wydajność, ale ryzyko „jednego pudła”
Dedyk daje stałe zasoby i brak sąsiadów. To świetne, gdy aplikacja jest wrażliwa na I/O albo potrzebuje specyficznej konfiguracji (np. własne jądro, nietypowe moduły). Problem zaczyna się, gdy dedyk jest jedynym punktem prawdy: jedna awaria sprzętu, jeden błąd RAID, jedna nieudana aktualizacja i firma jest offline, dopóki ktoś tego nie poskłada.
Wymagaj jasnej strategii HA (high availability) lub chociaż planu odtwarzania: zapasowa maszyna, możliwość szybkiej reinstalacji, automatyzacja konfiguracji (Ansible/Terraform) i kopie poza serwerem. Bez automatyzacji dedyk jest często „ręcznie rzeźbiony” — a wtedy migracja lub odbudowa po awarii trwa nieprzyjemnie długo.
Chmura (IaaS/PaaS): elastyczność, która kosztuje, jeśli nie pilnujesz porządku
Chmura dobrze znosi skoki ruchu i pozwala budować architekturę odporną na awarie strefy/regionu, ale nie rozwiązuje automatycznie problemów procesowych. Typowa wpadka: zasoby powstają „na szybko” bez tagów, bez kontroli uprawnień i bez limitów budżetowych, a potem nikt nie wie, co jest krytyczne i kto ma to utrzymywać. Druga: zbyt szerokie role IAM (uprawnienia), bo „miało działać od razu”, co otwiera drzwi do wycieku danych po przejęciu konta.
Jeśli chmura ma być bezpieczna, potrzebujesz dyscypliny: separacji środowisk (prod/test), minimalnych uprawnień, logów audytowych, szyfrowania (w spoczynku i w tranzycie) oraz jasno opisanych zależności. I jeszcze jedno: plan wyjścia (exit plan). Lock-in nie boli w dniu wdrożenia, boli w dniu, gdy trzeba zmienić dostawcę albo odzyskać kontrolę nad kosztami.
Managed hosting/managed serwery: płacisz za ludzi i procesy
Usługi managed mają sens wtedy, gdy koszt przestoju jest wyższy niż koszt stałej opieki. Tu kupujesz nie tylko zasoby, ale też dyżury, procedury i praktykę w gaszeniu pożarów. Klucz to doprecyzowanie, co jest „w pakiecie”: czy obejmuje to aktualizacje, monitorowanie aplikacyjne (nie tylko ping), konfigurację backupu, wsparcie przy incydentach bezpieczeństwa, oraz realne SLA (czasy reakcji i przywrócenia).
Dobry test jakości managed: poproś o przykładowy proces obsługi incydentu i zakres danych, które dostaniesz po awarii (post-mortem, oś czasu, przyczyna, działania zapobiegawcze). Jeśli odpowiedź jest marketingowa albo „to zależy”, ryzyko przenosi się na ciebie — tylko drożej.
Bezpieczeństwo dostawcy — konkretne wymagania i pytania kontrolne (bez marketingu)
„Bezpieczny hosting” na stronie oferty oznacza zwykle tyle, że ktoś zainstalował certyfikat TLS i ma firewall na brzegu sieci. Dla firmy liczy się to, czy dostawca potrafi obronić trzy najczęstsze scenariusze: przejęcie konta, złośliwy ruch na aplikację (boty, exploity, brute force) i utrata danych po awarii. Każdy z nich da się zweryfikować pytaniami, które nie brzmią jak marketing.
Dostęp do panelu i serwerów: MFA, role i „kto widzi hasła”
Duża część incydentów zaczyna się banalnie: ktoś loguje się do panelu klienta i zmienia DNS, resetuje hasła poczty albo podmienia pliki strony. Jeśli panel nie wymusza MFA/2FA (drugi składnik logowania) i nie ma sensownej kontroli uprawnień, to prosisz się o problemy.
Sprawdź trzy rzeczy:
- MFA dla panelu i kont uprzywilejowanych — czy jest dostępne, czy da się je wymusić organizacyjnie, czy wspiera aplikacje TOTP/U2F.
- Role i delegowanie dostępu — czy możesz dać księgowości dostęp tylko do faktur, a agencji tylko do DNS, bez pełnych uprawnień.
- Audyt działań — czy panel pokazuje historię logowań i zmian (kto, kiedy, z jakiego IP). Bez tego po incydencie zostaje zgadywanie.
Uwaga: jeśli dostawca oferuje „zarządzanie serwerem”, dopytaj, jak wygląda dostęp administracji do twoich zasobów: czy jest per-operator, czy współdzielony, czy mają rejestrowanie sesji (session recording) i zasadę „least privilege” (minimalne uprawnienia). W praktyce to różnica między kontrolowanym serwisem a chaosem w stylu „ktoś się zalogował na roota i nie wiemy kto”.
WAF, anty-DDoS i ochrona przed botami: co jest w standardzie, a co „dodatkowo”
WAF (web application firewall) i ochrona anty-DDoS bywają sprzedawane jako „tarcza”, ale diabeł siedzi w szczegółach: gdzie to działa, co filtruje i jak wygląda obsługa fałszywych alarmów. DDoS to nie tylko „gigabity na sekundę”. Często bardziej boli zalew zapytań HTTP, które zabija aplikację, a nie łącze.
Konkrety do weryfikacji:
- Warstwa ochrony — czy anty-DDoS działa na L3/L4 (sieć/transport), a WAF na L7 (HTTP). Same filtry L3/L4 nie uratują przeciążonej aplikacji.
- Zakres — czy ochrona obejmuje też panel, API, pocztę, a nie tylko „stronę WWW”.
- Tryb działania — czy WAF jest w trybie blokowania, czy tylko monitoruje; czy możesz wprowadzać reguły per aplikacja.
- Obsługa incydentu — czy w razie ataku dostajesz realną pomoc (np. korekta reguł, tymczasowe limity, rate limiting), czy tylko „proszę włączyć Cloudflare”.
Krótki scenariusz z praktyki: sklep zaczyna sypać 503 mimo że CPU „nie wygląda źle”. Powód: boty robią kilkaset zapytań na sekundę do wyszukiwarki, a aplikacja mieli zapytania do bazy. Dostawca z sensownym WAF/rate limitingiem odcina ten ruch na brzegu. Dostawca bez tego każe „zwiększyć serwer”.
Szyfrowanie i certyfikaty: HTTPS to dopiero początek
TLS (HTTPS) jest obowiązkowy, ale dla firmy istotne jest też szyfrowanie „w spoczynku” (na dyskach) i to, kto ma dostęp do kluczy. Jeśli używasz baz danych, dysków blokowych, obiektowego storage’u — dopytaj o:
- Szyfrowanie danych na nośnikach — czy jest domyślne, jak zarządzane są klucze (KMS/HSM vs „gdzieś w systemie”).
- Rotację i wygasanie certyfikatów — czy panel ostrzega, czy jest automatyczne odnawianie (np. Let’s Encrypt), czy dostawca wspiera SNI i nowoczesne konfiguracje.
- Kopie zapasowe a szyfrowanie — czy backupy są szyfrowane i czy klucz nie jest trzymany razem z kopią.
Tip: jeśli dostawca oferuje „bezpłatny SSL”, to dobrze — ale poproś też o informację, jak wygląda proces awaryjny, gdy automatyczne odnowienie nie zadziała. Najgorszy typ awarii to taki, którego nikt nie zauważa do momentu, gdy przeglądarka klientów zaczyna krzyczeć o „niezaufanej stronie”.
Logi i monitoring: bez telemetrii nie ma diagnostyki
Gdy coś przestaje działać, najpierw potrzebujesz danych: logów serwera, aplikacji, poczty, DNS, WAF, a czasem hypervisora. Jeśli dostawca nie daje logów albo trzyma je „krótko”, to w incydencie zostajesz z domysłami. Dodatkowo — logi muszą być wiarygodne (czas, integralność) i dostępne wtedy, gdy produkcja płonie.
Sprawdź:
- Dostępność logów — jakie logi są dostępne w panelu, a jakie tylko „na zgłoszenie”.
- Retencję — ile dni/tygodni logi są przechowywane i czy można je eksportować.
- Monitoring — czy dostawca monitoruje tylko „ping i CPU”, czy też usługi (HTTP/SMTP/IMAP), miejsce na dysku, i błędy aplikacyjne (np. 5xx).
- Alerting — czy możesz ustawić alerty do własnych kanałów (mail, webhook), a nie tylko „w panelu”.
Poczta firmowa: reputacja, SPF/DKIM/DMARC i antyspam po stronie dostawcy
Problemy z pocztą potrafią rozwalić firmę równie skutecznie jak padnięta strona: faktury nie dochodzą, klienci nie dostają potwierdzeń, a dział sprzedaży „jest niemy”. Jeżeli hosting ma obejmować e-mail, to samo „mamy serwer pocztowy” jest za mało.
Weryfikuj minimalny zestaw:
- Reputacja IP — czy dostajesz dedykowane IP dla wysyłki (jeśli wysyłasz dużo), jak dostawca reaguje na nadużycia innych klientów.
- SPF/DKIM/DMARC — czy panel pomaga to poprawnie skonfigurować i czy dostawca potrafi wytłumaczyć, co dokładnie wpisujesz w DNS.
- Antyspam/antywirus — jakie mechanizmy są używane, czy są kwarantanny, jak wygląda obsługa false positive.
- Rate limiting i bezpieczeństwo kont — ochrona przed brute force, wymuszanie silnych haseł, MFA (jeśli jest webmail/panel).
Uwaga: jeśli dostawca hostingu miesza „pocztę do firmy” z „masową wysyłką marketingową”, często kończy się to problemami z deliverability. Dopytaj wprost, czy dopuszczają cold mailing i jak separują takie use-case’y od zwykłych skrzynek firmowych.
RPO/RTO i testy odtwarzania: liczby, nie obietnice
Backup bez testu odtworzenia to potencjalna dekoracja. W umowie lub ofercie powinny pojawić się dwa parametry: RPO (Recovery Point Objective — ile danych maksymalnie możesz stracić) i RTO (Recovery Time Objective — jak szybko wracasz do działania). Jeśli dostawca nie chce mówić o RPO/RTO, to zwykle znaczy, że „zrobimy co się da”.
Co sprawdzić praktycznie:
- Czy da się wykonać restore samodzielnie (panel/API) i czy da się odtworzyć pojedynczy element (baza, katalog) bez nadpisania wszystkiego.
- Czy backup jest spójny — szczególnie dla baz danych i aplikacji transakcyjnych.
- Czy robione są testy odtworzenia i jak często. Jeśli nie robi dostawca, musisz robić ty (i uwzględnić to w procesie).
Umowa i SLA: miejsca, w których najczęściej „ucieka” odpowiedzialność
Ryzyko rzadko wynika z tego, że dostawca nie ma SLA. Częściej z tego, że SLA jest napisane tak, że w praktyce niewiele gwarantuje: ma dużo wyłączeń, liczy się w skali miesiąca, a „awaria” jest zdefiniowana jako kompletna niedostępność, bez odniesienia do jakości usługi (np. 10% requestów timeoutuje — ale ping odpowiada).
Jak czytać SLA, żeby nie dać się złapać na „średnią miesięczną”
Uptime 99,9% wygląda dobrze, dopóki nie przeliczysz tego na realny czas: SLA zwykle liczy się miesięcznie, a przerwy mogą się „kumulować” w najgorszych godzinach. Dodatkowo często nie wlicza się planowanych prac, awarii po stronie dostawców upstream, a czasem nawet problemów z DNS.
Szukanie konkretów w SLA:
- Definicja niedostępności — czy obejmuje błędy aplikacyjne wynikające z infrastruktury (np. storage), czy tylko „brak odpowiedzi”.
- Okna serwisowe — kiedy, jak komunikowane, czy możliwe są prace „poza oknem” i na jakich zasadach.
- Rekompensaty — nie po to, żeby „zarobić na awarii”, tylko żeby zobaczyć, czy dostawca bierze odpowiedzialność. Jeśli rekompensata jest symboliczna i trudna do uzyskania, SLA jest głównie deklaracją.
- Separacja SLA dla wsparcia — uptime usługi to jedno, czas reakcji supportu w P1/P2 to drugie. Dobre oferty rozdzielają te dwie rzeczy.
Czasy reakcji i eskalacja: co oznacza „24/7” w praktyce
„Wsparcie 24/7” potrafi oznaczać: formularz przyjmie zgłoszenie w nocy, a człowiek zobaczy je rano. Firmie zależy na tym, czy w krytycznym incydencie jest dyżur, czy jest eskalacja do drugiej linii, i czy dostaniesz odpowiedź merytoryczną, a nie autoresponder.
Proste pytania kontrolne, które szybko odsiewają „best effort”:
- Jak wygląda klasyfikacja priorytetów (P1/P2/P3) i jakie są czasy pierwszej reakcji oraz czasy obejścia problemu?
- Czy jest telefon dyżurny dla P1, czy tylko e-mail/ticket?
- Jak działa eskalacja — po ilu minutach/godzinach zgłoszenie trafia do inżyniera infrastruktury?
- Czy support ma dostęp do metryk i logów, czy „pyta adminów” dopiero po twoim zgłoszeniu?
Własność danych, lokalizacja i podwykonawcy: GDPR/RODO bez iluzji
Dla wielu firm istotne jest, gdzie fizycznie i prawnie są dane. Nawet jeśli „serwer w UE”, to backup może leżeć gdzie indziej, a część usług może być outsourcowana. Nie chodzi o tworzenie prawniczego labiryntu, tylko o uniknięcie zaskoczeń przy audycie lub incydencie.
Sprawdź, czy dostawca jasno podaje:
- Lokalizacje centrów danych i gdzie trzymane są backupy (off-site też ma lokalizację).
- Podwykonawców (np. anty-DDoS, mail gateway, storage) i czy jest to opisane w umowie powierzenia.
- Procedurę zgłaszania naruszeń i czas powiadomienia o incydencie bezpieczeństwa.
Pułapki ofertowe i czerwone flagi, które widać bez dostępu do serwerowni
Nie musisz audytować data center, żeby wyłapać problemy. Sporo sygnałów jest „na wierzchu”: w panelu, regulaminie, sposobie komunikacji i w tym, jak sprzedawca odpowiada na techniczne pytania.
„Nielimitowane” zasoby i brak limitów na procesy: konflikt wpisany w model
Jeżeli oferta mówi o nielimitowanym transferze, nielimitowanej liczbie stron i „turbo wydajności”, a jednocześnie nie mówi o limitach CPU/RAM/IO, to znaczy, że limity są — tylko ukryte w regulaminie lub egzekwowane uznaniowo. W firmie to prosta droga do sytuacji: kampania rusza, ruch rośnie, a konto dostaje throttling (ograniczenie) i nikt nie potrafi powiedzieć dlaczego.
Brak status page i historii awarii: cisza informacyjna to też ryzyko
Status page (publiczna strona statusu) nie gwarantuje braku awarii, ale pokazuje dojrzałość operacyjną: komunikację, timeline, czas trwania, czasem post-mortem. Jeśli nie ma żadnego kanału statusowego, a jedynym źródłem prawdy jest support, to w kryzysie tracisz czas na ustalanie, czy problem jest u ciebie.
Panel bez audytu i bez eksportu danych: lock-in w wersji codziennej
Jeżeli nie możesz łatwo wyeksportować stref DNS, listy skrzynek, konfiguracji usług, logów i backupów, to migracja będzie bolała. Lock-in nie zawsze jest „celowy”, czasem wynika z bałaganu. Efekt biznesowy jest ten sam: trudniej zmienić dostawcę, nawet jeśli jakość spada.
W praktyce brak eksportu oznacza też brak dowodów w sporze. Gdy pojawia się incydent (np. nagłe spowolnienia albo podejrzenie włamania), a dostawca nie daje surowych logów HTTP/systemowych ani historii zmian w panelu, zostajesz z „na pewno u was”. Bez danych nie zrobisz sensownego RCA (root cause analysis — analiza przyczyny źródłowej), nie odtworzysz sekwencji zdarzeń, nie podeprzesz się tym u ubezpieczyciela.
Sprawdza się prosty test: czy jesteś w stanie w godzinę zebrać paczkę migracyjną bez proszenia o łaskę — strefy DNS w standardowym formacie, backup bazy i plików, listę kont/szynek/aliasów, certyfikaty (albo przynajmniej możliwość ich ponownego wystawienia), oraz logi z sensownym zakresem czasu. Jeśli „da się”, ale tylko przez ticket z czasem realizacji „do 7 dni roboczych”, to w kryzysie i tak jesteś uwiązany.
Uwaga: lock-in potrafi być subtelny. Częsty przypadek to własny „kreator DNS”, który generuje rekordy, ale nie pokazuje pełnego BIND-a (strefy), albo panel, który nie pozwala ustawić TTL (czas życia rekordu w cache) poniżej jakiejś wartości — a potem migracja ciągnie się godzinami, bo stare wpisy siedzą w resolverach. Inny klasyk: backup „jest”, ale nie da się go pobrać, tylko odtworzyć na tym samym koncie. To nie backup, tylko funkcja cofania.
Tip: poproś o dostęp do demo panelu i sprawdź trzy rzeczy zanim zapłacisz: eksport DNS, pobranie backupu oraz to, czy historia działań (kto/co/kiedy zmienił) jest w ogóle widoczna. Zajmuje to kilka minut, a oszczędza dni nerwów.
Sprzedaż „bezpiecznego hostingu” bez szczegółów: marketing zastępuje kontrolę
Hasła typu „enterprise security”, „AI antywirus” czy „pełna ochrona DDoS” są tanie — konkret jest drogi. Jeżeli nie dostajesz chociaż zarysu architektury bezpieczeństwa (WAF — web application firewall, separacja tenantów, segmentacja sieci, model aktualizacji), to nie masz czego ocenić. W firmie to kończy się zakupem „poczucia bezpieczeństwa”, a nie usługi.
Dobre pytania są techniczne i krótkie: czy jest 2FA/MFA w panelu, jak wygląda rotacja kluczy i dostępów uprzywilejowanych, czy są regularne aktualizacje jądra/hipernadzorcy (dla VPS), jak obsługiwane są podatności krytyczne (SLA na patchowanie), czy dostaniesz raport po incydencie. Jeśli odpowiedzi są wymijające albo sprowadzają się do „mamy certyfikaty”, to sygnał ostrzegawczy.
Mini-checklista przed podpisaniem: szybki filtr ryzyka
- Dane i wyjście awaryjne: eksport DNS, pobieralny backup, dostęp do logów, jasna ścieżka migracji bez „ticketów na wszystko”.
- Bezpieczeństwo: MFA w panelu, WAF/ochrona przed brute force, sensowna polityka haseł, opis procesu patchowania i reagowania na incydenty.
- Backup i odtwarzanie: RPO/RTO na piśmie, testy restore (kto i jak często), możliwość odtworzenia selektywnego, backup off-site z lokalizacją.
- Operacje i support: status page z historią, czasy reakcji dla P1, realna eskalacja, rozdzielone SLA na usługę i wsparcie.
- Granice usługi: jawne limity CPU/RAM/IO, zasady antyabuse, separacja poczty firmowej od masowej wysyłki.
Jeśli na kilka punktów nie da się uzyskać prostych, weryfikowalnych odpowiedzi — to już jest odpowiedź. W hostingu najwięcej kosztuje nie sama awaria, tylko chaos wokół niej: brak danych, brak procedur i brak możliwości szybkiego ruchu.
Plan awaryjny i testy przed migracją: jak nie zepsuć DNS, poczty i TLS
Najwięcej szkód robi nie sama zmiana dostawcy, tylko migracja „na żywca”: bez obniżenia TTL, bez kopii konfiguracji, z pocztą przenoszoną w trakcie dnia pracy. Efekt jest przewidywalny: część klientów trafia na starą stronę, część na nową, a skrzynki odbierają wiadomości w dwóch miejscach albo wcale.
DNS: TTL, rekordy i kolejność zmian
DNS działa jak pamięć podręczna internetu. Jeśli TTL (time-to-live) jest wysokie, stare rekordy będą krążyć godzinami. Dobre podejście wygląda nudno, ale działa:
- Najpierw obniż TTL kluczowych rekordów (A/AAAA, CNAME, MX) na 300–900 sekund — na starym dostawcy i z wyprzedzeniem (dzień wcześniej bywa rozsądnym minimum).
- Zrób eksport strefy (pełny BIND lub równoważny) i porównaj rekord po rekordzie, zamiast „klikać w kreator”. Uwaga na brakujące TXT (SPF/DKIM/DMARC, weryfikacje usług).
- Unikaj zmiany nameserverów „w ciemno”. Bezpieczniej jest najpierw postawić identyczną strefę u nowego dostawcy i dopiero wtedy przepiąć delegację.
Tip: jeśli dostawca DNS nie pokazuje SOA/NS w sensownej formie albo nie pozwala kontrolować TTL — ryzyko migracji rośnie. DNS bez kontroli TTL to proszenie się o długie „szarpanie” po przełączeniu.
Poczta: najczęstszy scenariusz wpadki to MX + SPF/DKIM
Poczta firmowa jest bezlitosna: małe potknięcie i nagle wiadomości lądują w spamie albo odbijają. W migracji maili zwykle psują się trzy rzeczy:
- MX (gdzie ma trafić poczta) przełączony zanim nowe skrzynki są gotowe.
- SPF (kto ma prawo wysyłać) nieaktualny po zmianie serwera/relaya.
- DKIM (podpis) — stary klucz zostaje w DNS, a nowa usługa podpisuje innym; część odbiorców zaczyna odrzucać.
Dodatkowo dochodzi DMARC (polityka, co robić z niezgodnymi mailami). Jeśli DMARC jest ustawiony restrykcyjnie (reject/quarantine), migrację trzeba robić ostrożniej, bo każdy błąd w SPF/DKIM robi realny „dowóz = 0”.
Uwaga: jeśli dostawca hostingu „przy okazji” obsługuje pocztę na współdzielonym IP, reputacja IP może cię ugryźć nawet bez twojej winy. Pytanie kontrolne brzmi: czy jest dedykowany outbound albo przynajmniej kontrola reputacji i mechanizmy antyabuse.
TLS/HTTPS: certyfikat to nie tylko „kłódka”
Po migracji częste są dwa objawy: ostrzeżenia przeglądarki i pętle przekierowań. W praktyce wynikają z pośpiechu przy certyfikatach i konfiguracji:
- Certyfikat: czy wystawiasz nowy (np. Let’s Encrypt) czy przenosisz istniejący. W obu przypadkach potrzebujesz kontroli DNS/HTTP-01 i dostępu do konfiguracji vhostów/reverse proxy.
- Łańcuch certyfikatów (intermediate) — czasem na nowej platformie „działa u mnie”, a u klientów sypie się, bo brakuje pełnego chain.
- HSTS (HTTP Strict Transport Security) — jeśli domena ma HSTS, powrót na HTTP nie jest „awaryjną opcją”. To dobrze dla bezpieczeństwa, słabo dla improwizacji.
Tip: zanim przepniesz ruch, sprawdź nową instancję po adresie tymczasowym (subdomena, wpis w /etc/hosts, preview URL) i zrób szybki test: nagłówki, przekierowania, certyfikat, ładowanie zasobów mieszanych (mixed content).
Backup i odtwarzanie bez mitów: RPO/RTO, retencja i test restore
Wiele firm dowiaduje się, że „backup był”, dopiero gdy trzeba go odtworzyć — i okazuje się, że backup obejmuje tylko pliki, bez bazy, albo trzyma jedną wersję z ostatniej doby, albo odtworzenie wymaga zgłoszenia i czekania. Biznesowo to różnica między „godzina niedostępności” a „odtwarzamy dwa dni i dalej nie działa”.
RPO i RTO: dwie liczby, które ustawiają rozmowę
RPO (Recovery Point Objective) odpowiada na pytanie: ile danych możesz stracić (np. ostatnie 15 minut vs ostatnia doba). RTO (Recovery Time Objective): jak szybko usługa ma wrócić. Dostawca może mieć świetne backupy, ale fatalne RTO, bo odtwarzanie jest ręczne i kolejka jest długa.
Jeśli dostawca nie chce podać RPO/RTO albo mówi „to zależy”, dopytaj o mechanikę:
- Jak często robione są backupy i czy obejmują pliki + bazy + konfigurację?
- Jaka jest retencja (ile wersji i z jakiego okresu)?
- Czy backup jest off-site (fizycznie/logicznnie poza główną infrastrukturą)?
- Kto i jak wykonuje restore: ty w panelu, support, automaty, a może „tylko pełne odtworzenie konta”?
Snapshot, backup, replikacja: podobne słowa, różne konsekwencje
Uwaga na pojęcia:
- Snapshot (migawka dysku/VM) bywa szybki, ale często jest w tej samej macierzy/storage — przy awarii storage’u nie pomaga.
- Backup powinien być niezależny i możliwy do pobrania. Jeśli nie da się go wyeksportować, to jesteś zależny od platformy.
- Replikacja (np. bazy) chroni przed awarią jednego węzła, ale powiela też błędy logiczne (usunięcie danych, zaszyfrowanie ransomware).
Dobry zestaw to: snapshoty do szybkich rollbacków + backup off-site do scenariuszy „spaliło się coś większego” + procedura odtworzenia, która nie zakłada szczęścia.
Test odtworzenia: jedno pytanie, które obnaża dojrzałość
Poproś o opis, jak wygląda test restore: jak często, kto go robi i co dokładnie jest weryfikowane (czy tylko „da się rozpakować”, czy aplikacja wstaje i odpowiada). Jeśli dostawca mówi, że „backup jest, ale testów nie robimy”, to masz odpowiedź o prawdopodobieństwie powodzenia w kryzysie.
Krótki przykład z praktyki: sklep po aktualizacji wtyczki przestał działać. Backup „dzienny” okazał się robiony o tej samej porze co deploy, więc zawierał już uszkodzony stan. Gdyby była retencja kilku wersji (np. 7–14 dni) i możliwość selektywnego odtworzenia bazy, sytuacja skończyłaby się dużo szybciej.
Bezpieczeństwo konta i dostępów: najtańszy atak to przejęcie panelu
Włamania do stron i poczty często nie zaczynają się od „hakowania serwera”, tylko od przejęcia panelu klienta: phishing, wyciek hasła, brak MFA, zbyt szerokie uprawnienia. A potem już jest prosto: zmiana DNS, podmiana plików, reset haseł w skrzynkach.
MFA, role i dziennik zdarzeń: minimum dla firmowego hostingu
Weryfikacja po stronie dostawcy jest banalna do sprawdzenia, a robi ogromną różnicę:
- MFA/2FA obowiązkowe dla panelu (najlepiej TOTP/FIDO2). „Opcjonalne” często kończy się tym, że nikt go nie włącza.
- Role i uprawnienia (RBAC) — rozdziel dostęp do DNS, rozliczeń, serwerów i poczty. Konto „admin do wszystkiego” to proszenie się o kłopoty.
- Audit log (dziennik zdarzeń) w panelu: kto zmienił rekord DNS, kto dodał klucz SSH, kto wygenerował token API. Bez tego nie zrobisz analizy incydentu.
Uwaga: jeśli dostawca oferuje API, sprawdź politykę tokenów (zakres uprawnień, wygasanie, możliwość rotacji). Token bez ograniczeń + bez logów = cichy wektor ataku.
Dostępy uprzywilejowane i „managed”: gdzie kończy się odpowiedzialność dostawcy
Usługi typu managed kuszą, bo zdejmują z firmy administrowanie. Ale tu jest pułapka: czasem „managed” oznacza tylko instalację aktualizacji systemu, a aplikacja i jej bezpieczeństwo zostają po twojej stronie. Dopytaj o granicę:
- Czy dostawca aktualizuje tylko OS, czy też stack (PHP/Node/DB) i komponenty typu Redis?
- Czy monitoruje usługi aplikacyjne, czy tylko „czy VM żyje”?
- Jak wygląda dostęp administracyjny: czy dostawca ma konto root, jak jest chronione, jak jest logowane?
Praktyczny wybór: szybka ścieżka decyzji pod ryzyko w firmie
Jeśli decyzja utknęła między „tani, ale niepewny” a „drogi, ale nie wiadomo za co”, pomaga sprowadzić ją do scenariuszy. Nie do parametrów z folderu reklamowego, tylko do tego, co naprawdę boli, gdy się psuje.
Jeśli największe ryzyko to przestoje sprzedaży
- Wybieraj model z monitoringiem i jasnym SLA na incydenty (osobno uptime i support P1).
- Szukaj status page i dojrzałej komunikacji (timeline, powiadomienia).
- Weryfikuj IO/storage (to częsta przyczyna „wszystko działa, ale muli”) oraz opcje skalowania bez migracji w nocy.
Jeśli największe ryzyko to utrata danych
- Wymagaj RPO/RTO oraz retencji kilku wersji.
- Backup ma być off-site i pobieralny.
- Zapytaj o testy restore i procedurę odtworzenia „na żądanie” (kto robi, w jakim czasie).
Jeśli największe ryzyko to przejęcie konta / incydent bezpieczeństwa
- Bez MFA i audit logów w panelu nie ma rozmowy.
- Liczy się izolacja (na współdzielonych środowiskach: separacja kont, ograniczenia procesów, reguły anty-bruteforce) oraz praktyczne mechanizmy (WAF, rate limiting).
- Dostawca powinien umieć powiedzieć, jak wygląda proces reagowania i w jakim czasie informuje o naruszeniu.
Mini-checklista operacyjna: ostatni test zdrowego rozsądku
- Demo panelu: włącz MFA, sprawdź audit log, sprawdź eksport DNS i pobranie backupu.
- SLA: definicja awarii + czasy reakcji P1 + wyłączenia + procedura eskalacji.
- Backup: częstotliwość, retencja, off-site, test restore, możliwość odtworzenia selektywnego.
- Mail: zasady reputacji IP, wsparcie dla SPF/DKIM/DMARC, separacja ruchu masowego od firmowego.
- Wyjście awaryjne: czy w 60 minut zbierzesz paczkę do migracji (strefa DNS, dane, konfiguracje, logi) bez czekania na support.
Najczęściej zadawane pytania (FAQ)
Na co patrzeć przy wyborze hostingu dla firmy, żeby uniknąć przestojów?
Największe ryzyko nie siedzi w „parametrach serwera”, tylko w tym, co dzieje się, gdy coś się wysypie: monitoring, dyżury, eskalacja i realny czas przywrócenia. Jeżeli dostawca mówi wyłącznie „wsparcie 24/7”, ale nie rozróżnia czasu reakcji od czasu naprawy, to w krytycznym momencie możesz dostać tylko grzeczny ticket.
Sprawdź operacyjnie, czy mają: status page (publiczna strona statusu), jasne poziomy priorytetów incydentów, kontakt awaryjny oraz opis, jak wygląda post-mortem (analiza przyczyn po awarii). To są rzeczy, które odróżniają stabilną usługę od „hostingu z folderem na pliki”.
Co powinno być w SLA hostingu i jak je czytać?
SLA (Service Level Agreement) bywa mylące, bo samo „99,9% uptime” niewiele mówi o Twoim scenariuszu. Kluczowe są zapisy o tym, ile trwa reakcja na zgłoszenie (czas reakcji) oraz ile maksymalnie może potrwać przywrócenie usługi (czas naprawy/przywrócenia), plus godziny obowiązywania wsparcia i sposób eskalacji.
Uwaga: jeśli w SLA są tylko kredyty/zwroty, a brak konkretnych procesów (kto, kiedy, jak przywraca), to w praktyce płacisz za ryzyko przestoju. Dopytaj też o komunikację w trakcie incydentu: czy dostajesz aktualizacje, czy musisz „wydzwaniać”, żeby cokolwiek ustalić.
Jak sprawdzić, czy backupy hostingu są realne, a nie tylko „bo są”?
Backup bez testu odtworzenia to obietnica, nie mechanizm. Minimum to jasna odpowiedź na: jak często robione są kopie, jaka jest retencja (ile dni/wersji trzymają), gdzie są składowane (off-site, czyli w innej lokalizacji) i czy da się odtworzyć konkretny punkt w czasie (np. sprzed kilku godzin), a nie tylko „ostatnią kopię”.
W rozmowie padają zwykle dwa parametry: RPO (Recovery Point Objective – ile danych możesz stracić) i RTO (Recovery Time Objective – jak szybko usługa wróci). Tip: poproś o opis procedury restore krok po kroku i zapytaj wprost, czy robią okresowe testy odtwarzania (nawet na środowisku testowym).
VPS, chmura czy hosting współdzielony — co jest bezpieczniejsze dla firmy?
To zależy od tego, kto ma zarządzać systemem i bezpieczeństwem. Hosting współdzielony bywa OK dla prostych stron, ale częściej cierpi na overselling (sprzedawanie zasobów „na zapas”), co kończy się losowymi spadkami wydajności. VPS daje więcej kontroli, ale przenosi na firmę (lub administratora) aktualizacje, hardening i monitoring.
Jeśli nie masz zasobów na administrację, sensowną opcją jest hosting managed (zarządzany) albo usługa, gdzie dostawca bierze odpowiedzialność za aktualizacje, backup, monitoring i reakcję na incydenty. Bez względu na model, dopytaj o izolację klientów, limity zasobów oraz praktyki bezpieczeństwa (MFA, logi, procedury incydentowe).
Jak zabezpieczyć konto hostingu przed przejęciem (panel/FTP/SSH)?
Najczęstszy punkt wejścia to konto do panelu, a nie „magiczne hakowanie serwera”. Szukaj dostawcy, który ma MFA/2FA (uwierzytelnianie wieloskładnikowe), role i uprawnienia (RBAC), historię logowań i zmian oraz możliwość ograniczenia dostępu po IP. Dla SSH liczy się wsparcie dla kluczy (zamiast haseł) i szybka opcja blokady/„zamrożenia” dostępu przy podejrzeniu włamania.
Uwaga: „antywirus na serwerze” nie zastąpi podstaw typu MFA i logów audytowych. Jeśli kilka osób loguje się jednym hasłem „na firmę”, to prędzej czy później robi się z tego incydent, którego nie da się nawet dobrze prześledzić.
Jak uniknąć problemów przy migracji DNS i certyfikatów SSL/TLS?
Najczęstszy błąd to przełączenie DNS bez przygotowania TTL (czas życia rekordu w cache). Gdy TTL jest wysokie, część użytkowników przez długi czas trafia na starą infrastrukturę, mimo że „już przełączone”. Dobrą praktyką jest obniżenie TTL odpowiednio wcześniej i uruchomienie okresu równoległego działania (stare i nowe środowisko).
Drugi temat to TLS (HTTPS): certyfikat musi obejmować właściwe domeny/subdomeny, mieć pełny łańcuch i odnawiać się automatycznie (np. Let’s Encrypt). Na koniec zrób krótką checklistę rekordów: A/AAAA/CNAME, MX, oraz SPF/DKIM/DMARC — migracja strony potrafi „przy okazji” zepsuć pocztę.
- Obniż TTL przed zmianą i zaplanuj rollback.
- Sprawdź certyfikaty na wszystkich subdomenach.
- Zweryfikuj rekordy pocztowe (MX + SPF/DKIM/DMARC).
Co musi mieć poczta firmowa, żeby nie wpadała do spamu i nie była blokowana?
Techniczne minimum to SPF (kto może wysyłać), DKIM (podpis wiadomości) i DMARC (polityka weryfikacji + raporty). Dostawca powinien nie tylko „obsługiwać”, ale realnie ułatwiać konfigurację tych rekordów i diagnozę problemów z dostarczalnością (logi, czytelne komunikaty o odrzuceniach).
Jeśli poczta jest na hostingu współdzielonym, zapytaj o ryzyko „sąsiada” (wspólne IP) i procedurę przy podejrzeniu spamu: czy jest kwarantanna i weryfikacja, czy od razu twarda blokada konta. Tip: separacja usług (WWW u jednego dostawcy, poczta w usłudze stricte pocztowej) często zmniejsza skutki awarii i incydentów.
Bibliografia i źródła
- ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. International Organization for Standardization (2022) – Wymagania ISMS; kontrola dostępu, incydenty, ciągłość i audytowalne procedury.
- ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls. International Organization for Standardization (2022) – Katalog kontroli: MFA, logowanie zdarzeń, kopie zapasowe, zarządzanie zmianą.
- NIST Special Publication 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems. National Institute of Standards and Technology (2010) – Planowanie awaryjne IT; strategie backup/restore, testy odtworzeń, role i eskalacja.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. Internet Engineering Task Force (2011) – Standard DKIM; podpisy wiadomości i weryfikacja integralności nadawcy.
- OWASP Application Security Verification Standard (ASVS). OWASP Foundation – Wymagania bezpieczeństwa aplikacji; uwierzytelnianie, sesje, logowanie, MFA.
