Autor: Kamil Kosiorek „Kosior” — właściciel Vis-Sol, autor i właściciel procesu
Poradnik właściciela strony
Najgorszy moment na serię przypadkowych zmian to chwila po awarii. Zatrzymaj aktualizacje, zachowaj bieżący stan i wracaj do ostatniej stabilnej wersji w sposób, który pozwala później ustalić przyczynę.
Kontrolowany powrót Kopia → log → zgodność → test
Jak bezpiecznie przywrócić stronę po błędzie aktualizacji?
Po awarii należy zatrzymać dalsze zmiany, zachować kopię uszkodzonego stanu i ustalić pierwszą przyczynę w logach. Powrót powinien obejmować spójny zestaw plików oraz bazy danych, jeżeli aktualizacja zmieniała jej strukturę. Dopiero po odzyskaniu działania wykonuje się kontrolowane testy i ponawia zmianę poza produkcją.
Pytania przed przywróceniem strony
Dlaczego potrzebna jest kopia również po awarii?
Kopia sprzed awarii umożliwia powrót, a kopia uszkodzonego stanu zachowuje logi, pliki i konfigurację potrzebne do ustalenia przyczyny. Bez niej naprawa może usunąć najważniejsze dowody.
Kiedy modernizacja jest lepsza niż budowanie strony od nowa?
Gdy działające treści, adresy, integracje i wyniki wyszukiwania mają wartość, a problem dotyczy możliwych do wydzielenia elementów. Odtworzenie od zera ma sens dopiero wtedy, gdy koszt utrzymania obecnej architektury przewyższa bezpieczną migrację.
Kiedy nie wykonywać samodzielnego rollbacku?
Gdy brakuje pewnej kopii, aktualizacja migrowała dane albo awaria dotyczy płatności, logowania i danych osobowych. Wtedy przypadkowa podmiana plików może pogłębić niespójność.
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.
Zabezpiecz stan przed naprawą
Vis-Sol może najpierw odtworzyć i ustabilizować serwis, a dopiero potem planować modernizację.
Strona działa wolno
Procesy wyłączają się na serwerze
VSA / pierwsza pomoc
Przygotuj opis awarii bez ujawniania dostępów.
VSA pomoże zebrać wersje, czas zmiany i pierwszy komunikat. Naprawa wymaga osobnego, bezpiecznie uzgodnionego dostępu.
Zobacz też: Naprawa i modernizacja stron · Strony internetowe Toruń