Czym jest utrzymanie i opieka techniczna sklepu dla firmy

Utrzymanie i opieka techniczna sklepu to nie jedna usługa, a trzy warstwy odpowiedzialności. Warto rozdzielić je przed porównaniem ofert, bo „mam hosting” nie znaczy „mam opiekę”.

• Hosting – prąd i dysk. Serwer lub VPS działa, jest miejsce na pliki i bazy, maszyna odpowiada. Odpowiedzialność dostawcy hostingu zwykle kończy się na komunikacie „serwer pinguje”.
• Administracja serwerem. System operacyjny, PHP, MySQL/MariaDB, nginx/Apache, firewall, kopie zapasowe, aktualizacje pakietów. Tu siedzi większość przyczyn przestojów, których nie widać do pierwszej awarii.
• Opieka nad aplikacją sklepu. PrestaShop lub WooCommerce, moduły i wtyczki, szablon, integracje: bramka płatności, kurierzy, fakturowanie, ERP, feedy produktowe. Zgodność modułu z wersją sklepu sprawdzasz w dokumentacji deweloperskiej PrestaShop, a nie w opisie na marketplace.

Scenariusz, który zdarza się co kilka miesięcy: piątek 20:15, klient klika „Zapłać”, bramka zwraca błąd 500. Hosting odpowiada „serwer działa”, producent modułu płatności „po naszej stronie OK”, operator płatności „transakcja nie dotarła”. Bez jednej osoby odpowiedzialnej za całość zgłoszenie czeka do poniedziałku, a koszyk z porzuconymi zamówieniami rośnie. W umowie musi być zapisane, kto odbiera telefon i kto ma dostęp do serwera.

Są dwa modele rozliczenia. „Kupuję godziny” – np. 10 h miesięcznie rozliczanych w rejestrze czasu; sensowne, gdy masz wewnętrznego developera i potrzebujesz rąk do konkretnych zadań. „Kupuję efekt” – stała opłata za SLA, monitoring, kopie i aktualizacje; sensowne, gdy nie chcesz zarządzać technikaliami. Oba działają, ale mieszanie ich bez zapisu w umowie kończy się sporem, czy aktualizacja PrestaShop wchodzi w pakiet. Szersze omówienie tematu: utrzymanie i opieka techniczna sklepów Zamość – praktycznie.

Co realnie obejmuje opieka techniczna sklepu – 6 obszarów

Zanim porównasz ceny, poproś dostawcę o rozbicie oferty na sześć obszarów. Jeśli nie potrafi ich wymienić, prawdopodobnie sprzedaje hosting z ładniejszą nazwą. Przykład kompletnego pakietu utrzymania i opieki technicznej sklepów Świdnik pokazuje, jak taki podział wygląda w praktyce.

• Aktualizacje z testem regresji. Kolejność jest stała: kopia → staging → produkcja. Aktualizacja „na produkcji w poniedziałek rano” to najczęstsza przyczyna przestoju – moduł zgodny z PrestaShop 1.7 potrafi wywalić checkout na 8.x. Po wdrożeniu przechodzisz test: dodanie produktu, koszyk, kupon, płatność, mail potwierdzający.
• Monitoring z alertami, nie tylko wykres. Dostępność HTTP strony głównej i koszyka, test przejścia zamówienia, transakcja testowa w bramce, TTFB, CPU/RAM/dysk. Osobno alerty o wygasającym SSL (Let’s Encrypt odnawia co 90 dni) i domenie.
• Kopie zapasowe. Backup musi leżeć poza serwerem – S3, Backblaze B2, inne data center. Retencja: dzienna 7 dni, tygodniowa 4–8, miesięczna 12. Raz na kwartał test odtworzenia na staging. RAID chroni od awarii dysku, ale nie od ransomware, błędnego DROP TABLE ani usunięcia plików przez byłego pracownika.
• Bezpieczeństwo. WAF przed aplikacją, ograniczenie /admin do znanych IP lub basic auth, fail2ban na SSH, 2FA dla administratorów, skanowanie integralności plików. Jeśli sklep przyjmuje karty, operator płatności wymaga zgodności PCI DSS w zakresie po stronie sklepu (zwykle SAQ A/A-EP) – przestarzałe PHP to podważa.
• Wydajność. Core Web Vitals (LCP, INP, CLS), pełny cache, Redis/Memcached, CDN, czyszczenie tabel ps_connections i ps_guest, indeksy w bazie. Wolny LCP i wolny checkout to mniej zamówień, nie „tylko estetyka”.
• Drobny rozwój. Zmiana w szablonie, nowe pole w formularzu, moduł do faktur – z jasnym limitem godzin w pakiecie (np. 3 h/mies.) i stawką za nadwyżkę.

