Telefon zadzwonił o 9:47 rano w Black Friday. Belgijski sprzedawca odzieży uruchomił największą promocję roku, przygotowaną tygodniami kampanii e-mailowych, współpracą z influencerami i płatną reklamą. Ruch skoczył dokładnie tak, jak planowano — a ich sklep PrestaShop padł całkowicie w ciągu pierwszej godziny. Klienci klikający starannie przygotowane reklamy trafiali na strony błędów zamiast na oferty ograniczone czasowo, które im obiecano. Strona na chwilę wracała, wyświetlała kilka podstron, a potem znowu się sypała, gdy kolejka zapytań przeciążała każdą chwilowo dostępną pojemność. Zanim się z nami skontaktowali, stracili już ponad €40,000 przewidywanej sprzedaży, a najruchliwsze godziny zakupowe roku właśnie mijały. Dostawca hostingu upierał się, że serwery są w porządku. Poprzedni programista nie odbierał telefonów. Inwestycja w marketing wyparowywała na bieżąco.

→ Masz awarię wydajności? Nasz zespół reaguje od razu

Opisane objawy wskazywały na awarię warstwy bazy danych — charakterystyczny wzorzec częściowego powrotu, po którym następuje kolejny upadek, oznacza wyczerpanie połączeń, a nie zwykłe nasycenie zasobów. Przy normalnym ruchu ich konfiguracja MySQL obsługiwała skromną liczbę jednoczesnych użytkowników bez problemu. Ale ruch w Black Friday pomnożył liczbę jednoczesnych odwiedzających pięćdziesięciokrotnie, a każdy z nich generował wiele zapytań do bazy: produkty, operacje koszyka i sesje. Limit stu pięćdziesięciu jednoczesnych połączeń wydawał się hojny podczas rozmów planistycznych z poprzednim programistą; przy rzeczywistym obciążeniu świątecznym wyczerpywał się w ciągu kilku minut po każdym powrocie i powstawał cykl, w którym baza na chwilę przyjmowała połączenia, natychmiast się nasycała i odmawiała nowych zapytań, aż istniejące połączenia wygasły i zwolniły miejsce.

Środowisko hostingowe dołożyło kolejne utrudnienia, które wydłużyły czas naprawy. Wybrali zarządzanego dostawcę hostingu właśnie po to, żeby nie musieć nic ruszać, ale ta prostota oznaczała brak dostępu SSH, brak możliwości bezpośredniej zmiany konfiguracji MySQL i czas odpowiedzi wsparcia liczony w godzinach, w samym szczycie zgłoszeń u dostawcy w Black Friday. Ustawienia wydajności PrestaShop, które dało się zmienić w konfiguracji panelu — cache, kompilacja, tryb debugowania — były już ustawione poprawnie. Sama baza była w miarę zoptymalizowana, bo poprzedni programista wdrożył standardowe procedury czyszczenia. Problem leżał w warstwie infrastruktury, w konfiguracjach, których środowisko hostingowe celowo nie pozwalało im zmieniać.

→ Nie czekaj do Black Friday, żeby odkryć limity infrastruktury

Nasza interwencja awaryjna przebiegała dwutorowo. Po pierwsze, wdrożyliśmy natychmiastowe zarządzanie ruchem, aby zmniejszyć obciążenie bazy danych, zachowując jednocześnie jak największą przepustowość sprzedażową. Statyczne wersje kluczowych stron produktowych zostały wdrożone na serwerach brzegowych CDN, umożliwiając klientom przeglądanie kluczowych produktów promocyjnych, nawet gdy dynamiczne operacje nadal działały. Funkcjonalność koszyka i finalizacji zakupu została priorytetowo potraktowana poprzez routing żądań, który kierował ograniczone połączenia z bazą danych do operacji krytycznych dla konwersji, a nie do przeglądania. Operacje administracyjne zostały całkowicie zablokowane, aby zapobiec zużywaniu przez pracowników połączeń potrzebnych do dokonywania zakupów. Te środki pozwoliły sklepowi funkcjonować przy ograniczonej przepustowości – dalekiej od ideału, ale generującej sprzedaż, a nie tylko błędy.

