Bezpieczna aktualizacja systemów webowych

Niech pierwszy webdeveloper lub właściciel witryny, który nie zna takiej sytuacji rzuci kamieniem…

Godzina 22:56 Klik.  Klik. I po sprawie.

Tylko, że tym razem ten ostatni klik zamiast zmienić wersję na „nowszą i lepszą”  zostawia biały ekran śmierci.

„O kur…”, myślisz sobie „dobrze, że chociaż jest piątek”. Może nikt nie zauważy. W końcu weekend. Będzie czas to odkręcić.

W tym samym momencie ekran telefonu zaczyna rozświetlać pokój.
„Ciekawe kto to” - zadajesz czysto retoryczne pytanie, nerwowo próbując cofnąć to, co właśnie się wydarzyło.

Kilka głębokich oddechów. Próba przypomnienia sobie tajników kontroli nad sytuacją wyniesionych z filmów, w których mnisi zawsze wiedzą, co zrobić. Uspokajasz się na tyle, żeby utrzymać resztki świadomości.

To miała być rutynowa zmiana, robiona setki razy. Dlaczego tym razem nie zadziałało?

Znasz to? 

Jak do tego doszło?

Każdy system webowy ma moment, w którym zaczyna prosić o litość. Czasem subtelnie wolniejszym działaniem, błędami w logach, drobnymi problemami.

Czasem wprost - komunikatem, że obecna wersja przestaje być wspierana.

Powody są zwykle prozaiczne:

• nowe wersje PHP lub innego interpretera wnoszą poprawki bezpieczeństwa i wydajności,
• stare wersje oprogramowania wypadają z cyklu wsparcia i stają się potencjalnym wektorem ataków,
• biznes chce nowych funkcji, integracji albo po prostu „żeby było szybciej”.

W tym momencie zaczyna się proces aktualizacji. I właśnie tutaj najczęściej popełniany jest pierwszy błąd.

Dlaczego aktualizacje „na żywo” kończą się problemami?

Z doświadczenia przy aktualizacjach forów, sklepów i aplikacji webowych wynika jedno:
najwięcej awarii powstaje wtedy, gdy aktualizacja jest robiona na szybko, bez planu i bez testów (a co najgorsze) bezpośrednio na produkcji.

Wiem, bo na początku sam tak pracowałem. Mogłem sobie na to pozwolić jako młodszy, z mniejszą odpowiedzialnością i mniejszą stawką.

Dziś, kiedy w grę wchodzą:

• reputacja firmy,
• dane użytkowników,
• realne pieniądze,

robienie aktualizacji w stylu „yolo” przestaje być opcją.

Najczęstsze scenariusze problemów:

• rozszerzenie lub wtyczka nie wspiera nowej wersji środowiska (tu możesz wstawić dowolny język),
• zmiany były wykonywane ręcznie w plikach rdzenia systemu,
• motyw lub warstwa frontendu nie jest zgodna z nową wersją,
• brak możliwości szybkiego cofnięcia zmian (rollback).

Co istotne, każdą z tych sytuacji da się przewidzieć.
Pod jednym warunkiem: aktualizacja nie jest pojedynczym kliknięciem, tylko procesem wykonywanym etapami.

Można więc zrobić to bezpiecznie, ważne aby pod uwagę wziąć kilka kwestii, które wiążą się ze znajomością systemu. 

Jak przygotować bezpieczną i prawidłową aktualizację witryny?

Etap 1: przygotowanie i zabezpieczenie danych.

To najważniejszy etap całego procesu. Nie najbardziej widowiskowy, czasem mozolny i czasochłonny (duża ilość danych) ale decydujący o tym, czy aktualizacja będzie kontrolowanym procesem, czy próbą gaszenia pożaru.

Wiele rzeczy da się odtworzyć:

• konfigurację,
• wygląd,
• nawet część funkcjonalności.

Dane nie zawsze.

