Utrzymanie i opieka techniczna sklepu – co to właściwie znaczy

Wdrożenie kończy się w momencie odbioru, opieka zaczyna się następnego dnia. To dwie różne usługi. Wdrożenie rozliczasz za efekt: zakres, termin, faktura. Opiekę rozliczasz za czas i proces – płacisz nie za naprawę, gdy coś się zepsuje, ale za to, żeby się nie zepsuło.

W opiece działają dwa tryby pracy. Reaktywny to gaszenie pożarów: sklep nie odpowiada, płatności nie przechodzą, ktoś zgłasza błąd 500. Proaktywny to działania wykonywane bez zgłoszenia: kopie, aktualizacje, przeglądy logów, testy integracji. Abonament zawierający wyłącznie tryb reaktywny jest ubezpieczeniem, nie opieką – kupujesz obietnicę, że ktoś odbierze telefon, ale nikt nie sprawdza, czy kopia zapasowa da się odtworzyć.

Trzy filary opieki nad sklepem:

• Bezpieczeństwo – sklep jest publicznie dostępny, więc boty skanują go codziennie; chodzi o to, żeby nieudany atak nie skończył się wyciekiem bazy klientów.
• Dostępność – awarię ma wykryć monitoring w minutach, a nie klient, który nie może dokończyć zakupu.
• Wydajność – liczy się czas ładowania na telefonie klienta, mierzony na realnym ruchu, nie „wygląda szybko” – punkt odniesienia opisuje dokumentacja Web Vitals.

Zanim podpiszesz umowę, ustal granicę odpowiedzialności:

Co wchodzi w zakres opieki technicznej sklepu – konkretna lista

To minimum, o które warto zapytać każdego wykonawcę. Brak punktu w ofercie nie znaczy, że usługa jest zła – znaczy, że ten element nie jest objęty i spadnie na Ciebie albo będzie płatny dodatkowo.

• Kopie zapasowe – baza co 24 h, w szczycie sezonu co 6–12 h; pliki co 24 h; przechowywanie poza serwerem produkcyjnym (inny dostawca, storage typu S3); retencja 14–30 dni. Raz na kwartał kopia musi być odtworzona na środowisku testowym. Kopia, której nikt nie odtworzył, nie jest kopią – jest plikiem, o którym nic nie wiesz.
• Aktualizacje – rdzeń sklepu, wtyczki i moduły, motyw, wersja PHP i MySQL. W oknie serwisowym (typowo 2:00–5:00), zawsze z kopią przed zmianą i na stagingu, jeśli istnieje. Zgodność wersji PHP z aplikacją sprawdza się w dokumentacji producenta – dla PrestaShopu wymagania opisuje dokumentacja dla deweloperów PrestaShop.
• Test integracji płatności i kurierów po każdej aktualizacji – Przelewy24/PayU, InPost, DPD, DHL. To najczęstsze źródło cichych awarii: sklep działa, klient widzi koszyk, ale moduł kuriera nie zwraca listy paczkomatów. Test to zamówienie próbne na produkcji plus wygenerowanie etykiety.
• Monitoring dostępności – co 1–5 minut, alert e-mailem i SMS-em (e-mail w nocy poczeka do rana), kontrola certyfikatu SSL z wyprzedzeniem 14–30 dni, sprawdzanie kodów odpowiedzi HTTP i przejścia przez proces zamówienia.
• Przegląd logów raz w miesiącu – błędy PHP, slow query log MySQL, rozmiar i indeksy bazy, tabele nadmiarowe: porzucone koszyki, sesje, logi.
• Porządki bezpieczeństwa – usuwanie nieużywanych wtyczek i motywów, konta administratora imienne zamiast wspólnego „admin”, 2FA, blokada XML-RPC, limit prób logowania, wyłączenie wyświetlania błędów na produkcji.

Dobrą ofertę poznasz po raporcie: dostajesz zapis, co i kiedy wykonano, a nie tylko fakturę.

SLA w opiece nad sklepem: czas reakcji to nie czas naprawy

Większość sporów o opiekę wynika z jednego nieporozumienia: klient czyta „czas reakcji 2 h” jako „naprawa w 2 h”. To trzy różne parametry.

• Czas reakcji – potwierdzenie zgłoszenia i start diagnozy. Nie oznacza, że ktokolwiek wie, co się stało.
• Czas obejścia problemu – przywrócenie sprzedaży w jakiejkolwiek działającej formie, np. wyłączenie wadliwego modułu.
• Czas pełnego rozwiązania – usunięcie przyczyny i weryfikacja, że problem nie wróci.

