Czym jest utrzymanie i opieka techniczna sklepu internetowego

Wdrożenie sklepu to projekt z datą początku i końca — odbiór, faktura, zamknięcie tematu. Utrzymanie to usługa ciągła: płacisz co miesiąc za konkretną liczbę godzin (typowo 5–20 h) i za gotowość do reakcji. Rozlicza się to abonamentem godzinowym. Pierwsza rzecz do ustalenia w umowie: czy niewykorzystane godziny przechodzą na kolejny miesiąc. Przy 10 h miesięcznie różnica między „przechodzą” i „przepadają” to nawet kilkadziesiąt godzin w skali roku.

Zakres opieki zamyka się w pięciu filarach:

• Dostępność — monitoring co 1–5 minut (UptimeRobot, Better Stack), ale nie tylko strony głównej. Trzeba pilnować koszyka, podsumowania zamówienia i samego procesu płatności.
• Aktualizacje — rdzeń PrestaShop lub WooCommerce, moduły, wtyczki, motyw, wersja PHP, MySQL. Nigdy hurtem: najpierw środowisko testowe, kopia, potem test koszyka i płatności.
• Kopie zapasowe — pliki i baza w innej lokalizacji niż serwer produkcyjny, z testem odtworzenia raz na kwartał. Kopia, której nigdy nie odtworzyłeś, nie jest kopią.
• Bezpieczeństwo — WAF, limit prób logowania, 2FA na kontach administracyjnych, przegląd podatności modułów przed aktualizacją.
• Rozwój funkcji — drobne zmiany: nowy próg darmowej dostawy, dodatkowe pole w formularzu, poprawka w szablonie maila, baner na sezon.

Kto realnie potrzebuje opieki: sklep z ruchem powyżej 1–2 tys. sesji miesięcznie, sklep z integracjami (Subiekt, ERP, Baselinker, API kurierów) oraz każdy, kto nie ma w firmie osoby, która wejdzie na serwer i przeczyta logi. Tak samo działa to w mniejszych miejscowościach — zobacz, jak podchodzimy do utrzymania i opieki technicznej sklepów Szczebrzeszyn i sklepów Zwierzyniec.

Kiedy opieka nie ma sensu? Sklep w zamkniętej fazie testów, do którego nikt nie zagląda, i mikrosklep z 2 zamówieniami miesięcznie. Tam wystarczy kopia zapasowa od dostawcy hostingu i wsparcie na godziny, gdy coś się zepsuje. Powiemy to wprost, zamiast sprzedawać abonament na zapas.

Co realnie psuje się w sklepie — 7 awarii, które kosztują sprzedaż

Zamiast ogólnych ostrzeżeń — siedem sytuacji, które widzimy najczęściej. Każda kończy się albo utratą zamówień, albo kilkoma godzinami pracy przy wyjaśnianiu klientom, dlaczego nie dostali potwierdzenia.

• Konflikt wtyczki po automatycznej aktualizacji WooCommerce. Objaw: biały ekran, koszyk przestaje działać. Bez trybu debug (WP_DEBUG i debug.log w wp-config.php) w logach nie ma nic. Najszybsze wyjście: zmiana nazwy katalogu wtyczki przez SFTP i powrót do kopii.
• Przepełniony dysk na VPS. Rosnąca tabela logów, np. wp_actionscheduler_log, albo kopie zapasowe zapisywane w tym samym katalogu co pliki sklepu. Skutek: baza nie potrafi zapisać zamówienia, sesje klientów się rozjeżdżają. Sprawdzenie zajmuje minutę: df -h i du -sh na katalogu sklepu.
• Wygasły certyfikat SSL. Let’s Encrypt odnawia się automatycznie, ale nie gdy padł cron albo zmienił się DNS. Przeglądarki blokują płatność i wysyłkę, pojawia się ostrzeżenie o niezabezpieczonej stronie, a ruch spada w ciągu godziny.
• Nieudana migracja PHP 7.4 na 8.x. Hosting przełącza wersję w panelu, stary moduł korzysta z usuniętej funkcji i sklep przestaje przyjmować zamówienia. Błąd 500 widać wyłącznie w logu PHP na serwerze.
• Zbyt agresywne reguły WAF blokują panel admina. Właściciel traci dostęp do własnego sklepu, a zgłoszenie do supportu WAF trwa dłużej niż sam incydent.
• Zerwany webhook płatności lub API kuriera. Zamówienia są opłacone, ale statusy się nie aktualizują i etykiety się nie generują. Klient dzwoni z pretensjami, a Ty dowiadujesz się o awarii od niego.
• Atak credential stuffing na /admin. Tysiące prób logowania dziennie obciążają bazę i realnie grożą przejęciem konta. Lekarstwo: limit prób, 2FA, zmiana adresu panelu.