SLA i umowa: jak przeliczyć obietnice na godziny

SLA to dokument, w którym obietnica zamienia się w liczby. Zdanie „reagujemy szybko” nie ma wartości w sporze – wartość ma „potwierdzenie przyjęcia zgłoszenia w ciągu 4 godzin od wysłania na adres pomoc@…”. Trzy poziomy, które mają sens dla małych i średnich firm, wyglądają tak:

Kluczowe rozróżnienie: czas reakcji da się zagwarantować i powinien być zapisany liczbowo (kiedy dostajesz potwierdzenie i pierwszy opis działań). Czas naprawy zależy od przyczyny – jeśli błąd siedzi w module płatności, dostawca czeka na poprawkę producenta. Dlatego w umowie zapisuje się go jako „best effort” z obowiązkiem raportowania postępów co X godzin.

Definicja incydentu krytycznego musi być wypisana wprost, żeby nie było dyskusji o 20:15. Do tej kategorii wchodzą: sklep nie przyjmuje zamówień, płatności online nie działają, dane osobowe są zagrożone (wyciek, ransomware, dostęp obcej osoby do panelu), wygasł certyfikat SSL lub domena. Wszystko inne – błąd w szablonie, literówka w opisie kategorii, wolno działający raport – to zgłoszenie zwykłe.

Co musi znaleźć się w umowie: zakres (mapowany na sześć obszarów), kanał zgłoszeń (panel lub mail, nie Messenger), okno wsparcia (np. 8:00–16:00 vs 8:00–20:00), limit godzin w pakiecie, sposób rozliczania nadwyżki (stawka za godzinę ustalona z góry, nie „do uzgodnienia”), a także warunki wyjścia – lista dostępów, które dostawca przekazuje, format (menedżer haseł, klucze SSH) i termin (np. 14 dni). Bez tego ostatniego punktu zmiana dostawcy ciągnie się tygodniami. Więcej o konstrukcji takiej umowy piszemy przy okazji tematu SLA i umowa dla sklepów Łęczna.

Ile to kosztuje – widełki godzinowe i miesięczne dla MŚP

Zacznijmy od modelu rozliczenia. Standard na rynku to pakiet miesięczny z określoną liczbą godzin plus stawka za nadwyżkę. Nie „cennik z sufitu”, bo nikt uczciwie nie wyceni Twojego sklepu, dopóki nie policzy modułów, wersji PHP i tego, co siedzi w logach.

Widełki poniżej traktuj jako punkt odniesienia do rozmowy, nie jako cennik konkretnego dostawcy. Kwoty są netto i różnią się w zależności od regionu oraz specjalizacji — zawsze proś o ofertę na piśmie po audycie.

Model	Godziny / mies.	Co realnie obejmuje	Widełki netto
Pakiet podstawowy	4–6 h	monitoring, kopie, aktualizacje rdzenia, drobna zmiana	400–900 zł
Pakiet standardowy	8–12 h	plus aktualizacje modułów na stagingu, zmiany CSS/szablonu	900–1 800 zł
Pakiet rozszerzony	16–24 h	plus integracje, ERP, moduły własne, raport miesięczny	1 800–3 500 zł
Nadwyżka poza pakietem	—	prace doraźne, interwencje	130–250 zł / h

Co podnosi koszt:

• moduły pisane na zamówienie, bez dokumentacji i repozytorium — każda poprawka to czytanie cudzego kodu od zera,
• integracja z ERP (Subiekt, Comarch, Wapro) — synchronizacja stanów i faktur wymaga testów po obu stronach,
• dedykowany VPS z nietypową konfiguracją: własny nginx, Redis, Varnish,
• szablon edytowany bezpośrednio na produkcji, bez staged changes,
• 40+ wtyczek, z czego połowa nieaktualizowana od dwóch lat.

Co obniża koszt:

• porządek w modułach — wiadomo, co jest aktywne i po co,
• jeden operator płatności i jeden kurier zamiast trzech nakładających się integracji,
• aktualny stack: PHP 8.1+, MySQL 8, wersja sklepu objęta wsparciem,
• brak zaległości — dwa lata nieaktualizowanych wtyczek to nie „10 minut roboty”, tylko projekt na kilka dni.

Koszt alternatywny. Sklep robi w szczycie 30 zamówień na godzinę, średnia wartość zamówienia 180 zł. Godzina przestoju to około 5 400 zł utraconego obrotu — plus klienci, którzy nie wrócą. Godzina opieki to 130–250 zł. Jeśli pakiet kosztuje 1 200 zł miesięcznie, wystarczy, że raz w miesiącu skróci jedną awarię o pół godziny. Sposób rozliczenia i zakres pakietu opisujemy szerzej w tekście o utrzymaniu i opiece technicznej sklepów Zamość.

