SLA dla Magento: co musi zawierać dobra umowa wsparcia?

Czym różni się realne SLA dla Magento od zwykłej obietnicy pomocy?

Dobra umowa SLA (Service Level Agreement) dla Magento to precyzyjny dokument techniczno-prawny definiujący maksymalny czas reakcji na awarię, czas naprawy, dostępność środowiska oraz odpowiedzialność finansową agencji za przestój. Zwykły helpdesk reaguje wtedy, gdy programista skończy inne zadanie, natomiast rzetelne SLA i utrzymanie Magento gwarantuje natychmiastowe podjęcie prac w oparciu o sztywne priorytety błędów. Bez precyzyjnie spisanych metryk podpisujesz po prostu abonament na „święty spokój”, który kończy się przy pierwszym niedzielnym padzie procesu składania zamówień.

W ekosystemie Magento 2.4.7 na stacku z PHP 8.3, OpenSearch 2.x, Redisem i RabbitMQ nie ma miejsca na domysły. Jeśli po wdrożeniu modułu płatności checkout wyrzuca błąd 500 albo baza MySQL blokuje się przez deadlock przy transakcjach walutowych, umowa musi jasno wskazywać, kto wstaje o 22:00, jak szybko loguje się na serwer przez SSH i kiedy przywraca stabilność platformy.

Jak poprawnie sklasyfikować priorytety błędów (P1 do P4)?

Podstawowym błędem w umowach serwisowych jest brak jasnego rozróżnienia między usterką krytyczną a drobną modyfikacją szablonu. Agencje lubią wrzucać wszystko do jednego worka „czas reakcji do 24 godzin”, co w przypadku martwego koszyka oznacza tysiące złotych strat na godzinę. Prawidłowy podział w umowie wsparcia Magento powinien wyglądać następująco:

• P1 (Krytyczny / Awaria blokująca): Całkowita niedostępność sklepu, błąd 500 na stronie głównej, brak możliwości przejścia przez checkout, awaria integracji z bramką Przelewy24 lub brak możliwości płatności BLIK, padnięty silnik OpenSearch uniemożliwiający listowanie produktów. Gwarantowany czas reakcji: do 1–2 godzin (w trybie 24/7/365 lub 8/5, zależnie od pakietu), czas obejścia problemu (workaround): do 4 godzin.
• P2 (Wysoki / Awaria częściowa): Błąd uniemożliwiający realizację kluczowych procesów biznesowych, ale z działającą sprzedażą. Przykłady: awaria synchronizacji zamówień z Comarch ERP Optima lub Subiekt GT/nexo, niedziałające powiadomienia mailowe (SMTP drop), błąd generowania etykiet InPost ShipX. Gwarantowany czas reakcji: do 4 godzin.
• P3 (Średni / Usterka standardowa): Niedziałający filtr w warstwie Hyvä Theme, błąd w module cross-sell od Mirasvit czy Mageworx, rozjechany layout na urządzeniach z iOS, problem z naliczaniem punktów lojalnościowych w module Amasty. Czas reakcji: do 8–16 godzin roboczych.
• P4 (Niski / Zgłoszenie serwisowe): Zmiana baneru, aktualizacja treści CMS, konfiguracja nowej reguły promocji w katalogu, drobne poprawki CSS. Czas reakcji: do 24–48 godzin roboczych.

Co z integracjami: KSeF, Comarch ERP Optima, Subiekt nexo i InPost?

W polskich realiach e-commerce Magento rzadko działa w izolacji. Sklep to centrum operacyjne spięte szynami danych z systemami ERP, magazynami WMS, kurierami i bankami. Większość awarii nie wynika z samego rdzenia Magento, lecz z desynchronizacji na styku API.

Umowa SLA musi jednoznacznie określać zakres odpowiedzialności programistów za integracje zewnętrzne:

1. Krajowy System e-Faktur (KSeF) i biała lista VAT: Czy zespół wsparcia monitoruje kolejki RabbitMQ odpowiedzialne za wysyłkę e-faktur i weryfikację rachunków bankowych? Umowa powinna precyzować, jak szybko developer weryfikuje logi w var/log/, gdy token autoryzacyjny KSeF wygaśnie lub API Ministerstwa Finansów zwróci kod błędu 400/429.
2. Integracje ERP (Comarch Optima, Subiekt nexo, Enova): Jeśli integrator oparty na cronie zawiesi się przez niespójny format XML/JSON w kartotece towarowej, SLA musi wymuszać analizę blokady kolejki w ciągu zdefiniowanego czasu P2. Samo zrzucenie winy na „błąd po stronie ERP” bez weryfikacji payloadu to standardowa wymówka, przed którą umowa musi Cię chronić.
3. Allegro REST API: Przy intensywnej sprzedaży wielokanałowej opóźnienia w synchronizacji stanów magazynowych prowadzą do sprzedaży towaru, którego nie masz na stanie. SLA powinno obejmować monitoring zadań crona (bin/magento cron:run) oraz automatyczne alerty przy przekroczeniu limitów zapytań (rate limits).