Tak, firmy hostingowe często wykonują kopie zapasowe automatycznie, czasem codziennie. Ale nawet codziennie może być zbyt rzadko.
Przykładem jest aktywne forum, sklep lub system z dużą liczbą interakcji, gdzie kilka godzin różnicy oznacza realną utratę treści, zamówień albo historii użytkowników.

Dlatego zanim zostanie wykonana jakakolwiek aktualizacja, trzeba przygotować pełną, własną kopię danych.
Nie tylko „na wszelki wypadek”, ale jako fundament dalszych prac i możliwość wiernego odtworzenia środowiska produkcyjnego.

Co obejmuje ten etap

• sprawdzenie aktualnej wersji systemu oraz oficjalnej ścieżki aktualizacji (a nie skrótów „bo ktoś na forum tak zrobił”),
• weryfikację środowiska serwerowego: wersji PHP, baz danych, rozszerzeń, limitów,
• wykonanie pełnej kopii plików oraz bazy danych,
• test odtworzenia kopii - bo backup, którego nie da się przywrócić, nie jest backupem.

Ten etap decyduje o bezpieczeństwie całego procesu. Jest niewidoczny dla użytkownika końcowego, nie poprawia „od razu” wyglądu ani szybkości strony, ale to właśnie on sprawia, że kolejne kroki można wykonywać bez nerwowego zerkania na telefon.

Etap 2: Przygotowanie środowiska testowego.

Kopia danych odtwarza się poprawnie. To dobry moment, żeby… nie robić jeszcze nic na produkcji.

Kolejnym krokiem jest przygotowanie środowiska testowego, na którym będzie wykonywana właściwa aktualizacja. Jego celem nie jest „sprawdzenie czy się da”, tylko sprawdzenie, co konkretnie się zepsuje zanim zobaczy to użytkownik.

Najlepszy scenariusz to środowisko uruchomione:

• na tym samym serwerze,
• z tą samą konfiguracją,
• pod nową domeną lub subdomeną.

Dlaczego to takie ważne?
Bo tylko wtedy problemy, które się faktycznie pojawią tutaj, będą realnymi problemami produkcyjnymi, a nie efektem różnic w konfiguracji. Tutaj można wszystkie ostrzeżenia i błędy pokazać na ekranie (w kontrolowanych warunkach).

Testy na środowisku, które:

• ma inną wersję PHP,
• inne rozszerzenia,
• inne limity pamięci,
• inne biblioteki systemowe,

dają złudne poczucie bezpieczeństwa. „Na testach działało” to jedno z najdroższych zdań w IT.

Dobrze przygotowane środowisko testowe pozwala:

• zbudować konkretną listę rzeczy do poprawy po aktualizacji,
• wychwycić problemy z wtyczkami, motywami i integracjami,
• sprawdzić migracje danych bez ryzyka,
• przeprowadzić aktualizację w kontrolowanych warunkach.

Na tym etapie nie chodzi jeszcze o optymalizację czy nowe funkcje. Chodzi o to, żeby zepsuć wszystko tam, gdzie wolno, a nie tam, gdzie kosztuje to pieniądze i nerwy.

Etap 3: aktualizacja rdzenia systemu.

To pierwszy moment w całym procesie, w którym coś może pójść spektakularnie na “nie”. Momenty w których zastanawiasz się czy nie jest jeszcze za późno na zmianę zawodu rozpoczynają się tutaj.

Zwłaszcza wtedy, gdy aktualizacja nie oznacza przejścia z wersji 1.2 na 1.3, ale skok o kilka pokoleń na przykład z wersji 1 do 3 (pozdrowienia dla Prestashop).

W teorii proces bywa prosty. W zależności od:

• rodzaju oprogramowania,
• jego wieku,
• ciągłości wcześniejszych aktualizacji,

aktualizacja wygląda „typowo”: nadpisujesz stare pliki nowymi, aktualizujesz konfigurację i z umiarkowaną dumą patrzysz na działający system, gotowy na kolejne kroki.