5 awarii, które zdarzają się naprawdę – i jak je skrócić

Nie chodzi o to, czy awaria wystąpi. Chodzi o to, jak szybko sklep wróci do sprzedaży. Poniżej pięć przypadków z realnych wdrożeń.

1. Zapełniony dysk na VPS. Pierwsze objawy: błędy zapisu zamówień, problemy z zapisem sesji, logi rosnące po kilka GB miesięcznie. MySQL potrafi przejść w tryb tylko do odczytu i zamówienia przestają się zapisywać, choć strona nadal się otwiera. Reakcja: alert na progu 80% zajętości, nie 95%, rotacja logów (logrotate), monitoring przez Netdata, Zabbix albo panel hostingu.
2. Wygasły certyfikat SSL lub domena. Przeglądarka pokazuje ostrzeżenie „Niebezpieczna”, a klient wraca do wyników wyszukiwania. Konwersja spada wtedy niemal do zera, bo nikt nie wpisze danych karty na ostrzeżonej stronie. Reakcja: przypomnienia 30/14/7 dni przed wygaśnięciem, włączone autorenew i kontrola, czy nie zmienił się rekord DNS.
3. Konflikt po aktualizacji modułu. Typowy scenariusz: moduł płatności aktualizuje się w nocy, rano koszyk nie przechodzi do podsumowania. Reakcja: staging, kopia bazy przed każdą aktualizacją i rollback w kilkanaście minut. Zmiana, która nie przeszła na stagingu, nie idzie na produkcję.
4. Przerwana integracja z kurierem lub API płatności. Objaw: zamówienia wiszą w statusie „Oczekiwanie na płatność”, nie generują się etykiety wysyłkowe, magazyn pakuje ręcznie. Reakcja: monitoring odpowiedzi API, ponawianie żądań i jasno wskazane miejsce, gdzie sprawdza się logi.
5. Zalew botów i obciążenie CPU. Formularz kontaktowy albo wyszukiwarka przyjmuje tysiące żądań, CPU dobija do 100% i sklep zwalnia dla wszystkich. Reakcja: rate limiting w nginx, ochrona formularza (captcha, honeypot) i osobna kolejka dla zadań w tle.

Awaria	Pierwszy widoczny objaw	Co najbardziej skraca przestój
Zapełniony dysk	błędy zapisu zamówień	alert na 80% + rotacja logów
SSL lub domena	ostrzeżenie w przeglądarce	przypomnienia 30/14/7 dni, autorenew
Konflikt po aktualizacji	koszyk nie przechodzi dalej	staging + kopia bazy + rollback
Integracja z kurierem/API	brak etykiet, wiszące statusy	monitoring API i ponawianie żądań
Zalew botów	CPU 100%, wolne ładowanie	rate limiting + ochrona formularza

W każdym z tych przypadków czas skraca nie „szybki admin”, a wcześniej ustawione alerty, staging i kopia. Reakcja bez przygotowania to zwykle 2–4 godziny pracy, z przygotowaniem — 15–40 minut. Czas reakcji i zakres zgłoszeń powinny być zapisane w umowie; jak to wygląda w praktyce, opisujemy przy okazji umowy SLA dla sklepów w Łęcznej. Warto też wiedzieć, gdzie dostawca sprawdza składnię zmian — podstawą jest dokumentacja developerska PrestaShop, zwłaszcza rozdziały o modułach i override.

Zamość i wschodnia Polska: kiedy lokalny partner techniczny naprawdę pomaga

Lokalność bywa przeceniana. Prawda jest taka, że 80–90% pracy przy utrzymaniu sklepu wykonuje się zdalnie: przez SSH, panel hostingu i repozytorium kodu. Ale są sytuacje, w których bycie na miejscu zmienia bardzo dużo.

Kiedy lokalność ma znaczenie:

• odbiór i pierwsza konfiguracja sprzętu — serwer w szafie, terminal płatniczy, drukarka etykiet,
• integracja z lokalnym systemem magazynowym, jeśli pracuje na nim Twój zespół i trzeba zgrać pola oraz stany,
• awaria krytyczna w środku dnia — wizyta w 1–2 godziny zamiast kilku godzin konsultacji telefonicznej,
• kontakt telefoniczny w tej samej strefie czasowej i tych samych godzinach pracy. Różnica między „odbieramy 9:00–17:00” a wsparciem kończącym się o 16:00 czasu zachodniego bywa odczuwalna, zwłaszcza gdy problem pojawia się w piątek.

