Czym jest utrzymanie i opieka techniczna sklepu — i czym nie jest

Utrzymanie i opieka techniczna to nie jedna usługa, którą da się opisać jednym zdaniem w umowie. To trzy różne typy pracy i trzeba je rozdzielić, bo inaczej rozliczenie zawsze kończy się sporem.

Filar reaktywny to naprawa tego, co już się zepsuło: błąd 500 po aktualizacji, niedziałający checkout, zerwane połączenie z API przewoźnika. Filar prewencyjny to aktualizacje, kopie zapasowe, monitoring i przeglądy bezpieczeństwa. Filar rozwojowy to nowe funkcje, nowe integracje i zmiany w szablonie.

W dojrzałym sklepie 60–70% godzin z abonamentu idzie na prewencję i rozwój, a 30–40% na reakcję. Jeśli jest odwrotnie i 70% czasu zjada gaszenie pożarów — to nie znaczy, że sklep jest „trudny”. Znaczy, że coś jest niedomknięte: brak środowiska staging, PHP po terminie wsparcia, moduły aktualizowane raz w roku, brak monitoringu, który wykryłby problem przed klientem.

Czego NIE obejmuje typowa „opieka w cenie hostingu”:

• dostęp do plików i bazy (SFTP, phpMyAdmin) oraz własne kopie — często jesteś zamknięty w panelu,
• aktualizacje wtyczek i modułów firm trzecich — hosting aktualizuje serwer, nie Twój sklep,
• poprawki w modułach autorskich i szablonie — nikt ich nie zgłosił do supportu, więc nikt ich nie naprawi,
• integracje kurierskie i płatnicze (InPost, DPD, DHL, operator płatności) — zmiana API po stronie dostawcy to nie awaria hostingu,
• optymalizacja wydajności — LCP, cache, zapytania do bazy,
• raportowanie — nikt Ci nie powie, ile razy sklep realnie leżał.

Granica abonamentu. Utrzymanie jest powtarzalne i przewidywalne, więc mieści się w opłacie miesięcznej: np. podmiana klucza API po zmianie po stronie przewoźnika. Rozwój jest jednorazowy i szacowany z góry: dodanie nowego przewoźnika to zwykle 4–8 h z osobnej puli. Jeśli umowa tego nie rozdziela, po kilku miesiącach okazuje się, że „opieka” to w praktyce hosting z backupem.

Co dokładnie wchodzi w pakiet opieki: 6 obszarów z konkretami

Poniżej sześć obszarów, które w dobrej ofercie mają przypisane konkretne parametry. Jeśli któryś jest opisany ogólnie („dbamy o bezpieczeństwo”), to nie jest parametr — to hasło.