Po każdym incydencie warto sprawdzić, czy nie ucierpiały metryki ładowania — czym są LCP i INP, opisuje web.dev – Web Vitals. Zasady, które stosujemy w regionie, opisaliśmy przy okazji utrzymania i opieki technicznej sklepów Zamość.

SLA w praktyce: czasy reakcji, kanały zgłoszeń i co jest poza umową

Trzy progi krytyczności to minimum, jakie musi zawierać każda umowa na opiekę. Bez nich nie da się rozmawiać o jakości usługi, bo każdy incydent staje się sprawą „pilną”.

Czas reakcji to nie czas naprawy. Reakcja oznacza potwierdzenie zgłoszenia i rozpoczęcie diagnozy. Naprawa to przywrócenie działania, a jej czas zależy od przyczyny — awaria certyfikatu to 15 minut, konflikt modułu po aktualizacji może zająć pół dnia. W praktyce 90% właścicieli nie rozróżnia tych dwóch pojęć przy podpisywaniu umowy i później czuje się oszukanych. Wpisz do umowy oba parametry osobno.

Kanał zgłoszeń. Mail albo panel ticketowy — musisz mieć zapis: kto zgłosił, kiedy, co zostało zrobione. Telefon bywa szybszy, ale zgłoszenie bez ticketu to pułapka przy sporach. Zasada, którą warto wpisać: telefonicznie ustalamy tylko priorytet, a treść zgłoszenia i tak trafia do systemu.

Zapisy do wykreślenia: „opieka w miarę dostępności”, brak okna serwisowego (kiedy wykonawca może pracować na produkcji), brak definicji utraty danych. Uczciwa umowa podaje RPO i RTO — np. kopia co 24 h i odtworzenie do 4 h.

Poza umową zostają: prace nad nowymi modułami, migracja na inną platformę i kampanie SEO. To osobne projekty, wyceniane godzinowo z estymacją przed startem albo jako stała cena za zakres. Jak to wygląda przy WordPressie, rozpisaliśmy w materiale opieka WordPress Lublin: ceny, zakres i wybór wykonawcy.

Ile kosztuje utrzymanie sklepu — widełki oparte na liczbie godzin

Wycena utrzymania sprowadza się do jednego pytania: ile godzin miesięcznie realnie potrzebuje Twój sklep. Reszta to stawka godzinowa i granica między tym, co w abonamencie, a tym, co poza nim.

Na rynku lubelskim najczęściej spotkasz dwa modele rozliczenia:

• Abonament godzinowy — 5, 10 albo 20 godzin miesięcznie, rozliczanych w cyklu miesięcznym. Ustal w umowie, czy niewykorzystane godziny przechodzą na kolejny okres, czy przepadają. W praktyce większość firm nie przenosi ich dalej niż o jeden miesiąc.
• Prace poza abonamentem — nowe moduły, migracje, integracje z ERP czy kurierami. Rozliczane stawką godzinową albo wyceniane zadaniowo.

Widełki stawek zależą od zakresu i odpowiedzialności, nie od renomy wykonawcy. Proste prace serwerowe — konfiguracja PHP, crony, reguły firewall, certyfikat — oscylują w okolicy 120–180 zł/h netto. Prace modułowe i integracyjne, na przykład pisanie modułu do PrestaShop czy łączenie sklepu z ERP, to zwykle 200–320 zł/h netto. Zawsze potwierdź stawkę w konkretnej ofercie — widełki rynkowe to nie cennik.

