Nie klikaj kolejnych aktualizacji licząc, że jedna naprawi poprzednią. Każda następna zmiana zwiększa liczbę możliwych przyczyn i może nadpisać pliki potrzebne do odtworzenia.
1. Zatrzymaj dalsze zmiany
Zapisz godzinę awarii, ostatnią wykonaną aktualizację i widoczny komunikat. Jeżeli strona przetwarza płatności, zgłoszenia lub dane klientów, rozważ bezpieczny tryb serwisowy zamiast pozostawienia częściowo działającego procesu.
2. Wykonaj kopię obecnego, nawet uszkodzonego stanu
Kopia sprzed awarii służy do powrotu. Kopia po awarii służy do analizy. Obie są potrzebne. Nie nadpisuj jedynego działającego backupu nową automatyczną kopią.
3. Sprawdź zgodność wersji
Aktualizacja dodatku może wymagać nowszego PHP, innej wersji CMS lub biblioteki. Zmiana samego PHP może z kolei ujawnić stary kod. Porównaj wymagania wszystkich elementów, które zmieniły się w tym samym oknie.
4. Przeczytaj pierwszy błąd, nie ostatnie skutki
W logu często pojawia się lawina komunikatów. Najważniejszy jest pierwszy błąd krytyczny poprzedzający awarię. W zgłoszeniu wystarczy jego typ, plik, linia i czas — bez sekretów oraz danych użytkowników.
5. Wróć do jednej stabilnej wersji
Rollback powinien obejmować spójny zestaw plików i bazy danych, jeżeli aktualizacja wykonała migrację. Po powrocie wyczyść tylko właściwe warstwy cache i sprawdź logowanie, formularze, wyszukiwanie, płatności oraz zadania cykliczne.
6. Odtwórz zmianę poza produkcją
Jeżeli przyczyna nie jest oczywista, sklonuj problem w środowisku testowym. Aktualizacje można wtedy wykonywać pojedynczo, z pomiarem i porównaniem logów, bez kolejnych przerw na stronie publicznej.
Kiedy nie działać samodzielnie
- brakuje pewnej kopii plików lub bazy;
- aktualizacja wykonała migrację danych;
- awaria dotyczy płatności, logowania albo danych osobowych;
- serwer zwraca błędy krytyczne lub proces jest cyklicznie przerywany.