Realne poziomy to 2 h, 4 h i 1 dzień roboczy. Skrócenie z jednego dnia na 2 h zmienia wszystko w jednym scenariuszu: zgłoszenie z piątku 16:30 przy reakcji jednego dnia roboczego czeka do poniedziałku, czyli przez cały weekend sklep nie sprzedaje.

Godziny wsparcia to osobny parametr i osobna pozycja w cenie. Wariant 8–16 kosztuje najmniej, ale nie obejmuje wieczornego szczytu. Wariant 8–20 pokrywa realny ruch w polskim e-commerce. 24/7 ma sens głównie przy sprzedaży zagranicznej lub sklepie B2B z zamówieniami całodobowymi – w pozostałych przypadkach to przerost formy; taniej wychodzi 8–20 plus zapis o dyżurze telefonicznym w tygodniach szczytu.

SLA nie obejmuje rozwoju nowych funkcji, pracy na treściach i danych klienta oraz awarii po stronie dostawcy hostingu – te sytuacje muszą być wymienione wprost, z procedurą eskalacji do dostawcy.

Zgłoszenia: jeden kanał to jedno miejsce prawdy, np. helpdesk albo wspólny adres e-mail z numeracją spraw. Telefon rezerwuj dla spraw krytycznych, w których sklep nie sprzedaje. Zgłoszenia z czatu, SMS-a i telefonu rozproszone po trzech osobach to gwarancja, że coś zniknie.

Rabaty za przekroczenie SLA formułuj tak, żeby były wykonalne: np. 5% miesięcznej opłaty za każde rozpoczęte 60 minut zwłoki w czasie reakcji, maksymalnie 50% opłaty, naliczane automatycznie na fakturze, bez konieczności upominania się. Koniecznie z wyłączeniami: zgłoszenie poza godzinami wsparcia, oczekiwanie na informację od klienta, awaria po stronie hostingu. Rabat symboliczny, np. 50 zł, lepiej wykreślić – nie zmienia zachowania wykonawcy.

Jak wygląda to w praktyce przy sklepach sezonowych, opisujemy w materiale o utrzymaniu i opiece technicznej sklepów Zamość.

Ile kosztuje utrzymanie sklepu: model godzinowy, ryczałt i widełki

Pytanie „ile to kosztuje” da się rozbić na trzy modele rozliczeń. Każdy ma inną logikę i inne ryzyko.

• Model godzinowy (praca serwisowa). Płacisz za faktycznie przepracowane godziny, rozliczane co do minuty. Standardowe prace nad PrestaShop i WooCommerce w firmach z segmentu MŚP to zwykle 150–250 zł netto/h; gdy wchodzą integracje z ERP, magazynem albo API kurierów – 250–400 zł netto/h. Opłaca się przy stabilnym sklepie i rzadkich zdarzeniach. Nie opłaca się, gdy potrzebujesz kogoś „na telefon” – wtedy każdy telefon kosztuje.
• Ryczałt miesięczny. Stała kwota za zdefiniowany zakres: monitoring, kopie, aktualizacje bezpieczeństwa, budżet zgłoszeń i czas reakcji. Prosty sklep: 300–800 zł netto/mies. Sklep z płatnościami, kilkoma kurierami i integracją magazynową: 1000–3000 zł netto/mies. Opłaca się wtedy, gdy realnie potrzebujesz czasu reakcji – nie wtedy, gdy przez pół roku nie było ani jednego zgłoszenia.
• Pakiet godzin z rozliczeniem minutowym. Kupujesz z góry 5, 10 lub 20 godzin na miesiąc. Stawka jest niższa niż w modelu ad hoc, ale sprawdź, czy niewykorzystane godziny przechodzą na kolejny okres i na ile miesięcy – najczęściej na 1–3, potem przepadają.

Koszt podnoszą: liczba integracji (ERP, magazyn, kurierzy, płatności), moduły pisane na zamówienie, liczba języków i walut oraz szczyt sezonowy, w którym godzina pracy jest droższa i trudniej dostępna. Koszt obniżają: jeden własny moduł zamiast trzech płatnych wtyczek robiących to samo, stabilny hosting, uporządkowana baza i brak „zombie modułów” po wyłączonych funkcjach.

Czytając ofertę, sprawdź trzy rzeczy: ile godzin realnie zawiera pakiet (nie „nielimitowane wsparcie”, tylko liczba), co dzieje się z niewykorzystanymi godzinami i czy audyt startowy jest płatny osobno (zwykle 200–800 zł netto). Budżet trzymaj w czterech osobnych pozycjach: opieka techniczna, licencje i wtyczki, hosting, certyfikaty SSL. Jedna kwota „za wszystko” uniemożliwia porównanie dwóch ofert.