Dwa przykłady roczne. Sklep na WooCommerce, 100 zamówień miesięcznie, jeden język, bez ERP: 5–10 h miesięcznie, czyli 60–120 h rocznie, przy 150 zł/h daje 9 000–18 000 zł netto. Sklep na PrestaShop z integracją ERP, magazynem i kilkoma metodami dostawy: 10–20 h miesięcznie, czyli 120–240 h rocznie i 24 000–48 000 zł netto — bo każda aktualizacja modułu ERP wymaga nadzoru i testu.

Wycena na oko, bez audytu, jest prawie zawsze zawyżona: wykonawca dolicza bufor na nieznane. Pierwsze 2–3 płatne godziny audytu powinny objąć wersje PHP i MySQL, listę modułów z datami, logi błędów, czasy odpowiedzi, konfigurację kopii zapasowych, crony, kolejkę maili, stan certyfikatu i zużycie dysku. Do tego dochodzą koszty poza robocizną: licencje modułów, VPS 60–200 zł miesięcznie, domena, certyfikat, zewnętrzny monitoring. Techniczne podstawy modułów opisuje dokumentacja dla deweloperów PrestaShop — warto zajrzeć, jeśli dostajesz ofertę na prace modułowe. Podobny układ stawek i zakresów znajdziesz w modelu utrzymania i opieki technicznej sklepów w Zamościu.

Monitoring, kopie zapasowe i aktualizacje — konfiguracja krok po kroku

Zanim podpiszesz umowę, poproś obecnego wykonawcę o trzy rzeczy: zrzut ekranu monitoringu z ostatnich 30 dni, datę ostatniego testu odtworzenia backupu i listę aktualizacji z ostatniego kwartału. Jeśli nie ma czym odpowiedzieć, masz odpowiedź.

Monitoring zewnętrzny co 1 minutę: kod HTTP, czas odpowiedzi i poprawność certyfikatu. Sprawdzaj nie tylko stronę główną, ale też kartę produktu i scenariusz koszyka — uptime 100% nic nie znaczy, jeśli checkout zwraca błąd 500, a monitoring tego nie widzi. Monitoring wewnętrzny: obciążenie CPU, zużycie RAM, wolne miejsce i inody, długość kolejki maili (sklep, który nie wysyła potwierdzeń zamówień, traci klientów po cichu) oraz liczba procesów PHP-FPM. Osobno warto raz w miesiącu przejrzeć Core Web Vitals w Search Console — realne pomiary użytkowników, opisane w materiałach web.dev o Web Vitals.

Backup w modelu 3-2-1: codziennie baza i pliki, kopia zawsze poza serwer produkcyjny, minimum 30 dni retencji dziennej plus jedna kopia miesięczna na 12 miesięcy. Raz na kwartał test odtworzenia na środowisku staging — z zapisem daty, czasu trwania i wyniku. Bez testu nie wiesz, czy backup w ogóle się odtworzy.

Kolejność aktualizacji jest stała: kopia → staging → aktualizacja na staging → test koszyka i płatności transakcją testową u operatora → produkcja. Wdrażaj poza szczytem zamówień i miej przygotowany rollback. PHP oraz system operacyjny aktualizuj niezależnie od wersji sklepu. Zapytaj hosting, w jakich godzinach restartuje PHP-FPM — jeśli robi to w piątek o 17:00, dowiesz się o tym w poniedziałek z maila od klienta.

Alerty, które muszą działać: koniec ważności certyfikatu SSL, koniec opłacenia domeny, koniec wsparcia wersji PHP i wygaśnięcie licencji modułu. Zakres i stawki takich pakietów opisujemy też przy okazji opieki technicznej sklepów w Zwierzyńcu.

Bezpieczeństwo i zgodność: PHP, SSL, RODO i płatności bez teorii