• Aktualizacje. Rdzeń CMS (PrestaShop, WooCommerce, WordPress), moduły i wersja PHP. Przegląd raz w miesiącu, poprawki bezpieczeństwa w ciągu 72 h od publikacji. Okno serwisowe poza szczytem sprzedaży, np. 2:00–5:00. Procedura: snapshot i kopia przed zmianą, test na staging, wdrożenie na produkcję, weryfikacja koszyka i checkoutu, rollback do 30 minut, jeśli testy nie przejdą.
• Kopie zapasowe w modelu 3-2-1. Baza i pliki co 24 h, retencja minimum 30 dni, co najmniej jedna kopia poza serwerem produkcyjnym, test odtworzenia raz na kwartał. Nie „mamy backupy”, tylko „odtworzyliśmy sklep na staging w X minut”.
• Monitoring. Dostępność co 1–5 minut, SSL z alertem 14 dni przed wygaśnięciem, miejsce na dysku, kolejka e-maili, błędy 5xx w logach.
• Bezpieczeństwo. 2FA do panelu i serwera, WAF, ograniczenie dostępu do /admin, przegląd uprawnień użytkowników raz na kwartał, reakcja na podatności z CVE w ciągu 48 h.
• Wydajność. Core Web Vitals — LCP, INP, CLS ([progi i definicje Web Vitals](https://web.dev/articles/vitals)) — czas odpowiedzi koszyka i checkoutu, cache obiektowy (Redis), analiza slow query log. Sklepu z tysiącami produktów nie przeskoczysz samym szablonem, jeśli baza nie ma cache obiektowego.
• Integracje. InPost, DPD, DHL, operatorzy płatności, ERP (Subiekt, Comarch Optima, WMS). Monitoring statusu API, alert przy błędach, obsługa zmian po stronie dostawcy.

Ten sam zakres usług realizujemy w sąsiedniej lokalizacji: [utrzymanie i opieka techniczna sklepów w Biłgoraju](https://dropdigital.pl/utrzymanie-opieka-techniczna-sklepow-bilgoraj).

SLA w praktyce: czasy reakcji, okno serwisowe, raport miesięczny

Dobra umowa ma dwa osobne czasy dla każdego priorytetu: czas reakcji (potwierdzenie zgłoszenia i przypisanie inżyniera) oraz czas naprawy (przywrócenie sprzedaży).

Najczęstsza pułapka to zapis „reagujemy w 15 minut”. Te 15 minut dotyczy zgłoszenia, nie rozwiązania — a w ofercie często jest tylko jeden parametr i nie wiadomo, czy chodzi o pierwszą odpowiedź, czy o naprawę. Dopisz też definicję naprawy: czy to przywrócenie sprzedaży obejściem (np. wyłączenie wadliwego modułu), czy usunięcie przyczyny. To pierwsze jest zwykle znacznie szybsze i to ono powinno być w SLA, a nie furtka dla wykonawcy.

Okno serwisowe i wyłączenia. Planowane prace w oknie 2:00–5:00 z powiadomieniem 24 h wcześniej — te godziny nie wliczają się do SLA. Wyłączenia: awaria dostawcy hostingu lub centrum danych, siła wyższa, niezaplanowana zmiana API po stronie przewoźnika lub operatora płatności, działania osób trzecich. Uwaga: „awaria hostingu” nie może być furtką na wszystko — jeśli dostawca notuje 4 h przestoju co miesiąc, to problem z infrastrukturą, nie siła wyższa.

Raport miesięczny powinien zawierać: liczbę zgłoszeń według priorytetu, zużycie godzin z puli, wykonane aktualizacje z wersjami, status kopii (data ostatniej i wynik testu odtworzenia), incydenty bezpieczeństwa oraz realne czasy reakcji zestawione z deklaracją SLA. Klauzula eskalacji: jeśli w miesiącu naruszono SLA, kolejny miesiąc obejmuje określoną liczbę godzin bez opłaty albo rabat. Bez tego SLA jest deklaracją, nie zobowiązaniem.

Identyczne zasady stosujemy w innych lokalizacjach, np. [utrzymanie i opieka techniczna sklepów Szczebrzeszyn](https://dropdigital.pl/utrzymanie-i-opieka-techniczna-sklepow-szczebrzeszyn).

Ile kosztuje utrzymanie sklepu w Narolu i regionie — widełki stawek

Stawki za prace serwisowe przy sklepach internetowych w Polsce mieszczą się w dwóch widełkach. Prace standardowe — aktualizacja rdzenia i wtyczek, poprawka szablonu, konfiguracja kopii zapasowej, drobna korekta w CSS — to 130–180 zł/h netto. Prace specjalistyczne — integracja z ERP, moduł pisany na zamówienie, migracja między wersjami, optymalizacja wydajności (cache, indeksy w bazie, PHP-FPM) — to 180–250 zł/h netto. Różnica wynika z ceny pomyłki: przy integracji z ERP wykonawca musi znać API i schemat bazy, a błąd potrafi zablokować wystawianie faktur.

Budżet miesięczny liczy się z godzin, nie z nazwy pakietu. Mały sklep na WooCommerce z kilkunastoma wtyczkami: 4–6 h/mies., czyli ok. 600–1000 zł netto. Sklep na PrestaShop zintegrowany z ERP i kilkoma kurierami: 10–20 h/mies., czyli ok. 1500–3500 zł netto. Górna granica dotyczy sklepów z modułami autorskimi i dedykowanym VPS — samo utrzymanie serwera, kolejek zadań do ERP i analiza logów zajmuje wtedy kilka godzin w miesiącu.

Co podnosi koszt poza platformą:

• integracja z systemem ERP (Subiekt, Comarch, WMS) — każda aktualizacja po którejkolwiek ze stron wymaga testu przepływu zamówień i stanów magazynowych,
• moduły pisane na zamówienie — nie ma ich kto zaktualizować poza autorem kodu,
• dedykowany VPS — aktualizacje systemu, PHP i MariaDB oraz konfiguracja kopii po stronie serwera,
• sklep wielojęzyczny lub wielosklepowy — każda zmiana szablonu i każde tłumaczenie mnożą się przez liczbę witryn,
• sezonowe skoki ruchu — czerwiec i grudzień wymagają wcześniejszego testu obciążeniowego, a nie reagowania w trakcie.

Oferta „nielimitowana opieka za 299 zł/mies.” ma zwykle jeden mechanizm działania: brak realnych aktualizacji. Za tę kwotę nie sfinansujesz testu modułu po aktualizacji na stagingu. Rozliczenie musi być policzalne: stała pula godzin w abonamencie plus stawka za godziny dodatkowe, rozliczana w cyklu miesięcznym, z raportem zużycia. Porównując oferty z okolicy, zadaj każdej z nich to samo pytanie o liczbę godzin — utrzymanie i opieka techniczna sklepów w Biłgoraju to ten sam rynek usługowy i zbliżone stawki.

PrestaShop, WooCommerce czy sklep pisany na zamówienie — co zmienia platforma

Platforma zmienia zakres opieki, bo zmienia źródło ryzyka.

PrestaShop. Liczy się faza cyklu życia wersji. Linia 1.6 nie jest już rozwijana i nie dostaje poprawek bezpieczeństwa — jej utrzymywanie to odkładanie migracji, nie oszczędność. Linia 1.7 jest w końcowej fazie wsparcia, a bieżącym kierunkiem jest 8.x. Wymagania PHP dla konkretnej wersji sprawdzasz w dokumentacji deweloperskiej PrestaShop — to istotne, bo hosting potrafi podnieść PHP automatycznie i sklep przestaje działać bez żadnej zmiany po Twojej stronie. Drugie ryzyko to moduły: po aktualizacji rdzenia przestają działać hooki, override'y klas i stare wywołania API. Migrację 1.7 → 8.x planujesz etapami: kopia bazy, staging z docelową wersją PHP, test koszyka, płatności, wysyłki, faktury i panelu zamówień, dopiero potem produkcja.

WooCommerce. Tutaj opieka to przede wszystkim zarządzanie wtyczkami i motywem. Konflikty ujawniają się po aktualizacji WordPressa — najczęściej przez zmiany w jQuery, REST API albo wymuszenie nowszej wersji PHP. Osobna kategoria to wtyczki porzucone: w repozytorium widzisz datę ostatniej aktualizacji i liczbę instalacji, a brak wydań od dwóch lat oznacza, że nikt nie łata luk. Rośnie też baza: tabele wp_options i wp_postmeta przy tysiącach zamówień liczą miliony wierszy i spowalniają panel oraz checkout.

Rozwiązanie autorskie. Opieka nad nim wymaga dostępu do kodu i dokumentacji. Bez tego każda poprawka zaczyna się od reverse engineeringu, a to praca specjalistyczna w górnych widełkach stawek.

Wspólny mianownik jest jeden: staging, kontrola wersji i możliwość cofnięcia zmiany. Jeśli wykonawca tego nie ma, każda aktualizacja jest zakładem. Zakres prac serwisowych w abonamencie rozpisaliśmy przy okazji utrzymania i opieki technicznej sklepów Frampol.

Pułapki i sygnały ostrzegawcze: jak sprawdzić obecną opiekę

Poniższe testy wykonasz bez wiedzy technicznej. Wystarczy panel, dostęp do poczty i 15 minut.

• Test kopii zapasowej. Zapytaj, gdzie fizycznie leży kopia. Poprawna odpowiedź to inny serwer lub zewnętrzny storage, nie katalog na tym samym hostingu. Drugie pytanie: kiedy ostatnio odtworzono kopię na środowisku testowym. Kopia, której nikt nie przywracał, jest tylko nadzieją.
• Dostęp do infrastruktury. Sprawdź, czy masz u siebie dane do panelu hostingu lub SSH, konto w rejestratorze domeny (panel DNS), dane do bazy, konto administratora sklepu i pliki. Jeśli wszystko trzyma wykonawca, zmiana dostawcy zaczyna się od negocjacji.
• Data ostatniej aktualizacji. W WordPressie: Wtyczki → kolumna „Dostępna aktualizacja”. W PrestaShop: Moduły. Brak aktualizacji rdzenia i wtyczek od 6 miesięcy to otwarte drzwi dla botów skanujących znane luki.
• Wtyczki nieaktualizowane ponad 12 miesięcy. Sprawdź datę ostatniego wydania w repozytorium. Brak wydań od dwóch lat i porzucone repozytorium oznaczają, że luka nie zostanie załatana.
• Sposób pracy. Jeśli poprawki wchodzą przez FTP, bez stagingu i bez kontroli wersji, przy każdym zgłoszeniu rośnie ryzyko regresji — naprawiasz koszyk, psuje się wysyłka.
• Raport miesięczny. Brak jakiegokolwiek raportu oznacza, że nikt nie wie, co faktycznie zostało zrobione. Pytaj o listę wykonanych prac i zużytych godzin.
• Objawy wydajnościowe. Spadek pozycji i wzrost LCP po wdrożeniu nowych wtyczek, wolny checkout w godzinach szczytu, timeouty przy płatności — to sygnały, że opieka ogranicza się do gaszenia pożarów.

Lista kontrolna: 20 punktów przed podpisaniem umowy

Zanim podpiszesz umowę, przejdź przez listę punkt po punkcie. Odpowiedź „nie” w którymkolwiek z czterech obszarów krytycznych oznacza, że umowy nie podpisujesz — nie „dopisujecie tego później mailem”.

Lista kontrolna — 14 punktów do odklikania:

• 1. Czy hosting, domena, DNS, panel sklepu i konta pocztowe są zarejestrowane na Twoje dane firmowe, a wykonawca występuje wyłącznie jako dodany użytkownik z własnym loginem?
• 2. Czy umowa mówi, że kopia zapasowa plików i bazy powstaje co najmniej raz dziennie i leży poza serwerem produkcyjnym, z retencją minimum 30 dni?
• 3. Czy dostaniesz dokument z testu odtworzenia kopii na środowisku staging — z datą, godziną i czasem odtworzenia?
• 4. Czy SLA rozdziela czas reakcji i czas naprawy i ma co najmniej trzy priorytety (P1 awaria, P2 błąd blokujący, P3 drobne)?
• 5. Czy w SLA są wpisane godziny wsparcia, kanał zgłoszeń (mail, panel, telefon) i zasada działania po godzinach?
• 6. Czy raport miesięczny ma stały zakres: wersje oprogramowania, wykonane aktualizacje, incydenty, czasy reakcji, zajętość hostingu?
• 7. Czy liczba godzin w pakiecie jest policzona, a stawka za nadwyżkę wpisana w umowę?
• 8. Czy aktualizacje rdzenia i wtyczek przechodzą przez środowisko testowe i mają opisaną procedurę rollbacku?
• 9. Czy opieka obejmuje bezpieczeństwo: skanowanie, blokadę nieudanych logowań, reguły WAF lub na serwerze?
• 10. Czy monitoring dostępności działa z zewnątrz co 1–5 minut i wysyła alert także do Ciebie, nie tylko do wykonawcy?
• 11. Czy możesz zażądać pełnej kopii i eksportu danych w ciągu np. 24 godzin?
• 12. Czy umowa wylicza, co jest poza pakietem (nowe funkcje, zmiany szablonu, migracje, treści) i ile to kosztuje?
• 13. Czy opisano okres wypowiedzenia i protokół zdania dostępów?
• 14. Czy wskazano osoby odpowiedzialne po obu stronach, z kontaktem awaryjnym?

Zasada: minimum 12 z 14 punktów musi brzmieć „tak”. Cztery obszary krytyczne — dostęp do kont (1, 11), kopie zapasowe (2, 3), SLA (4, 5, 8), raportowanie (6, 10) — muszą mieć komplet „tak”. Dyskwalifikują, bo przy rozstaniu z wykonawcą hosting i domena na jego dane oznaczają tygodnie odzyskiwania sklepu i poczty, a kopia bez testu odtworzenia to nie kopia, tylko plik. SLA bez rozdzielenia reakcji od naprawy i raport bez liczb uniemożliwiają weryfikację, czy płacisz za usługę, czy za deklarację.

Kiedy sklep w Narolu potrzebuje stałej opieki — progi decyzyjne

Stały pakiet ma sens ekonomiczny, gdy koszt jednego dnia przestoju zbliża się do miesięcznego abonamentu. Policz to na własnych danych, nie na przeczuciu.

Próg 1: powyżej 30 zamówień miesięcznie lub powyżej 20 000 zł obrotu miesięcznego. Przy 20 000 zł obrotu dzienny obrót to około 660 zł. Dobę przestoju w środku tygodnia sprzedażowego liczy się jednak szerzej: utracone zamówienia, telefony od klientów, ręczne odtwarzanie płatności, spadek pozycji po dłuższym błędzie 5xx. Zestaw tę kwotę z ceną abonamentu z oferty — najczęściej wychodzi, że jeden dzień awarii kosztuje więcej niż miesiąc opieki.

Próg 2: integracje. Sklep połączony z ERP (Subiekt, Comarch, WMS) albo z kilkoma kurierami i bramkami płatności wymaga reakcji w dniach, nie tygodniach. Zmiana API kuriera, nowa wersja modułu płatności czy zmiana formatu pliku zamówień potrafi zatrzymać wysyłkę. Bez opieki szukasz wykonawcy na cito i płacisz za każdą interwencję jak za projekt.

Próg 3: sezonowość. Sklep nastawiony na turystykę Roztocza i Lubaczowszczyzny pracuje w oknach szczytowych: maj–wrzesień, długie weekendy, ferie. Wtedy liczy się nie „średni czas reakcji”, ale reakcja w oknie szczytowym. Warto pilnować wtedy wydajności — metryki Core Web Vitals potrafią spaść przy potrójnym ruchu i obniżyć konwersję, jeszcze przed jakąkolwiek awarią.

Próg 4: B2B. Indywidualne cenniki, limity kredytowe, zamówienia na konto — błąd w logice rabatowej potrafi przez tydzień sprzedawać z podwójnym rabatem. Strata na marży bywa kilkukrotnie wyższa niż roczny abonament.

Kiedy wystarczy opieka ad hoc: do 10 zamówień miesięcznie, bez integracji, poniżej 5 tys. wizyt miesięcznie. Wtedy wystarczy kwartalny przegląd, kopie i aktualizacje po stronie hostingu. Sklepy z mniejszych miejscowości regionu traktujemy tak samo — zobacz, jak wygląda utrzymanie i opieka techniczna sklepów w Józefowie, żeby porównać zakres.

Jak zaczynamy: audyt, przejęcie i pierwsze 30 dni

Przejęcie opieki nad działającym sklepem to projekt na miesiąc, nie jedno popołudnie. Kolejność ma znaczenie — najpierw dane i dostępy, potem zmiany.

Krok 1 — audyt techniczny (1–2 dni robocze). Zbieramy fakty: wersje PHP, PrestaShop/WooCommerce i szablonu, listę wtyczek z datą ostatniej aktualizacji i statusem wsparcia, konfigurację kopii zapasowych, czasy odpowiedzi (TTFB, LCP na stronie produktu i koszyka), stan bezpieczeństwa (nieaktualne biblioteki, otwarte katalogi, ścieżka panelu, konta bez 2FA), ustawienia cron i kolejek mailowych. Wynik to lista ryzyk z priorytetami P1–P3.

Krok 2 — uporządkowanie dostępów. Serwer, domena i DNS przechodzą na konta klienta, wykonawca dostaje konta użytkowników z przypisanymi rolami. Wszystkie loginy lądują w menedżerze haseł (np. Bitwarden, 1Password), włączamy 2FA, usuwamy konta po byłych wykonawcach i współdzielone hasła.

Krok 3 — pierwsza kopia i test odtworzenia. Pełny backup plików i bazy, odtworzenie na środowisku staging i pomiar realnego czasu powrotu. Ustalamy RPO (jak często kopie) i RTO (jak szybko odtwarzamy). Bez tego SLA nie ma podstaw.

Krok 4 — aktualizacje w kontrolowanej kolejności. Każda zmiana idzie staging → test koszyka, płatności i maili → produkcja, z rollbackiem do snapshotu sprzed zmiany. Kolejność i zasady aktualizacji rdzenia opisuje dokumentacja PrestaShop dla deweloperów. Okno serwisowe (np. wtorek 6:00–8:00) ustalamy z klientem raz na stałe.

Krok 5 — SLA, kanał zgłoszeń i raport. Ustalamy adres do zgłoszeń, numer awaryjny i priorytety. Pierwszy raport miesięczny trafia w ciągu 30 dni, a po 30 dniach robimy przegląd z listą wniosków i korektą zakresu. Regionalnie pracujemy też przy utrzymaniu i opiece technicznej sklepów w Bełżcu oraz w Szczebrzeszynie.

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

Lista kontrolna do odklikania

• Zakres na piśmie — Poproś o tabelę: co wchodzi w abonament, a co jest osobnym zleceniem. Brak tabeli to zwykle brak ustaleń.
• Cykl aktualizacji — Zapytaj o konkret: rdzeń CMS, moduły firm trzecich, wersja PHP — co ile tygodni i w jakim oknie czasowym.
• Okno serwisowe — Sprawdź, czy prace planowane są poza godzinami sprzedaży, np. 2:00–5:00, i czy jest zapis o wcześniejszym powiadomieniu.
• Rollback — Zapytaj, jak wygląda przywrócenie wersji sprzed aktualizacji i ile to trwa. Odpowiedź „jakoś sobie poradzimy” oznacza brak procedury.
• Kopie w modelu 3-2-1 — Kopia bazy i plików co 24 h, retencja minimum 30 dni, co najmniej jedna kopia poza serwerem produkcyjnym.
• Test odtworzenia — Raz na kwartał. Poproś o raport z ostatniego testu — z datą i wnioskami.
• Monitoring dostępności — Check co 1–5 minut, alert trafia do konkretnej osoby, a nie na ogólną skrzynkę biurową.
• Certyfikat SSL i domena — Alert o wygaśnięciu z 14-dniowym wyprzedzeniem. To samo dla domeny i rekordów DNS.
• Błędy 5xx i kolejka e-maili — Sprawdź, czy monitoring obejmuje logi błędów serwera oraz kolejkę wiadomości z zamówień — ciche niewysyłanie potwierdzeń to klasyczna awaria.
• Bezpieczeństwo — 2FA do panelu i do serwera, WAF, ograniczenie dostępu do /admin, przegląd uprawnień użytkowników i reakcja na podatności z CVE.
• Wydajność — Core Web Vitals (LCP, INP, CLS) oraz czas odpowiedzi koszyka i checkoutu mierzone cyklicznie, a nie raz przy wdrożeniu.
• Integracje — InPost, DPD, DHL, operatorzy płatności, ERP (Subiekt, Comarch Optima, WMS) — sprawdź, czy status API jest monitorowany i kto obsługuje zmiany po stronie dostawcy.
• Raport miesięczny — Liczba zgłoszeń według priorytetu, zużycie godzin z puli, wykonane aktualizacje, status kopii zapasowych, incydenty bezpieczeństwa.
• Ścieżka eskalacji — Nazwiska i kontakt do osób decyzyjnych po obu stronach oraz zapis o konsekwencjach przy niedotrzymaniu SLA.

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