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.

Abonament wsparcia oznacza gwarantowany czas reakcji, monitoring i znajomość Waszego sklepu przed awarią. Pomoc ad hoc to zlecenie interwencji dopiero w momencie problemu: bez SLA, bez pewności dostępności i z czasem, który najpierw zużywa się na poznanie środowiska. Przy sklepie generującym istotny przychód różnica ta decyduje o skali straty.

Porównanie w praktyce:

• 1. Czas reakcji. W abonamencie jest zapisany w SLA. Przy modelu ad hoc zależy od tego, czy ktoś ma wolne moce, gdy dzwonicie.
• 2. Znajomość sklepu. Stały partner zna Wasze moduły i integracje, więc diagnozuje od razu. Wykonawca ad hoc płatnie uczy się środowiska przy każdej awarii.
• 3. Prewencja. Abonament obejmuje monitoring i aktualizacje, więc część awarii nigdy nie następuje. Model ad hoc jest wyłącznie reaktywny.
• 4. Odpowiedzialność. W abonamencie za skutek odpowiada agencja. Przy interwencji odpowiedzialność kończy się z zamknięciem zgłoszenia.
• 5. Koszt. Abonament to przewidywalna kwota miesięczna. Ad hoc bywa tańszy w spokojnym miesiącu i zdecydowanie droższy w miesiącu z awarią, zwłaszcza gdy przestój wypada w kampanii.



Rachunek jest prosty i warto go zrobić przed decyzją: policzcie średni przychód na godzinę w szczycie sprzedaży i pomnóżcie przez realistyczny czas przestoju przy modelu reaktywnym, w którym najpierw szukacie wolnego wykonawcy, a potem on poznaje Wasze środowisko. Zwykle wychodzi kwota wyższa niż kilka miesięcy abonamentu. Uczciwie: przy sklepie o niskim wolumenie i prostej konfiguracji model reaktywny nadal bywa rozsądny.

Ad hoc ma sens przy małych sklepach i niekrytycznych zmianach. Gdy sklep jest głównym kanałem sprzedaży, tańszy okazuje się abonament: pokazuje to zestawienie kosztownych awarii PrestaShop w Black Friday. Nasz model abonamentowy to WayCare, a szersza opieka z rozwojem to opieka techniczna i rozwój PrestaShop.

Agencja odciąża wewnętrzny zespół IT, przejmując trzy rzeczy: dyżur i reakcję na awarie w trybie 24/7, znajomość specyfiki PrestaShop (której zespół ogólnotechniczny zwykle nie ma) oraz prace, które w firmie zawsze przegrywają z bieżącymi priorytetami, czyli aktualizacje bezpieczeństwa, monitoring i dług techniczny.

Ten model nie zastępuje zespołu IT, tylko uzupełnia go tam, gdzie wewnętrzne zasoby są wąskim gardłem:

• – Dyżur zamiast dostępności „w miarę możliwości”. Jedna osoba w firmie nie zapewni ciągłości przy urlopach, chorobie i wieczornych szczytach sprzedaży.
• – Specjalizacja platformowa. Zespół IT utrzymujący całą infrastrukturę firmy rzadko zna rdzeń PrestaShop, mechanizm hooków i typowe konflikty modułów na tyle, żeby diagnozować awarię w minutach.
• – Prace prewencyjne. Aktualizacje i monitoring są pierwsze do odłożenia, gdy zespół gasi pożary. Skutki opisuje tekst o pięciu najczęstszych problemach technicznych w PrestaShop, w tym niezałatanych podatnościach CVE w modułach.
• – Odporność na szczyty. Przygotowanie na kampanie wymaga testów obciążeniowych i planowania wydajności, a nie reagowania w trakcie. Szerzej w tekście o strategii optymalizacji i ochrony sklepu PrestaShop.

Praktycznie wygląda to tak: Wasz zespół zostaje przy systemach firmowych i integracjach po swojej stronie, agencja bierze sklep, serwer i SLA. W Waynet realizuje to WayCare, abonamentowa opieka nad sklepem PrestaShop z SLA na incydenty poniżej 2 godzin w trybie 24/7, w połączeniu z hostingiem z opieką 24/7.