Cykl życia PHP to pierwszy punkt audytu. Wersja bez wsparcia bezpieczeństwa oznacza brak łatek — nie da się tego nadrobić konfiguracją ani WAF-em. Wersję sprawdzisz w pliku phpinfo(), w panelu hostingu albo w konfiguracji serwera. Sprawdź też, czy sklep działa na wersji wspieranej przez swoją wtyczkę e-commerce.

HTTPS na całej domenie: certyfikat obejmujący adres z www i bez www, przekierowanie 301 z HTTP na HTTPS, nagłówek HSTS z rozsądnym max-age, wymuszenie SSL w konfiguracji sklepu (w PrestaShop: Zaawansowane → Parametry i włącz SSL). Sprawdź też mixed content — obrazy i skrypty ładowane po HTTP potrafią blokować część funkcji koszyka w przeglądarce.

RODO w praktyce sprowadza się do retencji i dostępu, nie do generowania dokumentów na zapas. W bazie zostają porzucone koszyki, stare logi, wiadomości z formularzy. Ustal, ile trzymasz każdą kategorię danych, i pilnuj tego crona czyszczącego. Dostępy powinny być imienne — jedno wspólne konto admin to problem przy zmianie pracy. Procedura odbioru: zmiana haseł, usunięcie kont, rotacja kluczy API i SSH, sprawdzenie kont współdzielonych z firmą zewnętrzną.

Płatności i PCI DSS. Gdy transakcję obsługuje operator (Przelewy24, PayU, Stripe), dane karty nie przechodzą przez sklep, a zakres wymagań jest wąski — zwykle SAQ A. Jeśli moduł płatności loguje albo zapisuje dane karty w bazie, wchodzisz w znacznie szerszy zakres. Sprawdź, czy formularz jest hostowany przez operatora i czy w logach nie ma numerów kart.

Higiena minimum: dwuskładnikowe uwierzytelnianie, dostęp do /admin ograniczony po IP przez .htaccess lub firewall, dziennik zmian w panelu włączony. Ten sam zestaw zasad stosujemy w utrzymaniu sklepów w Szczebrzeszynie.

Przejęcie sklepu od poprzedniego wykonawcy — procedura w 6 krokach

Zmiana wykonawcy to projekt techniczny z listą zadań i datami, nie rozmowa o winie. Najczęstszy błąd: nowa firma dostaje dostępy „na już”, a stary wykonawca dowiaduje się o zmianie w dniu przełączenia DNS.

1. Inwentaryzacja dostępów. Arkusz z kolumnami: usługa, kto ma login, gdzie jest 2FA, data weryfikacji. Zakres: hosting (panel, FTP/SFTP, SSH), panel domeny i strefa DNS, panel sklepu (Back Office PrestaShop lub wp-admin), API kurierów (InPost ShipX, DPD, DHL — osobno środowisko testowe i produkcyjne), operator płatności (Przelewy24, PayU, Stripe), konta Google (Search Console, Analytics 4, Ads, Merchant Center) i Meta.

2. Klucze kontra hasła. Hasła i klucze API resetujesz albo generujesz od nowa — nie „odbierasz”. Kopia przekazana mailem zostaje w tej skrzynce na zawsze. Nowy klucz tworzysz w panelu usługodawcy, wpisujesz do konfiguracji sklepu, stary unieważniasz tego samego dnia.

3. Zrzut bazy i plików. Wyślij żądanie: dump bazy SQL, archiwum katalogu sklepu z /modules, /themes i /override, plik konfiguracyjny. Podaj termin, np. 5 dni roboczych. Jeśli klient ma własny login do hostingu, zrzut robi sam z panelu i niczyja zgoda nie jest potrzebna.

4. Staging i test regresji. Odtwórz kopię na środowisku testowym i przejdź: logowanie, koszyk, checkout, płatność testowa, etykieta kurierska, mail potwierdzający, faktura, kod rabatowy.

