Co sprawdzić w infrastrukturze serwera przed sezonem sprzedażowym w e-commerce

Serwer, który przez 10 miesięcy roku działa bez problemu, może nie wytrzymać trzykrotnego skoku ruchu w ciągu jednej doby. Black Friday, powrót do szkoły i okres świąteczny to trzy momenty, które co roku kończą się awariami sklepów nieprzypadkowych, bo właściciele zakładają, że skoro serwer działa, to będzie działał. Poniższa lista obejmuje 6 rzeczy do sprawdzenia 4 tygodnie przed każdym szczytem. Cztery tygodnie dają czas na reakcję. Dwa tygodnie to już zarządzanie kryzysem.

Czego nie sprawdzasz na co dzień, a co zawodzi przy dużym ruchu?

Codzienne działanie sklepu obciąża serwer równomiernie i przewidywalnie. Szczyt sprzedażowy to inne zjawisko: jednoczesne sesje, duże koszyki, wielokrotne przeładowania strony produktowej i jednoczesne procesy kasowe. Awaria pojawia się nie tam, gdzie spodziewasz się wąskiego gardła, tylko tam, gdzie limit zasobu kończy się jako pierwszy.

Cztery najczęstsze punkty awarii przy skoku ruchu:

• limit połączeń do bazy danych (MySQL max_connections)
• brak cache dla stron produktowych i kategorii
• brak CDN dla plików statycznych (obrazy, JS, CSS)
• backup uruchamiający się w godzinach szczytu i blokujący zasoby

4 tygodnie przed szczytem: lista kontrolna

1. Sprawdź limity zasobów i izolację

Na hostingu współdzielonym każde konto ma przydzielony limit CPU, RAM i liczby procesów. Przy gwałtownym wzroście ruchu limit kończy się szybciej niż myślisz, a hosting nie ostrzega z wyprzedzeniem, tylko zwraca błąd 508 lub białą stronę.

Co sprawdzić:

• aktualny przydział CPU i RAM w panelu hostingu
• statystyki zużycia z ostatnich 30 dni (peak vs. średnia)
• czy hosting używa izolacji zasobów (np. CloudLinux), która chroni Twoje konto przed wpływem innych użytkowników na tym samym serwerze
• czy możliwe jest tymczasowe zwiększenie limitu na okres szczytu

Jeśli Twój hosting nie pokazuje zużycia zasobów w panelu, nie masz danych do oceny ryzyka. To jest już informacja.

2. Skonfiguruj i przetestuj cache

Cache to pierwsza linia obrony przed przeciążeniem serwera. Strona ładowana z cache nie generuje zapytania do bazy danych ani wykonania PHP. Przy 1 000 jednoczesnych użytkowników różnica między sklepem z cache a bez cache to często różnica między działaniem a awarią.

Co sprawdzić:

• czy cache stron jest włączony i aktywny (sprawdź nagłówek `X-Cache: HIT` w narzędziach deweloperskich przeglądarki)
• czy strony produktowe i kategorie są cachowane (często wyłączone przez wtyczki lub błędną konfigurację)
• czy cache jest czyszczony zbyt agresywnie przy każdej zmianie produktu
• czas życia cache (TTL): dla stron produktowych 1–4 godziny to rozsądny kompromis między świeżością danych a wydajnością

Na serwerze LiteSpeed cache działa na poziomie serwera, nie aplikacji, co oznacza, że jest znacznie szybszy niż wtyczkowy cache WordPress. Jeśli Twój hosting używa Apache lub Nginx bez dedykowanego cache, sprawdź, czy masz skonfigurowany Redis lub Memcached dla cache obiektów bazy danych.

3. Włącz CDN dla plików statycznych

CDN (Content Delivery Network) serwuje pliki statyczne (obrazy, CSS, JavaScript) z serwera geograficznie bliżej użytkownika. Dla sklepu e-commerce to oznacza dwie rzeczy: szybsze ładowanie strony i odciążenie głównego serwera od serwowania plików, które nie wymagają przetwarzania.

Co sprawdzić:

• czy CDN jest włączony i obsługuje obrazy produktowe (to zazwyczaj największy wolumen danych)
• czy pliki są serwowane z CDN (sprawdź nagłówek `CF-Cache-Status` dla Cloudflare lub odpowiednik innego dostawcy)
• czy obrazy są skompresowane i serwowane w formacie WebP (redukcja rozmiaru o 25–35% vs. JPEG przy tej samej jakości wizualnej)
• czy CDN ma włączony cache dla stron HTML (opcjonalne, ale skuteczne przy bardzo dużym ruchu)