Problem w tym, że zdarzają się wersje oprogramowania, które postanawiają bohatersko  zerwać z przeszłością i przejść na nową lepszą drogę. Zmienia się wtedy praktycznie wszystko:

• struktura bazy danych,
• sposób działania rozszerzeń,
• API,
• warstwa szablonów,
• mechanizmy konfiguracji.

W praktyce oznacza to, że poza samą aktualizacją plików trzeba:

• zmienić konfigurację systemu,
• przebudować bazę danych,
• dostosować lub wymienić wtyczki,
• często przepisać część szablonu lub logiki.

To moment, w którym zaczyna być jasne, dlaczego środowisko testowe nie było opcją, tylko koniecznością.

Bo cofnięcie niedziałającej aktualizacji na wersji produkcyjnej bywa trudniejsze niż sama aktualizacja. A czasem bardziej ryzykowne niż pozostawienie systemu w stanie „jakoś działa”.

Ten etap nie służy temu, żeby było miło. Służy temu, żeby wszystkie problemy wyszły tam, gdzie jeszcze pomyłka nie oznacza zmiany zawodu.

Etap 4: aktualizacja składników - wtyczki, czasem szablony.

Aktualizacja rdzenia zakończona.
To jeszcze nie moment na otwieranie szampana raczej na bardzo ostrożne sprawdzenie, czy system w ogóle stoi na nogach.

Czasami to wystarczy, żeby wykryć problem, który zatrzyma cały proces, lecz czasami nie da się tego zrobić.

W wielu systemach zależność od wtyczek jest tak duża, że rdzeń bez nich praktycznie nie istnieje. I to też jest cenna informacja.

Rozszerzenia, czyli kolejne potencjalne źródło problemów.

Systemy webowe rzadko działają w wersji „vanilla”. To właśnie wtyczki i rozszerzenia zamieniają prosty system w kombajn dopasowany do konkretnych potrzeb biznesowych.

Skoro wcześniej:

• sprawdziłeś, które z nich są wspierane,
• znalazłeś zamienniki dla porzuconych,
• albo świadomie zrezygnowałeś z części funkcjonalności,

teraz przychodzi moment, żeby dodawać je z powrotem — jedna po drugiej.

Po każdej instalacji:

• sprawdzasz, czy system się uruchamia,
• czy nie pojawiają się błędy,
• czy podstawowe funkcje nadal działają.

To, czy coś „kładzie system na łopatki”, zwykle widać od razu. Biały ekran, ostrzeżenia, błędy to jasny sygnał, że trzeba się temu przyjrzeć dokładnie.

Pamiętaj.

Nie każde ostrzeżenie to powód do paniki, często są to informacje np. o tym, że dana funkcja nie będzie wspierana w nowych wydaniach interpreterów lub, że system spodziewa się innego typu zmiennej. 

Warto to mieć na uwadze, ale nie spowoduje to zawieszenia działania. 

Jeśli widok jest znajomy, bez krzyczących komunikatów, oznacza to jedno: najprawdopodobniej działa. Najprawdopodobniej… bo to jeszcze nie koniec.

Etap 5: czy wszystko wygląda jak należy?

System działa, wtyczki są zaktualizowane — teraz pora sprawdzić coś, co bardzo łatwo przeoczyć: warstwę wizualną.

Teoretycznie szablon powinien być odizolowany od logiki systemu.
 W praktyce bywa różnie. Zwłaszcza w systemach takich jak WordPress, gdzie motyw potrafi zawierać:

• własne funkcje,
• dodatkową logikę,
• zależności od konkretnych plików lub stylów.

Po aktualizacji może się okazać, że:

• nowe pliki CSS się nie załadowały,
• stare style nadpisują nowe,
• część elementów „działa”, ale wygląda inaczej niż wcześniej,
• layout rozsypał się tylko na wybranych podstronach.

Celem tego etapu nie jest estetyczna perfekcja, tylko wyłapanie różnic względem wersji sprzed aktualizacji, zanim zobaczy je użytkownik.