5. Przełączenie DNS. Okno poza szczytem sprzedaży, np. wtorek 5:00–7:00. 24 godziny wcześniej obniż TTL rekordów A i CNAME do 300 s — rollback działa wtedy w minutach, nie w godzinach. Stary zestaw rekordów trzymaj w pliku.

6. Pierwsze 30 dni. Ustal baseline: TTFB, LCP, INP i CLS według metryk Web Vitals, liczba zamówień na dobę, lista znanych problemów. Na koniec zamknij stare dostępy: rotacja haseł, unieważnienie kluczy, usunięcie kont byłych wykonawców, 2FA dla wszystkich, którzy zostają.

Kolejność kroków nie zależy od miasta — tak samo wygląda utrzymanie i opieka techniczna sklepów Zwierzyniec.

Frampol i Lubelszczyzna: jak wybrać wykonawcę i nie przepłacić

Na Lubelszczyźnie zapytanie o opiekę sklepu trafia zwykle do trzech typów wykonawców. Każdy ma inną cenę i inne ryzyko.

Na pierwszej rozmowie zadaj cztery pytania i zapisz odpowiedzi: kto konkretnie odbierze zgłoszenie (imię i nazwisko, nie „zespół”), kto go zastąpi w razie urlopu, kto odpowiada za kopie trzymane poza serwerem sklepu oraz jakim kanałem zgłaszasz awarię (mail, ticket, telefon) i w jakich godzinach ten kanał działa.

Czerwone flagi, przy których warto zakończyć rozmowę: klient nie dostaje własnego dostępu do panelu hostingu i DNS; cała oferta jest „w pakiecie”, bez rozbicia na godziny i zakres; w umowie nie ma zapisu o przekazaniu dostępów, kopii i dokumentacji po zakończeniu współpracy; SLA istnieje tylko w ofercie handlowej, a nie w załączniku do umowy.

Lokalność pomaga w dwóch sytuacjach: gdy trzeba wejść na miejsce (serwerownia, kasa fiskalna, drukarka etykiet) i gdy problem dotyczy infrastruktury — bezpośredni kontakt z deweloperem skraca ustalanie, czy winny jest sklep, czy hosting. W pozostałych przypadkach praca zdalna wystarcza: logi, kopie i staging są dostępne przez internet, a czas reakcji zależy od procedury, nie od odległości. Zakres zwykle rozkłada się na te same pięć obszarów co w utrzymaniu i opiece technicznej sklepów Zamość, a porównanie stawek opisuje opieka WordPress w Lublinie: ceny, zakres i wybór wykonawcy.

Przekazanie sklepu na koniec umowy ma być konkretne: plik z dostępami w menedżerze haseł (nie w mailu), aktualna kopia bazy i plików, dokumentacja modułów — wersje, źródła licencji, własne modyfikacje i ich autor. Punktem odniesienia jest dokumentacja dla deweloperów PrestaShop, więc moduły pisane po swojemu warto opisać w tym samym formacie.

Lista kontrolna przed podpisaniem umowy na opiekę

Tę listę wydrukuj i odklikaj podczas rozmowy z wykonawcą.

1. Kopie bazy minimum raz dziennie, plików minimum raz w tygodniu.
2. Kopie trzymane poza serwerem sklepu — inny dostawca lub inny region.
3. Retencja kopii minimum 30 dni, z możliwością przywrócenia dowolnego dnia.
4. Udokumentowany test odtworzenia z datą i wynikiem.
5. Monitoring dostępności z zewnątrz, sprawdzanie co 1–5 minut, alert trafia do człowieka.
6. Aktualizacje najpierw na stagingu, potem na produkcji, z możliwością wycofania.
7. Zapisany czas reakcji i czas naprawy (SLA) osobno dla awarii krytycznej i zwykłego zgłoszenia.
8. Okno serwisowe oraz informacja, kto decyduje o pilnej aktualizacji bezpieczeństwa.
9. Panel hostingu i DNS pozostają na koncie klienta, wykonawca ma dostęp delegowany.
10. 2FA wszędzie i lista osób z dostępem aktualizowana przy każdej zmianie składu.
11. Raport miesięczny: co zrobiono, ile godzin zużyto, co zostało.
12. Zapis o przekazaniu dostępów, kopii i dokumentacji w 5 dni roboczych od zakończenia umowy.