Kiedy lokalność nie ma znaczenia:

• praca na serwerze, aktualizacje, kopie zapasowe,
• code review i poprawki w module,
• konfiguracja CDN, cache i optymalizacja Core Web Vitals.

To wszystko robi się zdalnie i zdalnie wychodzi zwykle szybciej, bo nie traci się czasu na dojazd. Dobry partner zdalny z Lublina, Rzeszowa czy Warszawy będzie lepszy niż słaby partner z Zamościa.

Zadanie	Czy lokalność pomaga	Dlaczego
Konfiguracja serwera, aktualizacje	Nie	praca przez SSH i panel
Setup sprzętu w siedzibie	Tak	dojazd, podłączenie, test na miejscu
Awaria krytyczna	Częściowo	wizyta 1–2 h vs praca zdalna
Integracja z lokalnym ERP/magazynem	Tak	wspólne testy z Twoim zespołem
Optymalizacja wydajności	Nie	wszystko dzieje się zdalnie

Praktyczna wskazówka. Poproś dostawcę o nazwiska osób z dostępem produkcyjnym do Twojego sklepu i wpisz je do umowy. Ustal też tryb przekazywania dostępów: menedżer haseł albo klucze SSH, nigdy hasło wysłane mailem. Zapytaj, co dzieje się przy rotacji personelu — czy dostępy są odbierane i przekazywane w ciągu 24 godzin. Warto porównać, jak wygląda to u dostawców obsługujących podobne firmy w regionie, np. w umowie SLA dla sklepów w Lublinie.

Pierwsze 30 dni współpracy – co powinno się wydarzyć

Dobry dostawca nie zaczyna od faktury, tylko od audytu. Pierwszy miesiąc ma jeden cel: najpierw wiedzieć, co jest w sklepie, potem cokolwiek zmieniać. Jeśli w tym okresie nikt nie prosi cię o dostępy do serwera, bazy danych i panelu płatności — nie ma czego utrzymywać.

Dzień 1–3: audyt startowy. Inwentaryzacja modułów: nazwa, wersja, autor, data ostatniej aktualizacji i zgodność z twoją wersją sklepu — sprawdzasz to choćby w dokumentacji dla deweloperów PrestaShop. Do tego wersja PHP i MySQL, bo niezgodność z nowszym PHP to najczęstsza przyczyna białej strony po cichej aktualizacji hostingu. Kopie zapasowe weryfikuje się przez próbę odtworzenia: kopia na środowisku testowym, sprawdzenie, czy pliki i baza pasują do siebie. Backup, którego nikt nie odtworzył, to nie backup. Sprawdź też dostęp do SSH, SFTP, panelu bazy, DNS, GA4 i Search Console.

Dzień 4–10: przejęcie i monitoring. Hasła lądują w menedżerze haseł, konta są imienne (nie „admin”), SSH działa na kluczach, nie na haśle. Monitoring obejmuje: dostępność co 60 sekund, kody 5xx, czas odpowiedzi, ważność certyfikatu SSL, wolne miejsce na dysku i błędy PHP w logach. Alert trafia na SMS i e-mail do konkretnej osoby, z kanałem zapasowym. Równolegle powstaje środowisko testowe: kopia sklepu na subdomenie, z wyłączonym indeksowaniem i wyłączonymi płatnościami.

Dzień 11–30: pierwsze zmiany i porządki. Aktualizacje wchodzą najpierw na staging, potem na produkcję — w oknie o niskim ruchu, ze świeżą kopią pod ręką. Porządki: moduły bez wsparcia, stare szablony, wtyczki nieaktywne, ale nadal leżące w katalogu (część z nich ma znane luki). Raport startowy zawiera listę ryzyk, np. „moduł X nietknięty od 2019 roku, autor nie odpowiada”.

O co zapytać przed podpisaniem umowy: o wzór raportu miesięcznego — co zrobiono, ile godzin zużyto, co zaplanowano. Bez tego płacisz abonament i nie wiesz za co. Zapisy o reakcji i karach znajdziesz w materiale o SLA i umowie na opiekę nad sklepem, a cały proces opisujemy w artykule o utrzymaniu i opiece technicznej sklepów Zamość.

Kiedy opieka techniczna się nie opłaca

Opieka techniczna to abonament, więc uczciwy dostawca powinien umieć powiedzieć, kiedy nie ma to sensu. Trzy sytuacje, w których przepalasz budżet.

