Checklista audytu Magento po wdrożeniu

Zapisz stan wdrożenia i możliwość rollbacku

Bez punktu odniesienia trudno odtworzyć, co zmieniło się między działającą a uszkodzoną wersją.

• commit albo paczka wdrożona na produkcji
• wersja Magento / Adobe Commerce
• wersje modułów i motywu
• backup bazy i mediów
• sposób powrotu do poprzedniej wersji
• lista komend i migracji wykonanych podczas deployu

Tryb produkcyjny, kompilacja i statyczne zasoby

Produkcja powinna działać w odpowiednim trybie, z przygotowaną kompilacją i statycznymi assetami.

Nie uruchamiaj komend naprawczych „na próbę” bez backupu i diagnozy. Najpierw odczytaj stan, ścieżki i logi.

• bieżący tryb aplikacji
• wynik kompilacji DI
• obecność statycznych zasobów dla używanych locale i motywów
• błędy 404 CSS, JS i fontów
• zgodność cache bustingu
• czy produkcja nie generuje assetów dynamicznie przy pierwszym żądaniu

Cron i kolejki

Cron obsługuje wiele zadań: indeksowanie, e-maile, reguły, importy, eksporty i procesy modułów. Brak cron może nie być widoczny od razu. Sklep otwiera się, ale po kilku godzinach stany, indeksy, e-maile lub integracje przestają się aktualizować.

• czy crontab istnieje dla właściwego użytkownika
• czas ostatniego wykonania
• zaległe wpisy
• osobne grupy cron
• logi błędów
• czy kolejki mają aktywnych konsumentów
• czy restart procesu nie czyści niezakończonej pracy

Indexery

Sprawdź status każdego indexera, tryb aktualizacji przy zapisie albo według harmonogramu, zaległości oraz czas pełnego reindexu. W dużym katalogu nie uruchamiaj pełnego reindexu w godzinach szczytu bez oceny wpływu.

• status valid / invalid / working
• harmonogram cron dla trybu według harmonogramu
• blokady i procesy wiszące
• wzrost tabel changelog
• czas aktualizacji kategorii, cen i wyszukiwarki
• zgodność danych na froncie po zmianie produktu

Cache, sesje i CDN

Cache ma przyspieszać sklep, ale nie może serwować starej ceny, koszyka innego użytkownika ani nieaktualnych assetów.

Nie stosuj czyszczenia całego cache jako uniwersalnej naprawy. Najpierw ustal, który cache jest nieaktualny i dlaczego invalidacja nie zadziałała.

• status typów cache
• backend cache i sesji
• Varnish, Fastly albo CDN, jeśli występują
• cache prywatnych bloków
• nagłówki odpowiedzi
• invalidacja po zmianie produktu i ceny
• zachowanie po wylogowaniu i na kilku urządzeniach

Checkout od początku do końca

Wykonaj rzeczywisty zakup dla najważniejszych kombinacji. Sprawdź zamówienie w panelu, ERP lub BaseLinkerze, bramce płatniczej i e-mailu. Sam ekran „dziękujemy” nie potwierdza całego procesu.

• gość i klient zalogowany
• różne stawki VAT
• rabat albo kod promocyjny
• kilka metod dostawy
• płatność online i odroczona
• produkt prosty i wariantowy
• ostatnia sztuka
• anulowanie albo nieudana płatność

Integracje i idempotencja

Testuj awarię połączenia oraz ponowienie. Jedno zamówienie nie może utworzyć dwóch dokumentów po timeoucie — patrz diagnostyka błędów integracji API.

• źródło prawdy i częstotliwość
• mapa ID
• retry i ochrona przed duplikacją
• kolejka błędów
• monitoring ostatniego sukcesu

Katalog, warianty i dane

Porównaj próbkę z systemem źródłowym. Nie ograniczaj się do produktów wybranych przez wdrożeniowca.

• SKU i EAN
• warianty i konfiguracje
• ceny regularne, specjalne i grupowe
• stany i dostępność do sprzedaży
• kategorie i atrybuty filtrów
• zdjęcia
• status i widoczność
• zachowanie po imporcie masowym

SEO po wdrożeniu

Po migracji porównaj listę starych i nowych URL-i oraz logi 404. Nie przekierowuj wszystkich błędów na stronę główną.

• kody 200, 301 i 404
• canonicale
• robots i sitemapa
• title i meta
• nagłówki H1
• strony filtrów i wyszukiwarki
• paginacja
• przekierowania po migracji
• dane strukturalne
• indeksowalność kategorii i produktów
• brak przypadkowego noindex po stagingu

Logi, bezpieczeństwo i monitoring

Przejrzyj logi aplikacji, PHP, serwera, cron, kolejki i integracji. Usuń tryb developerski, publiczne debugi i dane dostępowe z repozytorium. Zweryfikuj uprawnienia plików, konto administratora i kopie zapasowe.

• błędy 5xx
• brak działania cron
• kolejka rosnąca powyżej progu
• nieudane płatności
• spadek liczby zamówień
• brak synchronizacji stanów
• błędy importu
• zajętość dysku i bazy

Raport powinien kończyć się kolejnością napraw

Nie wystarczy lista osiemdziesięciu problemów. Dla każdej pozycji potrzebny jest dowód, wpływ, plik albo moduł, rekomendacja, ryzyko wdrożenia i test odbioru.