Każdy punkt weryfikuj materiałem, nie deklaracją. Nie „czy robicie kopie?”, a „pokażcie zrzut ekranu z ostatniego testu odtworzenia i datę”. Nie „czy monitorujecie?”, a „pokażcie wykres z ostatnich 30 dni z zaznaczonym czasem niedostępności”. Nie „przekażecie dostępy?”, a „pokażcie zapis w umowie”.

Reguła na koniec: jeśli brakuje trzech punktów krytycznych, oferta nie jest gotowa do podpisania. Wróć do rozmowy po uzupełnieniu, zamiast podpisywać i liczyć, że dogadacie się później. Ten sam zestaw pytań sprawdza się przy utrzymaniu i opiece technicznej sklepów Szczebrzeszyn, bo procedura jest niezależna od lokalizacji.

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

Lista kontrolna do odklikania

• Zakres pięciu filarów — Sprawdź, czy oferta wymienia osobno: dostępność, aktualizacje, kopie zapasowe, bezpieczeństwo i rozwój funkcji. Brak choćby jednego filaru to sygnał, że zakres jest niedomknięty.
• Trzy progi krytyczności — Umowa powinna rozdzielać: sklep nie działa, pojedyncza funkcja nie działa, zadanie rozwojowe. Dla każdego progu musi być inny czas reakcji.
• Czas reakcji i czas naprawy — Sprawdź, czy to dwie osobne liczby. Reakcja 1-2 h przy awarii krytycznej ma sens tylko wtedy, gdy obok stoi realny czas przywrócenia sprzedaży.
• Kanał zgłoszeń z zapisem — Zweryfikuj, czy istnieje panel ticketowy lub mail z numeracją zgłoszeń i czy dostęp do historii zgłoszeń zostaje u Ciebie po zakończeniu umowy.
• Okno serwisowe — Zapytaj, w jakich godzinach wykonawca może ingerować w sklep i czy o planowanych pracach informuje z wyprzedzeniem.
• Monitoring zewnętrzny — Ustal, czy dostępność sklepu jest sprawdzana z zewnątrz (np. co minutę) i kto dostaje alert — wykonawca, Ty, czy oboje.
• Kopie zapasowe: miejsce i częstotliwość — Zapytaj o lokalizację kopii, częstotliwość i retencję. Odpowiedź 'na serwerze' oznacza, że kopii w praktyce nie ma.
• Test odtworzenia kopii — Poproś o datę ostatniego testu odtworzenia sklepu z backupu. Jeśli nikt tego nie robił, wpisz to jako obowiązek w umowie.
• Definicja utraty danych — Sprawdź, czy umowa mówi, co się dzieje i kto odpowiada, gdy dane zamówień zostaną utracone lub przywrócone z opóźnieniem.
• Środowisko testowe — Zapytaj, gdzie wykonywane są aktualizacje przed wypuszczeniem na produkcję. Praca bezpośrednio na sklepie to ryzyko białego ekranu przy każdej aktualizacji.
• Zapisy do wykreślenia — Uważaj na sformułowania typu 'opieka w miarę dostępności', 'reagujemy niezwłocznie', 'w miarę możliwości'. Nie da się z nich wyciągnąć żadnych konsekwencji.
• Dostęp do serwera i panelu — Ustal na piśmie, że po zakończeniu współpracy dane dostępowe, kopie i dokumentacja wracają do Ciebie. To warunek, żeby nie być uwięzionym u wykonawcy.
• Raport miesięczny — Sprawdź, czy umowa przewiduje comiesięczne podsumowanie: liczba godzin, wykonane prace, incydenty, pozostałe godziny z abonamentu.
• Co jest poza umową — Ustal, że nowe moduły, integracje, migracja na inną platformę i kampanie SEO są wyceniane osobno. Bez tego granica zakresu rozmyje się po pierwszym miesiącu.

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