Po uruchomieniu platformy pytanie „kto za to odpowiada?” wraca przy pierwszej poważniejszej awarii. Utrzymanie ma sens wtedy, gdy z góry wiadomo, kto reaguje, co ma pierwszeństwo i co dzieje się, gdy problem dotyczy checkoutu, płatności albo integracji odpowiedzialnej za przesyłanie zamówień.
Prowadzimy stałe utrzymanie i rozwój platform Magento. Odpowiadamy za ciągłość działania i incydenty, realizujemy bieżące prace rozwojowe albo wspieramy istniejący zespół klienta tam, gdzie potrzebna jest głębsza specjalizacja Magento.
Na pierwszej rozmowie poznamy Magento, obecny model wsparcia i znaczenie platformy dla biznesu. Na tej podstawie określimy, jaki zakres odpowiedzialności i model współpracy mają sens.
Odpowiedzialność
Zmiana bannera i krytyczna poprawka bezpieczeństwa nie powinny czekać w tej samej kolejce. Podobnie błąd na pojedynczej stronie produktu nie może mieć tego samego priorytetu co niedziałający checkout, brak możliwości zalogowania klientów B2B czy zatrzymane przesyłanie zamówień do ERP.
Dlatego utrzymanie platformy to dla nas coś więcej niż realizacja kolejnych zgłoszeń.
Pierwszym celem jest jasny sposób reakcji, gdy pojawia się problem. Drugim - stopniowe ograniczanie liczby takich sytuacji przez aktualizacje, monitoring, poprawę najbardziej ryzykownych obszarów i świadome zarządzanie długiem technicznym.
Dobrze utrzymywane Magento z czasem staje się bardziej przewidywalne, zamiast przyzwyczajać organizację do gaszenia pożarów.
Budżet operacyjny
W stałej współpracy rozdzielamy dwa rodzaje pracy. Oba obszary działają równolegle, ale mają osobne przeznaczenie i zasady wykorzystania.
Obejmuje gotowość zespołu, obsługę incydentów, aktualizacje typu patch i security oraz działania potrzebne do przywrócenia prawidłowego funkcjonowania platformy.
Służy planowanym zmianom: konfiguracji, developmentowi, konsultacjom technicznym, usprawnieniom i kolejnym elementom roadmapy.
Rozdzielamy oba obszary z praktycznego powodu: awaria nie konsumuje wtedy budżetu przeznaczonego na rozwój platformy.
Zależnie od wybranego pakietu wsparcia niewykorzystane godziny mogą przejść na kolejne miesiące (maksymalnie przez trzy miesiące). Po wykorzystaniu limitu informujemy przed rozpoczęciem dodatkowych prac. Co miesiąc przekazujemy zestawienie: listę zgłoszeń, czas poświęcony na każde z nich i stan wykorzystania puli.
Większe modernizacje nie mieszczą się automatycznie w miesięcznym pakiecie. Upgrade dużej wersji Magento, przebudowa frontendu albo nowa integracja są planowane jako osobny projekt.
Klasyfikacja zgłoszeń
Każde zgłoszenie klasyfikujemy według jego wpływu na działanie platformy.
Sklep albo kluczowy proces sprzedażowy nie działa: brak możliwości składania lub opłacania zamówień, masowy błąd uniemożliwiający korzystanie z platformy, podejrzenie incydentu bezpieczeństwa.
Istotna funkcjonalność działa nieprawidłowo, ale platforma nadal sprzedaje. Poważne pogorszenie wydajności, problem dotyczący dużej grupy klientów albo ważnego procesu administracyjnego.
Błędy niekrytyczne, pojedyncze przypadki, problemy z dostępnym obejściem, usterki niezatrzymujące sprzedaży.
Nowe funkcje, usprawnienia, konfiguracje i zaplanowane prace rozwojowe.
Priorytet ustalamy na podstawie rzeczywistego wpływu problemu na sprzedaż i dostępność platformy. W sytuacjach niejednoznacznych klasyfikację konsultujemy z klientem, tak aby zgłoszenia krytyczne rzeczywiście zachowywały pierwszeństwo.
SLA
Określa, jak szybko po rejestracji zgłoszenia rozpoczynamy jego obsługę: przekazujemy merytoryczną odpowiedź z klasyfikacją priorytetu i kolejnymi krokami oraz faktycznie podejmujemy pracę. Automatyczne potwierdzenie z systemu nie jest reakcją.
Dotyczy przywrócenia kluczowego procesu albo wdrożenia bezpiecznego rozwiązania tymczasowego. Pełna naprawa może wymagać więcej czasu, jeśli problem wymaga zmiany kodu, testów regresji i wdrożenia w kolejnym release.
Nie obiecujemy jednego „czasu naprawy” dla każdej awarii. Określamy gwarantowaną reakcję oraz sposób działania zespołu w zależności od klasy incydentu.
Jak mierzymy SLA
Czas reakcji liczymy od rejestracji zgłoszenia w naszym systemie zgłoszeniowym. Bieg czasu może zostać wstrzymany, gdy rozwiązanie problemu wymaga działania lub informacji po stronie klienta albo gdy przyczyna leży w usłudze zewnętrznej pozostającej poza naszą kontrolą.
Szczegółowe zasady liczenia czasu, wymagane informacje w zgłoszeniu oraz wyłączenia SLA określamy w umowie.
Utrzymanie techniczne
Magento nie pozostaje przez lata tym samym systemem. Pojawiają się poprawki bezpieczeństwa, nowe wersje Magento i PHP, zmiany bibliotek, modułów i usług zewnętrznych.
Bieżący patch management i aktualizacje bezpieczeństwa są częścią utrzymania. Za łatkę krytyczną uznajemy oficjalną poprawkę oznaczoną przez producenta jako krytyczna (CVSS 9.0 i wyżej) lub o statusie Priority 1. Terminy wdrożenia poprawek krytycznych i pozostałych są określone w umowie i mierzalne.
Większe upgrade’y Magento planujemy osobno, ponieważ wymagają weryfikacji customowego kodu, zgodności modułów i testów regresji.
Celem jest niedopuszczenie do sytuacji, w której sklep przez kilka lat pozostaje na nieaktualnym stosie, a każda kolejna aktualizacja staje się dużym i ryzykownym projektem.
Znaczna część incydentów w Magento wykorzystuje znane podatności, dla których poprawka istniała wcześniej. Dla platform wymagających wyższego poziomu ochrony rozszerzamy utrzymanie o aktywny monitoring bezpieczeństwa.
Część narzędzi wymaga osobnej licencji po stronie klienta - informujemy o tym na etapie oferty.
Pełny obraz systemu
Użytkownik zgłasza, że kategoria ładuje się bardzo długo. Źródłem może być kod Magento, ale równie dobrze baza danych, indeksowanie albo sposób importowania danych.
Produkt nie pojawia się w sklepie. Problem leży czasem w synchronizacji z ERP albo PIM.
Klient nie widzi aktualnego statusu zamówienia. Frontend działa prawidłowo, ale proces wymiany danych zatrzymał się w kolejce.
Dlatego przy utrzymaniu złożonych platform patrzymy na cały system, a nie wyłącznie na kod sklepu. Pracujemy z bazami MySQL i MariaDB, Redis, Varnish, OpenSearch i Elasticsearch, RabbitMQ oraz integracjami z ERP, PIM, CRM i systemami dedykowanymi.
Współpracujemy z administratorami lub dostawcą infrastruktury klienta. Jeśli potrzebne jest wsparcie po naszej stronie, pomagamy w diagnostyce, konfiguracji i optymalizacji środowiska.
Przejęcie utrzymania
Nie trzeba być naszym klientem wdrożeniowym, żeby przekazać nam utrzymanie Magento.
Przed objęciem platformy SLA poznajemy projekt: kod, customowe moduły, integracje, środowiska, deployment i podział odpowiedzialności między systemami. Nie chodzi o wielomiesięczny audyt, tylko o to, żeby nie deklarować czasów reakcji dla systemu, którego stanu jeszcze nie znamy.
Jeśli platforma jest niestabilna, błędy wracają, a stan techniczny projektu jest trudny do oceny, lepszym pierwszym krokiem jest Ratowanie i przejęcie projektu Magento . Po stabilizacji projekt przechodzi do regularnego modelu utrzymania.
Dopasowanie
Zwykły model utrzymania będzie głównie obsługiwał kolejne awarie. Lepszym początkiem jest diagnoza, przejęcie i stabilizacja.
Ratowanie projektów Magento →Jeśli sklep działa funkcjonalnie, ale problemem są TTFB, Core Web Vitals, baza, cache lub indeksowanie, właściwym punktem wejścia jest osobny projekt optymalizacyjny.
Optymalizacja wydajności Magento →Nie sprzedajemy samej przestrzeni serwerowej jako usługi supportowej. Współpracujemy z dostawcą infrastruktury klienta albo pomagamy zaprojektować i zoptymalizować środowisko Magento.
Pytania
Tak. Przed objęciem platformy regularnym SLA poznajemy jej kod, integracje, środowiska i sposób wdrażania zmian. Jeśli projekt wymaga większej stabilizacji, pierwszym etapem jest Rescue.
Utrzymanie odpowiada za ciągłość działania, incydenty i prace eksploatacyjne. Pakiet godzin służy planowanym zmianom i developmentowi. Oba modele działają równolegle, dzięki czemu awarie nie konsumują budżetu przeznaczonego na rozwój.
To zależy od wybranego pakietu. Oferujemy pakiety, w których godziny przechodzą na kolejne miesiące, maksymalnie przez trzy miesiące. Co miesiąc przekazujemy zestawienie wykonanych prac i stanu wykorzystania puli.
Dla incydentów krytycznych udostępniamy ścieżkę awaryjną poza standardowymi godzinami wsparcia. Jeśli platforma wymaga gwarantowanego SLA 24/7, musi to być osobno zaprojektowany model obsługi.
Ostateczna klasyfikacja należy do nas, w uzasadnionych przypadkach po konsultacji z klientem. Priorytet wynika z wpływu na sprzedaż i dostępność.
Bieżące poprawki i aktualizacje bezpieczeństwa są częścią utrzymania. Większe aktualizacje wersji planujemy jako osobne prace, ponieważ wymagają testów regresji, weryfikacji modułów i często dostosowania customowego kodu.
Tak. Działamy jako wsparcie specjalistyczne przy trudniejszych problemach, integracjach, performance, aktualizacjach czy decyzjach architektonicznych. Nie każdy taki przypadek musi oznaczać zmianę obecnego wykonawcy.
Wspieramy diagnostykę, konfigurację i optymalizację środowiska Magento albo współpracujemy z administratorem klienta. Dokładny podział odpowiedzialności ustalamy na początku współpracy.
Opisz obecny model wsparcia, krytyczne procesy i problemy, które pojawiają się najczęściej.
Odezwiemy się w ciągu 12 godzin od wysłania formularza.