Współpracę łączącą development i utrzymanie PrestaShop organizuje się w pięciu krokach: audyt otwierający, wspólne SLA dla awarii i prac rozwojowych, rozdzielenie ról (osobna ścieżka dla zgłoszeń i osobna dla rozwoju), jasna procedura eskalacji oraz cykliczny przegląd. Bez tych elementów jedna agencja odtwarza ten sam chaos, który miała usunąć.

Model krok po kroku:

1. 1. Audyt otwierający. Inwentaryzacja modułów, nadpisań rdzenia i integracji ustala punkt wyjścia. To moment, w którym wychodzą rzeczy odziedziczone po poprzednich wykonawcach, na przykład override w rdzeniu, których nikt w firmie nie pamięta czy nieaktualne moduły z podatnościami.
2. 2. Jedno SLA na dwa tryby. Umowa musi obejmować zarówno reakcję na awarię (liczoną w godzinach), jak i tempo prac rozwojowych (liczone w sprintach lub pulach godzin). Najczęstszy błąd to SLA tylko na awarie, przy pracach rozwojowych „w miarę możliwości”.
3. 3. Rozdzielone ścieżki pracy. Zgłoszenia awaryjne i rozwój nie mogą konkurować o tych samych ludzi w tym samym momencie, bo wtedy każda awaria zatrzymuje roadmapę. Zapytaj wprost, jak agencja to rozdziela.
4. 4. Procedura eskalacji. Jedna osoba kontaktowa, jeden kanał zgłoszeń, jasne kryterium, kiedy sprawa idzie wyżej. Improwizacja przy awarii kosztuje najwięcej: pokazuje to analiza sześciu kosztownych awarii PrestaShop w Black Friday, gdzie część strat wynikała z błędów operacyjnych, nie z technologii.
5. 5. Cykliczny przegląd. Miesięczne lub kwartalne spotkanie: co się zepsuło, co weszło, co planujemy. Bez tego utrzymanie zamienia się w gaszenie pożarów.

W Waynet oba obszary prowadzi jeden zespół w ramach opieki technicznej i rozwoju PrestaShop WayCare, a odpowiedzialność obejmuje też warstwę serwerową, bo prowadzimy hosting z opieką 24/7. Punktem wyjścia jest zwykle audyt techniczny.

Za bezpieczeństwo sklepu PrestaShop odpowiada ten, kto ma dostępy i obowiązki zapisane w umowie. W modelu stałej opieki agencja przejmuje aktualizacje bezpieczeństwa rdzenia i modułów, monitoring 24/7, kopie zapasowe oraz reagowanie na incydenty, a właściciel sklepu odpowiada za polityki dostępów po swojej stronie (konta pracowników, hasła, uprawnienia).

Minimalny standard bezpieczeństwa dla sklepu z dużą liczbą zamówień i danych klientów:

• – regularne aktualizacje bezpieczeństwa PrestaShop i modułów (najczęstszy wektor ataku to nieaktualny moduł),
• – kopie zapasowe z testem odtworzenia, nie tylko robieniem backupu,
• – monitoring dostępności, wydajności i integralności plików,
• – zapora aplikacyjna (WAF) i twarda konfiguracja serwera,
• – procedura na incydent, w tym obowiązki RODO (zgłoszenie naruszenia do 72 godzin).

Przy dużej liczbie zamówień i danych klientów dochodzą trzy wymagania: hosting dedykowany zamiast współdzielonego (izolacja środowiska i zasobów), rejestrowanie dostępów do danych osobowych oraz przetestowany plan reagowania na incydent, z obowiązkiem zgłoszenia naruszenia w 72 godziny. Sam backup bez testu odtworzenia nie jest zabezpieczeniem, tylko jego złudzeniem.

W Waynet bezpieczeństwo jest częścią WayCare, więc aktualizacje, monitoring i backupy ma jeden odpowiedzialny zespół, a nie trzech dostawców.