1. Sklep bez sprzedaży albo w zawieszeniu. Jeśli od miesięcy nie ma zamówień, nie potrzebujesz administracji serwerem. Wystarczy tani hosting, darmowy certyfikat SSL i kopia zapasowa trzymana poza serwerem — np. w Backblaze B2 albo S3, kilka złotych miesięcznie. Aktualizacje robisz raz na kwartał, po zrobieniu kopii. Płacenie 400–800 zł netto miesięcznie za pilnowanie sklepu bez ruchu to wydatek bez zwrotu.

2. Sklep w pełni SaaS. Na platformach hostowanych serwerem, aktualizacjami, kopiami i SSL zajmuje się operator. Kupujesz wtedy pracę nad funkcjami, nie utrzymanie. Uwaga: nie wszystko znika — konfiguracja integracji z kurierami i płatnościami, aplikacje dociążające szablon, jakość zdjęć wpływająca na LCP nadal są po twojej stronie. Ale nie płacisz za administrację infrastrukturą, bo jej nie posiadasz.

3. Masz wewnętrznego dewelopera. Jeśli ktoś na etacie zna sklep i robi zmiany, nie potrzebujesz abonamentu na całość. Potrzebujesz wsparcia punktowego: pakietu godzin ponad etat albo stawki godzinowej z gwarancją reakcji, gdy problem dotyczy serwera, hostingu lub płatności — czyli warstwy, której etatowy deweloper zwykle nie dotyka. Uważaj na umowy z 12-miesięcznym minimalnym zobowiązaniem i rozliczaniem niezużytych godzin.

Jedna rzecz działa zawsze, niezależnie od modelu: kopia zapasowa, którą ktoś realnie odtworzył choć raz. Jeśli tego nie ma, problemem nie jest pytanie „czy opieka się opłaca”, tylko brak podstaw do jakiegokolwiek planu naprawczego. Od czego zacząć porządkowanie, opisaliśmy w artykule o utrzymaniu i opiece technicznej sklepów Chełm.

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

Lista kontrolna do odklikania

• Zakres opieki na piśmie — Przed podpisaniem: sprawdź, czy umowa wymienia konkretne czynności (aktualizacje, kopie, monitoring, bezpieczeństwo), a nie ogólne „utrzymanie sklepu”.
• Kanał zgłoszeń — Ustal, czy zgłoszenia idą mailem, przez panel czy telefonem i kto je odbiera po 17:00 oraz w weekend.
• Czas reakcji i okno wsparcia — Porównaj deklarację z tabelą SLA: ile godzin na reakcję, w jakich godzinach, czy incydent krytyczny ma osobny poziom.
• Limit godzin i nadwyżka — Zapytaj, ile godzin wchodzi w pakiet, co dzieje się po przekroczeniu limitu i jaka jest stawka za nadwyżkę.
• Miejsce kopii zapasowych — Poproś o potwierdzenie, że kopie leżą poza serwerem produkcyjnym, oraz o opis retencji dziennej, tygodniowej i miesięcznej.
• Test odtworzenia kopii — Sprawdź, czy dostawca wykonuje go raz na kwartał i czy dostajesz z niego krótkie potwierdzenie.
• Zakres monitoringu — Zapytaj, czy monitorowane są: dostępność HTTP, czas odpowiedzi, poprawność koszyka i płatności, obciążenie CPU/RAM/dysku, wygasające certyfikaty SSL i domeny.
• Staging — Sprawdź, czy istnieje kopia sklepu do testów i czy przed aktualizacją jest odświeżana z produkcji.
• Depozyt dostępów — Zweryfikuj, czy masz DNS, panel hostingu, konto administratora, repozytorium kodu i klucze API do płatności oraz kurierów.
• Wersje aplikacji i PHP — Sprawdź wersję PrestaShop lub WooCommerce, PHP i liczbę aktywnych modułów – dwa lata zaległych aktualizacji to główny powód wysokich kosztów.
• Wydajność i Core Web Vitals — Zrób pomiar przed startem współpracy i po pierwszych zmianach (cache, CDN, optymalizacja bazy), żeby mieć punkt odniesienia.
• Bezpieczeństwo — Potwierdź konfigurację WAF, limitów na /admin, uwierzytelniania dwuskładnikowego i zakresu zgodności z wymogami operatora płatności po stronie sklepu.
• Raport miesięczny — Ustal, co dostajesz na koniec miesiąca: lista wykonanych prac, zużyte godziny, incydenty i wnioski.
• Warunki wyjścia — Przed podpisaniem: zapisz, w jakim terminie i w jakiej formie dostawca przekazuje dostępy oraz dokumentację po zakończeniu umowy.

Najczęściej zadawane pytania

Źródła i materiały

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