Drugi tor dotyczył przyczyn źródłowych poprzez eskalację infrastruktury. Współpracując z zespołem ds. eskalacji awaryjnej dostawcy hostingu, wynegocjowaliśmy tymczasowe zmiany konfiguracji, które zwiększyły maksymalną liczbę połączeń z bazą danych i procesów roboczych PHP poza ich standardowe limity zarządzane. Alokacja pamięci dla procesów PHP została rozszerzona, aby zapobiec wyczerpaniu pamięci, które przyczyniło się do kaskadowych awarii. Wczesnym popołudniem – około cztery godziny po początkowej awarii – sklep ustabilizował się na pełnym obciążeniu, a infrastruktura została tymczasowo przekonfigurowana, aby obsłużyć ruch generowany przez promocję. Sprzedaż została wznowiona w wolumenach, które, choć niższe niż te, które można by osiągnąć w ciągu całego dnia pracy, pozwoliły odzyskać znaczną część przychodów z tego, co wydawało się całkowitą stratą.

Analiza po awarii pokazała infrastrukturę, która nigdy nie była właściwie skalowana pod ruch, jaki potrafił wygenerować zespół marketingu. Ich hosting PrestaShop wystarczał do zwykłej codziennej pracy i skromnych skoków promocyjnych, ale duże kampanie opierały się na założeniach o pojemności, których nikt nie potwierdził testami obciążeniowymi. Limit stu pięćdziesięciu połączeń z bazą obsługiwał przy ich wzorcu zapytań około stu jednoczesnych odwiedzających — daleko poniżej tysięcy, które przyciągnęłaby udana kampania Black Friday. Przydział pamięci na ich pakiecie nie udźwignął liczby procesów PHP potrzebnych przy wysokiej współbieżności. Te ograniczenia były niewidoczne przy normalnej pracy i ujawniły się katastrofalnie dopiero wtedy, gdy marketing osiągnął dokładnie tę skalę, do której dążył.

Rozwiązanie, które wdrożyliśmy na kolejne sezony, zamknęło te luki architekturą zaprojektowaną pod szczytową pojemność, a nie pod zwykłą wystarczalność. Infrastrukturę bazy przenieśliśmy na dedykowany hosting MySQL z limitami połączeń dopasowanymi do ich ambicji ruchowych. Serwery WWW ustawiliśmy za równoważeniem obciążenia, które mogło skalować się w poziomie w okresach promocji. Wdrożyliśmy cache Redis, co zmniejszyło liczbę zapytań do bazy o osiemdziesiąt procent i wyraźnie podniosło efektywną pojemność. Testy obciążeniowe potwierdziły, że nowa architektura utrzymała dziesięć tysięcy jednoczesnych użytkowników bez spadku wydajności — pojemność, która uniesie nawet wyjątkowo udane promocje, zanim infrastruktura stanie się ograniczeniem.

Czy Twój sklep jest gotowy na kolejną wielką szansę?

Kwota €40,000 utraconej sprzedaży w Black Friday, którą ten sprzedawca poniósł, to tylko bezpośrednio mierzalna szkoda — przychód od odwiedzających, którzy próbowali kupić w godzinach awarii. Koszty niemierzalne to relacje z klientami nadszarpnięte stronami błędów, reputacja marki nadszarpnięta skargami w mediach społecznościowych oraz budżet reklamowy zmarnowany na ruch, który dostał awarie zamiast zakupów. Każdy sklep PrestaShop planujący większą promocję działa przy podobnym ryzyku, jeśli infrastruktura nie została sprawdzona pod oczekiwany szczyt ruchu. Pytanie nie brzmi, czy uda ci się ściągnąć ruch — twój zespół marketingu pracuje właśnie nad tym. Pytanie brzmi, czy twoja infrastruktura zamieni ten ruch w sprzedaż, czy w studium przypadku o tym, co się dzieje, gdy przygotowanie nie dorównuje ambicji.

→ Sprawdź infrastrukturę przed następną kampanią