Jakie procedury techniczne i deploymentowe musi gwarantować zespół?

Nie pozwól, aby prace serwisowe były prowadzone bezpośrednio na serwerze produkcyjnym (tzw. cowboy coding). W SISL każda zmiana w kodzie przechodzi przez rygorystyczny proces CI/CD, a umowa SLA powinna te standardy formalizować. Zwróć uwagę, czy umowa zawiera następujące zapisy techniczne:

Wszelkie prace programistyczne, poprawki błędów oraz instalacje patchy bezpieczeństwa (np. Adobe Security Bulletin) muszą być wdrażane w pierwszej kolejności na środowisku Staging/UAT, testowane automatycznie, a następnie wdrażane na produkcję bez przerw w działaniu sklepu (Zero-Downtime Deployment).

W umowie powinny znaleźć się bezpośrednie odniesienia do dobrych praktyk Magento 2:

• Wykonywanie kompilacji kodu (bin/magento setup:di:compile) oraz generowania assetów statycznych (bin/magento setup:static-content:deploy) w kontenerach budujących, a nie na żywym organizmie produkcyjnym.
• Czyszczenie cache (bin/magento cache:flush) z zachowaniem działania cache pełnostronicowego (Varnish / Fastly / Redis), aby uniknąć nagłego skoku obciążenia CPU (tzw. cache stampede).
• Cykliczne audyty logów błędów (exception.log, system.log, debug.log) w celu eliminacji powtarzających się zapytań SQL spowalniających bazę.
• Wdrażanie kwartalnych aktualizacji bezpieczeństwa Magento (Quality Patches i Security Releases) w ramach stałego budżetu godzinowego.

Ile kosztuje utrzymanie Magento 2 i jak rozliczać pakiety godzinowe?

Na polskim rynku e-commerce koszty wsparcia Magento zależą od skali biznesu, wielkości bazy produktów oraz stopnia customizacji kodu. Ceny roboczogodziny doświadczonego software house'u kształtują się obecnie w granicach 190 – 350 PLN netto (lub 60 – 90 EUR przy rozliczeniach zagranicznych).

Umowy SLA funkcjonują w dwóch głównych modelach:

• Retainer (ryczałt gotowościowy + pula godzin): Płacisz stałą kwotę miesięczną (np. 3 000 – 8 000 PLN netto) za samą gwarancję czasów reakcji P1/P2 i rezerwację mocy przerobowych zespołu, w czym zawarty jest pakiet 15–40 godzin roboczych na bieżące prace programistyczne. U nas w projektach dbamy o to, aby niewykorzystane godziny z pakietu przechodziły częściowo na kolejny miesiąc (tzw. rollover do 30 dni) lub mogły być wykorzystane na audyty wydajnościowe.
• Time & Material z minimalną opłatą gotowościową: Płacisz niższą opłatę bazową za sam monitoring i gwarancję SLA, a każda przepracowana godzina nad bugfixem czy rozwojem rozliczana jest na podstawie raportów z systemu Jira / Toggl.

Uważaj na zapisy o zaokrąglaniu czasu pracy. Uczciwa umowa przewiduje rozliczanie z dokładnością do 15 minut, a nie pełnych godzin za jednominutowy restart usługi OpenSearch czy odblokowanie kolejki zamówień.

Jak zabezpieczyć się przed wyłączeniami odpowiedzialności i karami umownymi?

Umowa SLA bez kar umownych jest jedynie deklaracją dobrych chęci. Jeśli awaria P1 trwa 6 godzin w Black Friday, a agencja nie podjęła działań w ciągu gwarantowanych 60 minut, powinieneś mieć prawo do naliczenia konkretnych kar finansowych (np. obniżenie opłaty abonamentowej o 10-20% za każdy przypadek przekroczenia czasu reakcji).

Zwróć również uwagę na zapisy dotyczące własności intelektualnej i dostępu do kodu. Wszelkie poprawki, skrypty migracyjne i moduły tworzone w ramach SLA muszą przechodzić na własność Twojej firmy wraz z momentem opłacenia faktury. Masz prawo do pełnego wglądu w repozytorium (GitLab/GitHub) oraz logi systemu deploymentu.

Szukasz partnera, który przejmie techniczny ciężar utrzymania Twojego sklepu bez korporacyjnego żargonu i zbędnych pośredników? Sprawdź nasze podejście i napisz do nas — przeanalizujemy Twój stack technologiczny i zaproponujemy SLA dopasowane do realnego wolumenu zamówień.