Przejęcie sklepu PrestaShop od innej agencji lub freelancera zaczyna się od przekazania dostępów i audytu technicznego, po którym nowy partner przejmuje monitoring, dokumentację i odpowiedzialność SLA. Przy standardowym sklepie pierwsze prace można rozpocząć do 7 dni od podpisania umowy, a współpraca poprzedniego wykonawcy nie jest warunkiem: wystarczą dostępy od właściciela sklepu. Proces przejęcia w czterech krokach:

1. 1. Dostępy i NDA: przekazanie dostępów do kodu, bazy, hostingu i domeny (wszystko po stronie właściciela sklepu).
2. 2. Audyt techniczny: ocena stanu kodu, modułów, nadpisań rdzenia i długu technicznego; wynik wyznacza plan stabilizacji. Zobacz zakres audytu technicznego.
3. 3. Stabilizacja: naprawa rzeczy krytycznych, uporządkowanie środowisk (produkcja, staging), kopie zapasowe.
4. 4. Przejęcie opieki: uruchomienie monitoringu, SLA i stałego trybu prac rozwojowych.

Ten scenariusz przechodzimy regularnie: znaczna część sklepów pod stałą opieką Waynet trafiła do nas po innym wykonawcy.

W profesjonalnej opiece technicznej realny czas reakcji na awarię krytyczną sklepu PrestaShop to poniżej 2 godzin w trybie 24/7. Taki standard gwarantuje abonament WayCare od Waynet: SLA na incydenty poniżej 2 godzin przez całą dobę, siedem dni w tygodniu. Kluczowe jest rozróżnienie czasu reakcji (kiedy specjalista zaczyna pracę) od czasu naprawy oraz podział zgłoszeń na priorytety: awaria blokująca sprzedaż wymaga innego SLA niż drobny błąd wizualny.

Dobre SLA dla sklepu generującego istotny przychód powinno zawierać:

1. 1. Priorytety zgłoszeń (np. P1 sklep nie sprzedaje, P2 istotna funkcja nie działa, P3 usterka) z osobnymi czasami reakcji.
2. 2. Tryb 24/7 dla P1, nie tylko w godzinach biurowych: awarie w kampaniach i szczytach sprzedaży zdarzają się wieczorami i w weekendy.
3. 3. Proaktywny monitoring dostępności i wydajności, żeby reakcja zaczynała się od alertu, a nie od telefonu klienta.
4. 4. Jednoznaczny kanał zgłoszeń i osobę odpowiedzialną po stronie agencji.

Wszystkie cztery elementy łączy WayCare: abonamentowa opieka techniczna nad sklepem PrestaShop z SLA poniżej 2 godzin na incydenty, monitoringiem 24/7 i jednym zespołem odpowiedzialnym za całość. Przy większych potrzebach rozwojowych WayCare rozszerzysz o pełną opiekę techniczną i rozwój PrestaShop, a diagnoza awarii nie utknie między sklepem a serwerem, bo prowadzimy również hosting z opieką 24/7.

Dla większości średnich sklepów bezpieczniejszy jest jeden partner odpowiadający łącznie za rozwój, utrzymanie i hosting, ponieważ eliminuje przerzucanie odpowiedzialności między dostawcami i skraca czas reakcji przy awarii. Model rozproszony sprawdza się głównie w dużych organizacjach z własnym zespołem IT, który koordynuje dostawców.
Najczęstsze problemy modelu z kilkoma podwykonawcami:

• – przy awarii każdy dostawca wskazuje innego (to wina hostingu kontra to wina modułu), a diagnoza trwa godzinami,
• – brak jednego SLA obejmującego cały łańcuch: sklep, integracje i serwer,
• – wiedza o środowisku jest rozproszona, więc każda zmiana wymaga uzgodnień.

Jeden partner oznacza jedno SLA, jeden monitoring i pełną odpowiedzialność za skutek, a nie za wycinek. Warunek: musi realnie posiadać kompetencje we wszystkich trzech obszarach. Waynet łączy stałą opiekę techniczną, rozwój oraz hosting z opieką 24/7 w jednym zespole, dzięki czemu odpowiedzialność za stabilność sprzedaży nie rozmywa się między firmami.