Sklep w Krasnobrodzie i na Roztoczu: sezonowość, ruch turystyczny, lokalny wykonawca

Sklep z produktami regionalnymi w Krasnobrodzie i okolicach żyje inaczej niż sklep całoroczny. Ruch rośnie od maja i trzyma się do września, a szczyty wypadają w weekendy i długie weekendy – liczba sesji potrafi wzrosnąć kilkukrotnie w ciągu dwóch, trzech dni. To nie problem, dopóki infrastruktura jest na to przygotowana.

Dlatego test obciążeniowy robimy w kwietniu, nie w lipcu. Na kopii sklepu na środowisku testowym (k6, Locust albo prosty ab) sprawdzamy, ile równoczesnych sesji wytrzymuje dodawanie do koszyka i podsumowanie zamówienia, a przy okazji patrzymy na wyniki mobilne – turysta szuka produktu w terenie, na słabym zasięgu. Metryki opisane w materiałach o Web Vitals pokazują, co realnie odczuwa klient, a nie tylko co wygląda dobrze w panelu.

Luty–marzec to okno na prace planowane: aktualizacje PrestaShop i WooCommerce, sprzątanie bazy (porzucone koszyki, tabele statystyk, logi), testy płatności i modułów kurierskich, przegląd stref dostawy. Sklep sprzedający wysyłkowo poza region musi mieć poprawnie ustawione strefy, punkty odbioru i koszt przesyłki dla odbiorcy spoza Roztocza – inaczej dopłaca do dostawy z własnej marży.

Listopad–styczeń to drugi szczyt: Black Friday i święta. Zmiany w kodzie zamrażamy 10 dni przed startem promocji – wdrażamy wyłącznie poprawki bezpieczeństwa.

Osobna kwestia to wykonawca z tej samej strefy czasowej. Ktoś z Zamościa lub Lublina ustala okno serwisowe na konkretne godziny, odbiera telefon w środku sezonu i przy krytycznej awarii przyjmuje kontekst głosem, a nie przez formularz. Jak to wygląda w praktyce, opisujemy przy okazji opieki technicznej nad sklepami w Zamościu oraz utrzymania i opieki nad sklepami w Zwierzyńcu.

Jak wygląda miesiąc opieki technicznej krok po kroku

Rytm opieki powinien być widoczny w raportach. Jeśli wykonawca nie potrafi pokazać, co robił w danym miesiącu, to nie opieka, tylko dostęp do panelu.

Start (pierwsze 1–2 tygodnie): audyt techniczny, inwentaryzacja modułów i wtyczek (nazwa, wersja, autor, data ostatniej aktualizacji, zgodność z wersją PHP), przejęcie dostępów – panel, SFTP, baza, rejestrator domeny, hosting, konta płatności, Search Console – oraz dokumentacja stanu wyjściowego, czyli zapis, co było zepsute jeszcze przed przejęciem. Przy zgodności modułów z kolejnymi wersjami PrestaShop pomaga dokumentacja deweloperska PrestaShop.

Co tydzień: przegląd alertów monitoringu, obsługa zgłoszeń w ramach ustalonego czasu reakcji, aktualizacje bezpieczeństwa w stałym oknie serwisowym (np. wtorek, 6:00–8:00), kopia przed zmianą i po niej.

Co miesiąc: raport z liczbą wykonanych godzin, listą zmian, czasami reakcji na zgłoszenia i rekomendacjami na kolejny okres. Cztery liczby, które warto porównywać między wykonawcami.

Co kwartał: test odtworzenia kopii na środowisku testowym oraz test pełnej ścieżki zakupu – koszyk → płatność → etykieta → e-mail. Bez tego dowiesz się o awarii od klienta, który nie dostał potwierdzenia.

Co rok: przegląd wersji PHP i plan migracji, porządki w bazie i plikach, przegląd konfiguracji bezpieczeństwa oraz poczty wychodzącej – SPF, DKIM, DMARC. Bez rekordów DMARC maile z potwierdzeniami zamówień częściej trafiają do spamu.

Zasada zamrożenia: od 10 grudnia i w szczycie sezonu wdrażamy wyłącznie poprawki bezpieczeństwa.

Pułapki w opiece nad sklepem i jak je wykryć

