Baza wiedzy PrestaShop

W ciągu tygodnia realnie da się zrobić trzy rzeczy: zabezpieczyć dostępy, wykonać audyt otwierający i wdrożyć poprawki krytyczne. Czego nie da się zrobić bezpiecznie w tydzień, to większe prace rozwojowe w nieznanym kodzie. Kolejność ma znaczenie: najpierw dostępy i kopia zapasowa, potem diagnoza, dopiero na końcu zmiany. Odwrócenie tej kolejności jest najczęstszą przyczyną przestoju przy zmianie wykonawcy.

Zanim zadzwonisz do kogokolwiek, zabezpiecz pięć rzeczy. To jedyny etap, którego nie zrobi za Ciebie żadna agencja, a bez niego nowy zespół nie ruszy:

1. Dostęp do kodu i repozytorium. Jeśli kod jest tylko na serwerze, a nie w repozytorium, odnotuj to jako ryzyko numer jeden.
2. Dostęp do hostingu i panelu serwera, wraz z danymi do bazy.
3. Domena. Sprawdź, czy jest zarejestrowana na Waszą firmę, a nie na wykonawcę. To najczęstszy punkt zapalny przy rozstaniu.
4. Konta zewnętrzne: płatności, kurierzy, ERP, analityka, licencje modułów komercyjnych.
5. Świeża kopia zapasowa plików i bazy, pobrana na Wasz dysk, nie tylko „u wykonawcy”.

Realny harmonogram pierwszego tygodnia:

• Dzień 1 do 2: przekazanie dostępów, NDA, kopia zapasowa z testem odtworzenia, uruchomienie monitoringu.
• Dzień 2 do 4: audyt otwierający: stan kodu, nadpisania rdzenia, moduły bez wsparcia, integracje, wydajność. Wynikiem jest lista rzeczy krytycznych i plan.
• Dzień 4 do 7: środowisko testowe i naprawa rzeczy blokujących sprzedaż. Zmiany wchodzą poza godzinami szczytu, z możliwością szybkiego wycofania.
• Od drugiego tygodnia: prace rozwojowe, gdy zespół zna już środowisko.

Czego nie robić, nawet pod presją: nie zrywaj współpracy z dotychczasowym wykonawcą, zanim masz komplet dostępów i zweryfikowaną kopię zapasową. Nie przenoś hostingu w pierwszym tygodniu, bo migracja pod presją to najczęstsze źródło przestoju. Nie zaczynaj od nowych funkcji, tylko od stabilizacji. I nie zamawiaj prac bez środowiska testowego, nawet jeśli ktoś obiecuje, że „to drobna zmiana”.

Rozmowa z dotychczasowym dostawcą. Poproś na piśmie o dokumentację, listę środowisk, dostępy i informację o zaległych pracach. Nawet chłodne rozstanie zwykle kończy się przekazaniem materiałów, jeśli prośba jest konkretna i rzeczowa. Jeśli kontakt jest zerwany, audyt techniczny odtworzy większość obrazu z samego kodu, choć zajmie to więcej czasu.

W Waynet ten scenariusz przechodzimy regularnie, bo znaczna część sklepów pod naszą opieką trafiła do nas po innym wykonawcy. Start zaczyna się od audytu technicznego, a stabilizację i dalszy rozwój prowadzimy w ramach WayCare, gdzie SLA na incydenty wynosi poniżej 2 godzin, a monitoring działa 24/7. Pełny opis procesu znajdziesz w pytaniu jak wygląda przejęcie sklepu PrestaShop od innej agencji, a przed wyborem nowego partnera sprawdź czerwone flagi przy wyborze agencji.

Ani jedno, ani drugie nie jest bezpieczne samo z siebie. Moduł dedykowany daje pełną kontrolę nad kodem i mniejszą powierzchnię ataku, bo nie jest publicznie znany, ale jego bezpieczeństwo zależy wprost od jakości wykonawcy. Gotowy moduł z marketplace bywa lepiej przetestowany na tysiącach instalacji, ale wprowadza zależność od wydawcy, który może przestać go aktualizować.
Realne ryzyka gotowego rozszerzenia:

• Znane podatności. Popularny moduł jest publicznie opisany, więc luka w nim jest natychmiast skanowana masowo. To najczęstszy wektor ataku na sklepy PrestaShop, co pokazujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop, gdzie pierwszym punktem są niezałatane podatności CVE w modułach komercyjnych.
• Porzucenie przez wydawcę. Moduł bez aktualizacji od dwóch lat zostaje z Wami przy każdej kolejnej wersji PrestaShop.
• Nadmiarowe uprawnienia. Rozszerzenia często proszą o szerszy dostęp do danych, niż wymaga ich funkcja.