Bo system, który technicznie działa poprawnie, ale wygląda „trochę inaczej”, w oczach klienta często po prostu… nie działa.

Etap 6: czas przejść na produkcję.

Przejście przez Mordor zakończone. Moment chwały majaczy gdzieś w oddali, reflektory prawie zapalone. Został jeszcze jeden etap, który jak na złość nadal potrafi wszystko zepsuć czyli wdrożenie na produkcję.

Po tym, co wydarzyło się wcześniej, powinno być formalnością. I bardzo często faktycznie nią jest. Ale informatyka ma tę nieprzyjemną cechę, że nawet na finiszu potrafi przypomnieć, kto tu naprawdę rządzi.

Dlatego zanim klikniesz „deploy”:

• wykonaj świeżą kopię zapasową produkcji,
• jeszcze raz sprawdź konfigurację (szczególnie różnice względem testów),
• jeśli trzeba powtórz kluczowe kroki aktualizacji,
• po wdrożeniu wyczyść cache aplikacji, serwera i przeglądarki.

W międzyczasie warto też pomyśleć o użytkownikach. Krótka informacja o trwającej aktualizacji albo strona techniczna potrafią zrobić ogromną różnicę w odbiorze bo „chwilowa przerwa techniczna” brzmi znacznie lepiej niż „strona nie działa”.

To jest moment na spokojne, kontrolowane domknięcie procesu, nad którym pracowałeś od pierwszej kopii zapasowej.

Częste błędy podczas aktualizacji:

1. Aktualizacja bez pełnej kopii zapasowej
   Gdy coś pójdzie nie tak, nie ma do czego wrócić. Backup, którego nie da się odtworzyć, jest tylko uspokajaczem sumienia.
2. Praca bez środowiska testowego
   Aktualizacja na produkcji to rezygnacja z kontroli na rzecz szczęścia. Każdy błąd od razu widzą użytkownicy, a presja rośnie wykładniczo.
3. Przekonanie, że skoro core działa, to wszystko działa
   Rdzeń systemu zwykle przechodzi aktualizację bez problemu. To dodatki, wtyczki i motywy najczęściej wysadzają całość.
4. Ignorowanie ręcznych zmian w kodzie
   Stare projekty niemal zawsze mają „drobne poprawki” w core. Aktualizacja nadpisuje je bez ostrzeżenia i zaczyna się chaos.
5. Brak testów po aktualizacji
   „Strona się włącza” to nie test. Bez sprawdzenia kluczowych funkcji problemy wychodzą dopiero u użytkowników.
6. Brak decyzji przy problematycznych funkcjach
   Coś nie działa, ale nikt nie chce zdecydować, co dalej. Efekt to przeciągające się prace i koszty bez górnego limitu.
7. Brak kontroli po wdrożeniu
   Nie wszystko psuje się od razu. Bez monitoringu błędy potrafią dojrzewać w tle przez dni albo tygodnie.
8. Traktowanie aktualizacji jak „szybkiego zadania”
   To wspólny mianownik wszystkich problemów. Aktualizacja to proces zarządzania zmianą, nie kliknięcie w panelu.

Podsumowanie.

Bezpieczna aktualizacja to proces, który minimalizuje ryzyko niedostępności serwisu, pozwala w bezpieczny sposób przetestować nową wersję oprogramowania, jednocześnie chroniąc dane.

Niezależnie od tego co aktualizujemy kroki te pozwolą na bezpieczne zarządzanie zmianą i ochronią przed przykrymi niespodziankami.

Jeśli planujesz aktualizację i chcesz mieć ją zrobioną bez przestojów, nerwów i gaszenia pożarów, lepiej potraktować ją jak proces, a nie eksperyment.

O autorze.

Od lat związany z szeroko rozumianą informatyką. Pierwszą stronę stworzyłem w liceum, za co otrzymałem wyróżnienie.

Ciągle uczę się, aby dorównać tempu rozwoju nowoczesnych technologii łącząc je z wiedzą o psychologii aby zwiększać skuteczność stron i aplikacji internetowych.