Najczęstsza pułapka to kopie zapasowe trzymane na tym samym serwerze co sklep. Sprawdzisz to w pięć minut: poproś o ścieżkę, w której leżą dumpy bazy i archiwa plików, i zweryfikuj ją w panelu hostingu. Jeśli to /home/konto/backup albo katalog wewnątrz public_html, jedna awaria serwera zabiera sklep i kopie razem. Druga rzecz to test odtworzenia — kopia, której nikt nigdy nie odtworzył, jest tylko hipotezą. Poproś o przywrócenie dumpa na obcym środowisku (lokalny Docker, subdomena staging) i sprawdzenie, czy zgadza się liczba zamówień i produktów oraz czy wyświetlają się zdjęcia.

Kolejna pułapka: opieka sprowadzona do opłacania licencji i klikania „aktualizuj”. Pytanie kontrolne brzmi: co dzieje się po aktualizacji? Powinien istnieć scenariusz testowy — zamówienie testowe każdą metodą płatności, zmiana statusu, faktura PDF, mail potwierdzający, etykieta kurierska. Bez tego pierwszy klient po aktualizacji modułu płatności odkryje błąd zamiast Ciebie. Trzecia: nadpisywanie modyfikacji. Jeśli zmiany siedzą w plikach rdzenia sklepu albo w motywie nadrzędnym, najbliższa aktualizacja je usunie. Wykryjesz to, porównując pliki z oryginalnym pakietem w tej samej wersji (diff -r lub sumy kontrolne). W PrestaShop modyfikacje należą do motywu potomnego i modułu własnego, nie do rdzenia — potwierdza to dokumentacja dla deweloperów PrestaShop. Czwarta: brak dziennika zmian. Zadaj jedno pytanie: „pokażcie dziennik zmian z ostatnich 3 miesięcy”. Cisza w odpowiedzi oznacza brak procesu.

• Praca wyłącznie przez panel, bez kopii roboczej i środowiska testowego — każda zmiana ląduje od razu na produkcji, a jej wycofanie to ręczne przywracanie plików.
• Zmiana wersji PHP bez testów — hosting podnosi PHP z 7.4 na 8.1 „przy okazji”, sklep wstaje, ale moduł płatności i generator faktur przestają działać. Test: error_log, zamówienie testowe, wystawienie faktury.
• Pozorne bezpieczeństwo: jedno konto admin dla całego zespołu, brak 2FA, certyfikat SSL odnawiany ręcznie, bez alertu o wygaśnięciu.
• Alert-test: poproś o chwilowe wyłączenie monitoringu na 15 minut. Jeśli powiadomienie SMS lub e-mail nie dociera — monitoringu nie ma albo alerty lecą na martwą skrzynkę.

Jeśli po takim przeglądzie zostaje więcej niż dwa punkty do naprawy, temat warto potraktować szerzej — podobne przypadki opisujemy przy okazji utrzymania i opieki technicznej sklepów Zwierzyniec.

Lista kontrolna przed podpisaniem umowy na opiekę techniczną

Całą listę przejdziesz przed podpisaniem umowy, bez wiedzy technicznej. Metoda jest jedna: nie pytaj „czy robicie kopie”, pytaj „gdzie leżą i kiedy ostatnio odtworzyliście je na innym serwerze”. Odpowiedź ze szczegółem jest wiarygodna, odpowiedź „tak, oczywiście” — nie. To samo dotyczy dostępu: nie interesuje Cię zapewnienie, że dane są bezpieczne, tylko informacja, że dostaniesz własne konto administratora zamiast współdzielonego admin.

Krytyczne są cztery rzeczy: kopie poza serwerem sklepu, ich realny test odtworzenia, komplet dostępów po Twojej stronie i SLA na piśmie z czasem reakcji oraz czasem naprawy. Bez tego nie ma o czym rozmawiać — reszta to kwestia proporcji i budżetu.

Kiedy opieka techniczna się opłaca, a kiedy wystarczy monitoring

Podział jest prosty: im więcej integracji, tym większa szansa, że po cichej aktualizacji wysypie się coś, czego nie widać w panelu. Sklep bez ERP, z jedną bramką płatności i kilkoma zamówieniami dziennie zwykle nie potrzebuje stałego abonamentu. Wystarczy hosting z automatycznymi kopiami poza serwerem, monitoring dostępności z alertem oraz jedna godzina serwisowa kwartalnie na aktualizacje i test zamówienia. Sklep z ERP, kilkoma kurierami, płatnościami ratalnymi i integracją fakturową to inna liga — tam każda aktualizacja modułu to ryzyko zerwanego przepływu zamówień, a abonament przestaje być kosztem, a staje się ubezpieczeniem.