Realne ryzyka modułu dedykowanego:

• Brak zewnętrznego audytu. Kod widzi tylko wykonawca, więc błąd może żyć długo niezauważony.
• Bus factor. Jeśli moduł napisał jeden freelancer bez dokumentacji, utrzymanie po nim jest kosztowne.
• Aktualizacje na Was. Nikt nie wyda łatki za Was, gdy zmieni się rdzeń platformy.

Jak ocenić gotowy moduł przed instalacją, w pięciu krokach:

1. Data ostatniej aktualizacji i lista wspieranych wersji PrestaShop.
2. Historia zmian: czy wydawca reaguje na zgłoszenia bezpieczeństwa, czy tylko dodaje funkcje.
3. Zakres uprawnień i danych, do których moduł sięga.
4. Test na środowisku stagingowym, nigdy pierwsza instalacja na produkcji.
5. Plan wyjścia: co zrobicie, jeśli wydawca zniknie.

Kiedy funkcja wymaga rozwiązania dedykowanego: gdy dotyka danych osobowych lub płatności. Moduły płatnicze podlegają wymogom PCI DSS, a wszystko, co przetwarza dane klientów, podlega RODO, w tym obowiązkowi zgłoszenia naruszenia w 72 godziny. W takich obszarach kontrola nad kodem przestaje być wygodą i staje się wymogiem zgodności. Ten sam argument dotyczy integracji z ERP i magazynem, gdzie błąd nie tylko naraża dane, ale zatrzymuje sprzedaż.
Kiedy gotowy moduł w pełni wystarczy: funkcje standardowe i niekrytyczne, od wydawcy z aktualną historią zmian, przy sklepie z monitoringiem i aktualnymi kopiami zapasowymi. Trzecia droga, zwykle najbezpieczniejsza kosztowo: moduły autorskie agencji, która utrzymuje też Wasz sklep. Waynet rozwija katalog ponad 200 własnych modułów PrestaShop, aktualizowanych razem z platformą, a rozwiązania szyte na miarę realizujemy jako moduł PrestaShop na zamówienie. Zobacz też, jak wybrać między modułem dedykowanym a gotowym pod kątem kosztów i elastyczności oraz kto odpowiada za bezpieczeństwo sklepu PrestaShop.

Agencja ma sens, gdy nie macie w firmie programisty znającego PrestaShop, wdrożenie ma termin powiązany z sezonem sprzedażowym albo sklep od startu wymaga integracji z ERP i magazynem. Własny zespół wygrywa, gdy macie doświadczonych developerów, sklep jest rdzeniem biznesu i planujecie ciągły rozwój, a nie jednorazowy projekt. Przy zespole mieszanym najczęstszym błędem jest oddanie agencji wdrożenia bez ustalenia, kto utrzymuje sklep później.

Pięć kryteriów, które warto przyłożyć do własnej sytuacji:

1. 1. Budżet i jego struktura. Agencja to koszt projektowy, własny zespół to koszt stały. Rekrutacja i utrzymanie developera PrestaShop przez rok bywa droższa niż wdrożenie, ale przy ciągłym rozwoju proporcje się odwracają. Co realnie wpływa na wycenę, rozkładamy w tekście od czego zależy cena wdrożenia sklepu PrestaShop.
2. 2. Czas. Agencja startuje z gotowym zespołem i sprawdzonymi rozwiązaniami. Budowa kompetencji wewnętrznie to miesiące, a przy terminie powiązanym z sezonem zwykle nie ma tego zapasu.
3. 3. Kompetencje, ale te właściwe. Ogólne doświadczenie w PHP nie jest równe znajomości PrestaShop. Rdzeń, hooki i konflikty modułów to wiedza specyficzna, a jej brak generuje dług techniczny, którego skutki opisujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop.
4. 4. Plany rozwoju. Jednorazowe wdrożenie i potem drobne zmiany to argument za agencją. Roadmapa z ciągłymi wdrożeniami co tydzień to argument za własnym zespołem lub modelem mieszanym.
5. 5. Odpowiedzialność za stabilność. Kluczowe pytanie: kto odbierze telefon, gdy sklep przestanie sprzedawać w piątek wieczorem. Własny zespół oznacza dyżury, urlopy i ryzyko jednej osoby. Agencja z SLA oznacza zapisany czas reakcji.

Kiedy agencja nie jest potrzebna: mały sklep na gotowym szablonie, bez integracji, z prostym katalogiem i akceptowalnym ryzykiem kilkugodzinnego przestoju. Wtedy własna konfiguracja plus doraźna pomoc wystarczą. Kiedy warto oprzeć się na gotowych rozwiązaniach zamiast budować od zera, opisujemy w tekście o szybkim starcie z PrestaShop.

Trzeci wariant, najczęstszy w średnich firmach: model mieszany. Wasz zespół odpowiada za treści, marketing i procesy biznesowe, a partner zewnętrzny za kod, serwer i bezpieczeństwo. Tak działa WayCare: infrastruktura, monitoring 24/7, bezpieczeństwo i prace programistyczne w jednym abonamencie, z jednym punktem kontaktu i SLA poniżej 2 godzin. Samo wdrożenie w wariancie pakietowym opisuje WayBox, a klasyczne wdrożenie PrestaShop ma sens przy nietypowych wymaganiach. Zobacz też, jak wybrać agencję PrestaShop do stałej obsługi oraz czy lepiej mieć jednego partnera, czy kilku podwykonawców.

Kolejność ma znaczenie większe niż sam wybór narzędzi. Fundamentem są trzy rzeczy, bez których reszta nie ma sensu: przetestowane kopie zapasowe, środowisko testowe oddzielone od produkcji oraz monitoring, który wykrywa problem przed klientem. Dopiero na tym buduje się cache, CDN i zabezpieczenia aplikacyjne.

Hierarchia wdrożeń:

1. 1. Poziom zero, czyli odwracalność. Codzienne kopie zapasowe z przetestowanym odtworzeniem i środowisko testowe. Bez tego każda kolejna zmiana jest hazardem, a awaria oznacza godziny przestoju zamiast minut.
2. 2. Monitoring i alerty. Dostępność, wydajność i integralność plików. Reakcja ma zaczynać się od alertu, nie od telefonu klienta.
3. 3. Aktualizacje bezpieczeństwa. Rdzeń i moduły. Najczęstszym wektorem ataku jest nieaktualne rozszerzenie, co pokazujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop.
4. 4. Wydajność warstwy serwerowej. Konfiguracja pod PrestaShop i cache, czyli największy zysk przy najmniejszym nakładzie: konfiguracja serwera.
5. 5. Ochrona przed przeciążeniem i atakami. Zapora aplikacyjna i ochrona przed DDoS, opisane w tekście o strategii optymalizacji i ochrony sklepu PrestaShop.
6. 6. Optymalizacja aplikacji i bazy. Moduły, zapytania, obrazy, CDN dla zasobów statycznych.
7. 7. Testy obciążeniowe przed sezonem. Weryfikacja, czy całość wytrzyma planowany ruch.

Najczęstszy błąd w tej kolejności to inwestowanie w wydajność przy braku poziomu zero. Sklep szybki, ale bez kopii zapasowych i stagingu, potrafi stracić dzień sprzedaży na jednej nieudanej aktualizacji. Ile realnie kosztują takie decyzje, pokazuje analiza sześciu kosztownych awarii PrestaShop w Black Friday. W WayCare punkty od pierwszego do piątego są standardem umowy: środowiska produkcyjne i testowe, codzienne kopie zapasowe, monitoring techniczny 24/7, automatyczne testy End2End i SLA poniżej 2 godzin.

Zacznijcie od diagnozy przyczyny, nie od zakupu mocniejszego serwera. W sklepach, które zwalniają systematycznie (a nie tylko w szczytach), źródłem są zwykle cztery rzeczy: rosnąca baza danych bez indeksów i z zaległymi logami, narastająca liczba modułów, brak lub błędna konfiguracja cache oraz nieoptymalizowane obrazy. Dopiero po pomiarze wiadomo, które z nich kosztuje Was najwięcej.

Dlaczego to pilne: spowolnienie działa na sprzedaż podwójnie, przez porzucone koszyki i przez pozycje w wyszukiwarce. Mechanizm i sposób liczenia strat opisujemy w tekście o niskim współczynniku konwersji.

Kolejność działań:

1. 1. Pomiar i wskazanie wąskiego gardła. Profilowanie najwolniejszych podstron, analiza wolnych zapytań, sprawdzenie czasu odpowiedzi serwera oddzielnie od czasu renderowania. Metodę opisujemy w tekście o audycie i diagnostyce PrestaShop.
2. 2. Baza danych. Indeksy, analiza slow logów, oczyszczenie tabel, które rosną w tle latami. Szczegóły: jak zoptymalizować bazę danych PrestaShop.
3. 3. Warstwa aplikacji. Cache, przegląd modułów, usunięcie nieużywanych rozszerzeń i nadpisań rdzenia. Szerzej: konfiguracja cache w PrestaShop.
4. 4. Serwer i dostarczanie treści. Konfiguracja pod PrestaShop, cache po stronie serwera, CDN dla zasobów statycznych. Zobacz konfigurację serwera PrestaShop, rolę CDN oraz wdrożenie Vinyl Cache, dawniej Varnish.
5. 5. Dowód poprawy. Test obciążeniowy przed i po zmianach pokazuje, czy efekt jest realny, i przy jakim ruchu sklep nadal usiądzie: testy wydajnościowe PrestaShop.
6. 6. Odporność na szczyt ruchu. Ruch botów i ataki wolumetryczne obciążają sklep tak samo jak realni klienci, a awarie w szczycie sprzedaży powtarzają się według kilku stałych scenariuszy. Zobacz ochronę PrestaShop przed DDoS oraz kosztowne awarie PrestaShop w szczycie sprzedaży.

Zanim skontaktujecie się z wykonawcą, zbierzcie cztery informacje: wersję PHP i PrestaShop, stan cache (czy jest włączony i jaki), listę modułów dodanych lub zaktualizowanych w ostatnich tygodniach oraz wpisy z logu błędów z okresu spowolnienia. Przydatna jest też informacja, czy zwalnia cały sklep, czy konkretne widoki, na przykład listing kategorii albo koszyk. Z tymi danymi diagnoza zaczyna się od razu, zamiast od godziny zbierania kontekstu, a to realnie skraca czas naprawy.

Jeżeli sklep rośnie, jednorazowa optymalizacja nie wystarczy, bo wydajność degraduje się z każdym nowym modułem i przyrostem danych. Dlatego warto połączyć jednorazowe usprawnienia z ciągłym monitoringiem. Zakres prac naprawczych opisuje strona optymalizacji PrestaShop, punktem wyjścia jest audyt techniczny, samo wdrożenie warstwy cache i reverse proxy realizujemy jako optymalizację wydajności PrestaShop pod klucz, a stały monitoring wydajności wchodzi w WayCare.

Terminowość projektu modułowego zależy od trzech rzeczy ustalonych przed startem: rozbicia prac na etapy z osobnymi terminami odbioru, pisemnej specyfikacji funkcjonalnej zamiast ustaleń z rozmowy oraz jasnej procedury zmian w zakresie. Agencja, która wycenia rozbudowany moduł jedną kwotą i jednym terminem, bez pytań o Wasze procesy, właśnie zapowiedziała opóźnienie.

Kompetencje techniczne, które realnie odróżniają dobrego wykonawcę:

• 1. Praca na hookach, nie na nadpisaniach rdzenia. Moduł oparty na nadpisaniach blokuje przyszłe aktualizacje PrestaShop i konfliktuje z innymi rozszerzeniami. Skutki opisujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop.
• 2. Kompatybilność wersji. Zapytajcie wprost, na jakich wersjach moduł będzie testowany i co się stanie przy aktualizacji sklepu.
• 3. Własny katalog modułów. Agencja z gotowymi, utrzymywanymi rozwiązaniami rzadziej pisze od zera, więc dostarcza szybciej.

Elementy, które trzymają harmonogram:

1. 4. Specyfikacja przed kodowaniem. Opis zachowania funkcji, przypadków brzegowych i kryteriów odbioru. Brak specyfikacji to główna przyczyna „to nie tak miało działać” na końcu projektu.
2. 5. Etapy z odbiorami. Zamiast jednego terminu na całość, trzy lub cztery kamienie milowe, które widzicie działające.
3. 6. Procedura zmian. Każda zmiana zakresu w trakcie ma osobną estymatę i decyzję, czy wchodzi teraz, czy po odbiorze.
4. 7. Obowiązki po Waszej stronie. Opóźnienia często wynikają z braku decyzji lub danych testowych u zamawiającego. Ustalcie, kto i w jakim czasie odpowiada.
5. 8. Testy i wsparcie po wdrożeniu. Ustalcie okres, w którym poprawki błędów są w cenie.

Portfolio weryfikujcie konkretem: nie „tworzymy moduły”, ale jaki moduł, do jakiego procesu, w jakiej skali sklepu. Waynet utrzymuje katalog ponad 200 własnych modułów PrestaShop, co skraca czas realizacji, bo część funkcji jest już napisana i przetestowana. Zakres pracy nad rozwiązaniami szytymi na miarę opisuje strona modułu PrestaShop na zamówienie. Zobacz też, czy w Waszym przypadku lepszy będzie moduł dedykowany, czy gotowy z marketplace oraz jakie czerwone flagi wykluczają agencję.

Najpoważniejsze czerwone flagi to: brak SLA na piśmie, brak środowiska testowego, anonimowe realizacje bez nazw klientów, niejasne prawa do kodu oraz unikanie odpowiedzi na pytanie, kto odpowiada za serwer. Każda z nich oznacza, że ryzyko przestoju przenosi się na Was, a nie na wykonawcę.

Lista ostrzeżeń, które warto sprawdzić przed umową:

• 1. SLA tylko w rozmowie. Jeśli czasy reakcji nie są w umowie, nie istnieją. Punkt odniesienia: jaki czas reakcji na awarię PrestaShop jest realny.
• 2. Wdrożenia prosto na produkcję. Brak stagingu oznacza, że każdą zmianę testują Wasi klienci.
• 3. Brak procedury awaryjnej. Pytanie „co robicie, gdy sklep przestaje sprzedawać o 22 w piątek” powinno mieć konkretną odpowiedź, nie ogólnik o dostępności.
• 4. Anonimowe portfolio. Realizacje bez nazw i zakresu prac są nieweryfikowalne.
• 5. Niejasne prawa do kodu i dostępów. Ustalcie to na starcie, bo przy rozstaniu bywa to narzędzie nacisku.
• 6. Rozmyta odpowiedzialność za hosting. Podział „my kod, ktoś inny serwer” kończy się sporem o przyczynę przy każdej awarii.
• 7. Wycena bez pytań. Oferta na rozbudowany sklep przygotowana bez audytu i bez pytań o integracje to najczęstsza zapowiedź niedoszacowania.
• 8. Brak raportowania. Poproście o przykładowy raport miesięczny, a nie o obietnicę raportowania.

Odwrotność tej listy to zestaw pytań do rozmowy kwalifikacyjnej z agencją: zobacz jakie pytania zadać agencji przed podpisaniem umowy oraz jak wybrać agencję PrestaShop do stałej obsługi. Dobrą praktyką jest też sprawdzenie stabilności samej firmy: statusu partnera PrestaShop, stażu i publikowanych case studies.

Zmianę wykonawcy zaczyna się od diagnozy, gdzie realnie tracicie czas: w wycenach, w kolejce zadań, w testach czy w komunikacji. Potem przygotowujecie brief z listą zaległych prac i porównujecie oferty według tempa i sposobu rozliczenia, a nie tylko stawki godzinowej. Sama zmiana partnera nie przyspieszy wdrożeń, jeśli powtórzycie ten sam model współpracy.

Proces w czterech krokach:

1. 1. Diagnoza opóźnień. Zmierzcie, ile czasu mija od zgłoszenia potrzeby do wdrożenia i na którym etapie zadanie stoi najdłużej. To ustala punkt odniesienia dla nowego partnera.
2. 2. Brief zamiast listy życzeń. Zaległe prace, planowane integracje, znane problemy techniczne, oczekiwane tempo. Im konkretniej, tym trafniejsze wyceny i mniejsze ryzyko niedoszacowania.
3. 3. Porównanie ofert według tempa i modelu rozliczeń. Pytajcie o pulę godzin w miesiącu, długość sprintu, termin startu i sposób raportowania. Niska stawka przy wolnym tempie bywa droższa niż wyższa stawka przy przewidywalnych dostawach. Na co jeszcze wpływa wycena, piszemy w tekście od czego zależy cena wdrożenia sklepu PrestaShop.
4. 4. Bezpieczne przejęcie. Audyt otwierający, przekazanie dostępów i dokumentacji, uruchomienie monitoringu. Cały proces opisuje pytanie jak wygląda przejęcie sklepu PrestaShop od innej agencji.

Kontrola budżetu wynika z modelu, nie z obietnic: ustalona pula godzin, zatwierdzanie estymat przed startem zadania i miesięczny raport wykonanych prac. Zakres, który realizujemy w tym trybie, opisuje strona opieki technicznej z hostingiem 24/7 WayCare, a punktem wyjścia jest zwykle audyt techniczny.

Kompetencję w integracjach weryfikuje się procesem, nie deklaracją. Zapytaj o cztery rzeczy: czy pracują na środowisku testowym odwzorowującym produkcję, jak testują regresję przed wdrożeniem, czy mają procedurę wycofania zmian oraz jak monitorują integrację po starcie. Agencja, która nie ma odpowiedzi na te pytania, będzie testować na Waszym sklepie.

Osiem punktów do rozmowy:

1. 1. Staging. Czy istnieje środowisko testowe z realistycznym wolumenem danych, czy zmiany idą prosto na produkcję?
2. 2. Testy regresyjne. Co dokładnie sprawdzają przed wdrożeniem: koszyk, płatności, dostawy, synchronizację stanów?
3. 3. Rollback. Ile trwa powrót do poprzedniej wersji i czy był kiedykolwiek przeprowadzony w praktyce?
4. 4. Okno wdrożeń. Czy zmiany wchodzą poza szczytem ruchu i kto to decyduje?
5. 5. Doświadczenie z konkretnym systemem. Nie „integrujemy z ERP”, ale „integrowaliśmy z tym systemem, w tej wersji, w tej skali”.
6. 6. Architektura. Czy proponują model asynchroniczny z kolejką, czy synchroniczne wywołania w ścieżce zakupowej? Szerzej: jak zaprojektować integrację odporną na obciążenie.
7. 7. Monitoring po starcie. Kto dostaje alert, gdy synchronizacja stanie w środku kampanii, i w jakim czasie reaguje?
8. 8. Odpowiedzialność za serwer. Jeśli hosting jest u kogoś innego, przy awarii integracji zaczyna się spór o przyczynę.

Dowód kompetencji to case study o porównywalnej złożoności, nie lista logotypów. Przykłady wdrożeń z integracjami ERP i wielorynkowością znajdziesz w branżowych case studies, a przegląd funkcji i integracji w rozbudowanych wdrożeniach B2B w tekście o 40 funkcjonalnościach PrestaShop B2B. W Waynet integracje, sklep i opiekę i hosting z opieką 24/7 WayCare prowadzi jeden zespół.

Zacznij od diagnozy, nie od przebudowy. W integracjach, które działają na małym ruchu, a sypią się przy dużym, przyczyna prawie zawsze mieści się w jednym z czterech miejsc: pełna synchronizacja uruchamiana w godzinach sprzedaży, wywołania ERP w krytycznej ścieżce zakupowej, brak limitów czasu na zewnętrzne API oraz zapytania do bazy bez indeksów na tabelach synchronizacji.

Kolejność działań, która daje efekt najszybciej:

1. 1. Znajdź wąskie gardło pomiarem, nie intuicją. Zbierz logi błędów, czasy odpowiedzi ERP i wolne zapytania bazy z okresu awarii. Metodę opisujemy w tekście o audycie i diagnostyce PrestaShop.
2. 2. Przenieś ciężkie operacje poza godziny szczytu i zamień pełne synchronizacje na przyrostowe. To zwykle najtańsza zmiana z największym efektem.
3. 3. Wyjmij ERP z krytycznej ścieżki. Zamówienie ma zostać przyjęte nawet wtedy, gdy ERP nie odpowiada; przekazanie realizuje proces w tle.
4. 4. Dodaj limity czasu i ponawianie na każde wywołanie zewnętrzne, żeby jedno zawieszone połączenie nie zajmowało zasobów serwera.
5. 5. Popraw bazę. Tabele mapowań i logów synchronizacji zwykle rosną bez indeksów i po latach same stają się wąskim gardłem. Zobacz jak zoptymalizować bazę danych PrestaShop.
6. 6. Potwierdź poprawę testem obciążeniowym przed kolejnym szczytem, a nie w jego trakcie. Jak to zrobić: testy wydajnościowe PrestaShop przed i po Black Week.

Jeśli integracja była budowana przez kilku wykonawców, warto równolegle sprawdzić dług techniczny wokół niej: równoległe klucze API i nieudokumentowane nadpisania rdzenia to częste znaleziska, które opisujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop. Punktem wyjścia jest audyt techniczny, a stabilizację i utrzymanie prowadzimy w ramach integracji PrestaShop i stałej opieki technicznej WayCare.