Cloudflare w planie darmowym wystarczy dla większości sklepów do kilku tysięcy sesji dziennie. Przy większym ruchu warto rozważyć plan Pro (20 USD/mies.) dla priorytetowego cache i reguł firewall.

4. Zoptymalizuj bazę danych

Baza danych to najczęstszy punkt awarii przy dużym ruchu w WooCommerce i innych platformach opartych na MySQL. Każde zapytanie o produkt, kategorię, koszyk i zamówienie to osobne zapytanie do bazy. Przy 500 jednoczesnych użytkownikach niezoptymalizowana baza generuje kolejkę zapytań, która blokuje nowe połączenia.

Co sprawdzić:

• indeksy tabel: uruchom `SHOW INDEX FROM wp_posts` i `wp_postmeta` i sprawdź, czy indeksy istnieją dla kolumn używanych w zapytaniach WooCommerce
• rozmiar tabeli `wp_options` z opcjami autoload: jeśli przekracza 1 MB, masz prawdopodobnie setki wtyczek zapisujących dane przy każdym ładowaniu strony
• `max_connections` w konfiguracji MySQL: domyślna wartość 151 kończy się przy dużym ruchu; na serwerze dedykowanym lub VPS zwiększ do 300–500
• czy używasz persistent connections (trwałe połączenia do bazy) przez Redis lub podobne rozwiązanie

Narzędzie: wtyczka Query Monitor (WordPress) pokazuje, ile zapytań do bazy generuje każda podstrona i które z nich są wolne.

5. Przesuń backup poza godziny szczytu

Backup uruchamiający się o 12:00 w Black Friday to nie jest scenariusz abstrakcyjny. Domyślne harmonogramy backupu często są ustawione raz i nigdy nie zmieniane. Pełny backup bazy danych i plików to operacja I/O, która przez kilkanaście minut obciąża dysk i CPU.

Co sprawdzić:

• kiedy uruchamia się backup (cron w panelu hostingu lub harmonogram wtyczki)
• czy backup przechowywany jest poza głównym serwerem (lokalny backup to nie backup)
• czas ostatniego udanego backupu i jego rozmiar
• czy masz przetestowane przywracanie: backup, który nie był testowany, nie jest backupem

Przestaw harmonogram na godziny 2:00–5:00 w nocy. W dniu Black Friday rozważ wyłączenie automatycznego backupu i uruchomienie go ręcznie po zakończeniu szczytu.

6. Przygotuj plan awaryjny

Plan awaryjny to dokument, nie zamiar. Powinien istnieć przed szczytem, nie być tworzony w trakcie awarii.

Co powinien zawierać:

• dane kontaktowe hostingu (panel, telefon awaryjny, ticket support) zapisane poza systemem, który może nie działać
• czas reakcji support (SLA): sprawdź, czy Twój plan hostingowy gwarantuje czas odpowiedzi i jaki
• procedura przywracania backupu: kto to robi, skąd pobiera backup, ile to zajmuje
• próg decyzji: przy jakim czasie niedostępności sklepu dzwonisz do hostingu zamiast czekać na ticket

Jeśli hosting nie ma telefonu awaryjnego ani SLA poniżej 4 godzin, masz odpowiedź na pytanie, czy Twoja infrastruktura jest gotowa na szczyt sprzedażowy.

Kiedy zacząć?

4 tygodnie przed szczytem: sprawdź listę, zidentyfikuj braki, zamów zmiany u hostingu lub dewelopera.

2 tygodnie przed szczytem: wdroż zmiany, przetestuj cache i przywracanie backupu, sprawdź metryki po zmianach.

1 tydzień przed szczytem: przestaw harmonogram backupu, wyłącz zbędne wtyczki, zrób test obciążeniowy (narzędzia: k6, Loader.io, plan darmowy wystarczy do podstawowego testu).

Dzień szczytu: monitoruj serwer w czasie rzeczywistym (np. przez UptimeRobot z alertem SMS), miej plan awaryjny pod ręką.

---

Jeśli chcesz sprawdzić, czy Twoja obecna infrastruktura wytrzyma szczyt sprzedażowy, szczegóły dotyczące hostingu i konfiguracji serwera znajdziesz na stronie usługi hostingowe.