Policz koszt alternatywny własną stawką. Jeśli wyceniasz swoją godzinę na 120 zł, a na gaszenie sklepu schodzi Ci 5 godzin miesięcznie, praca „za darmo” kosztuje 600 zł — i tak nie obejmuje kopii ani testów. Do tego dochodzi ryzyko przestoju: w sklepie sezonowym jeden dzień w szczycie może kosztować więcej niż roczny abonament. Widełki abonamentów sprawdź w konkretnych ofertach u siebie, nie w cudzych cennikach z internetu.

Przy zmianie wykonawcy kluczowa jest lista dostępów: hosting, panel domeny i rekordy DNS, SFTP, baza danych, panel sklepu, konta w modułach płatności i kurierskich, repozytorium kodu, licencje modułów. Kolejność: najpierw inwentaryzacja i własna kopia po stronie przejmującego, potem własne konta, na końcu zmiana haseł i DNS. Przez tydzień, dwa oba zespoły działają równolegle. Podobny schemat przekazania opisujemy przy utrzymaniu i opiece technicznej sklepów Zamość.

I ostatnia rzecz: jeśli sklep działa stabilnie, kopie są testowane, nikt nie zwleka z reakcją, a Ty masz dostępy — nie zmieniaj wykonawcy tylko dlatego, że ktoś oferuje więcej. Zmiana bez powodu to najdroższa forma opieki.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Dostępy po Twojej stronie — Sprawdź, czy masz dane do hostingu, panelu DNS, domeny i panelu sklepu z uprawnieniami administratora. Jeśli nie – zmień to przed podpisaniem umowy na opiekę.
• Częstotliwość kopii — Umowa powinna wskazywać osobno bazę danych (co 24 h lub częściej w sklepach z dużym ruchem) i pliki (co 24 h). Poproś o wskazanie godziny wykonywania kopii.
• Kopie poza serwerem — Kopia leżąca na tym samym hostingu co sklep nie chroni przed awarią hostingu ani przed usunięciem serwera. Sprawdź, gdzie fizycznie trafia kopia.
• Retencja kopii — Zapytaj, ile dni wstecz możesz odtworzyć dane. Rozsądne minimum to 14 dni, komfortowe 30 dni. Retencja 3 dni oznacza, że błąd z ubiegłego tygodnia jest nie do cofnięcia.
• Test odtworzenia — Raz na kwartał. Weryfikacja: poproś o raport z datą testu, środowiskiem docelowym i czasem odtworzenia. Brak raportu = brak testu.
• Okno serwisowe i kopia przed zmianą — Ustal, w jakich godzinach wykonawca może pracować na produkcji i czy przed każdą aktualizacją robi kopię punktową. Sprawdź to na przykładzie ostatniej aktualizacji.
• Aktualizacje rdzenia, modułów i PHP — Zapytaj, kto decyduje o momencie aktualizacji i jak sprawdzana jest zgodność modułów z nową wersją PHP. Wersje wspierane przez PrestaShop są opisane w dokumentacji dla deweloperów – wykonawca powinien to monitorować.
• Test płatności po każdej aktualizacji — Zamówienie testowe z realną płatnością i zwrotem, najlepiej w trybie produkcyjnym lub piaskownicy operatora. Wynik powinien trafić do rejestru zmian.
• Test modułów kurierskich — Wygenerowanie etykiety InPost, DPD lub DHL po każdej aktualizacji sklepu, PHP lub modułu. To najczęstsze źródło cichych awarii – zamówienia wchodzą, paczki nie wychodzą.
• Monitoring dostępności — Interwał 1–5 minut, alert e-mail i SMS. Zweryfikuj, czy alert przychodzi również wtedy, gdy sklep odpowiada kodem błędu 500, a nie tylko przy całkowitym braku odpowiedzi.
• Monitoring certyfikatu SSL — Osobne powiadomienie z wyprzedzeniem, nie w dniu wygaśnięcia. Sprawdź datę ważności obecnego certyfikatu w przeglądarce i porównaj z datą w umowie.
• Przegląd logów raz w miesiącu — Logi błędów PHP, wolne zapytania MySQL oraz tabele nadmiarowe (koszyk, sesje, logi). Poproś o krótki miesięczny raport – jego brak oznacza, że nikt tam nie zagląda.
• Higiena bezpieczeństwa — Imienne konta administratora zamiast wspólnego „admin”, usunięte nieużywane wtyczki i motywy, blokada XML-RPC, limit prób logowania, aktualny certyfikat i kopie weryfikowane co kwartał.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów