Stary PHP i Laravel: co realnie grozi i jak zrobić aktualizację bez przestoju

„Działa, więc nie ruszamy” jest rozsądną zasadą do momentu, w którym przestaje być. Ten tekst tłumaczy, co realnie grozi firmie, której system stoi na niewspieranej wersji PHP albo Laravela, jak wygląda aktualizacja prowadzona bez przerwy w działaniu i w którym momencie lepiej przepisać moduł niż go ratować. Bez straszenia i bez zakładania, że masz dział IT.

Co znaczy „niewspierana wersja”

PHP i Laravel mają publiczne terminy wsparcia. Przez pewien czas dostają poprawki funkcjonalne, potem już tylko poprawki bezpieczeństwa, a po tej dacie nie dostają nic. To nie znaczy, że system przestaje działać z dnia na dzień. Znaczy, że od tego dnia każda nowa luka znaleziona w silniku zostaje w Twoim systemie na stałe.

Podobnie działają biblioteki, z których zbudowany jest projekt: system płatności, generator dokumentów, klient API. Ich autorzy przestają wspierać stare wersje, a kolejne wydania wymagają nowszego PHP. Powstaje węzeł: nie możesz zaktualizować biblioteki, bo nie masz nowego PHP, i nie możesz podnieść PHP, bo stary kod na nim nie działa.

Co realnie grozi

Ryzyka nie pojawiają się naraz. Dokładają się kolejno, im dłużej system stoi na wersji bez wsparcia.

1. Zaraz po końcu wsparcia Bezpieczeństwo

   Najczęstszy scenariusz nie wygląda jak włamanie z filmu. Wygląda jak automat, który skanuje internet w poszukiwaniu znanych wersji z publiczną luką i wchodzi tam, gdzie się da. Skutki bywają prozaiczne: doklejony kod wysyłający spam, przekierowanie części ruchu, podmienione numery kont w dokumentach.

2. Po kilku miesiącach Zgodność i umowy

   Przy danych osobowych RODO wymaga „odpowiednich środków technicznych”. System na wersji bez poprawek bezpieczeństwa tego warunku nie spełnia. Jeśli obsługujesz klientów korporacyjnych albo publicznych, pytanie o wersje pojawia się w ankiecie bezpieczeństwa, a coraz częściej także przy odnowieniu ubezpieczenia.

3. Po roku Koszt każdej zmiany

   Im starszy system, tym drożej wycenia się każdą nową funkcję, bo dotknięcie jednego miejsca wymaga ostrożności w pięciu innych. To ta pozycja, która zwykle najbardziej boli finansowo, choć nie wygląda groźnie.

4. Po dwóch latach i dłużej Hosting

   Dostawcy hostingu wycofują stare wersje PHP z własnej inicjatywy. Mail z informacją o wyłączeniu za miesiąc potrafi zamienić spokojny projekt w pożar, zwłaszcza gdy autor systemu jest nieosiągalny.

Dlaczego „przepiszmy wszystko od zera” to zwykle zła odpowiedź

Przepisanie brzmi czysto: nowy stack, nowy kod, koniec problemów. W praktyce oznacza, że przez długi czas firma płaci za dwa systemy, nie dostając nic nowego, a wiedza zapisana w starym kodzie, czyli wszystkie wyjątki dodane przez lata, znika po drodze. Dlatego zaczynam od przeglądu i dopiero on rozstrzyga: czasem wynik brzmi „przepisujemy jeden moduł, resztę aktualizujemy”.

Przegląd, od którego zaczyna się każdy taki projekt

• Na czym to stoi: wersje PHP, frameworka, bazy i serwera.
• Co jest przeterminowane: lista bibliotek bez wsparcia i tych ze znanymi lukami.
• Gdzie są integracje: płatności, dokumenty, systemy partnerów, poczta.
• Co jest testowane: zwykle odpowiedź brzmi „nic”, i to jest normalne.
• Czy da się postawić środowisko od zera na czystej maszynie, bez pytania autora. To najostrzejszy test dokumentacji.
• Co jest w kopiach zapasowych i czy ktoś kiedykolwiek próbował je odtworzyć.

Wynikiem jest lista zadań uszeregowana według ryzyka, a nie według tego, co da się naprawić najszybciej.

Jak wygląda aktualizacja bez przestoju

1. Kopia produkcji na osobnym środowisku. Z danymi pozbawionymi wrażliwych informacji, żeby dało się testować bez ryzyka.
2. Testy w miejscach, gdzie awaria kosztuje najwięcej. Logowanie, płatności, wystawianie dokumentów, integracje. Nie trzeba pokrywać całego systemu, żeby przestać zgadywać.
3. Wersja po wersji. Kolejne wydania PHP i frameworka po kolei, z uruchomieniem systemu po każdym kroku. Skok przez pięć wersji naraz kończy się długim debugowaniem bez punktu odniesienia.
4. Zmiany w bazie osobno i małymi krokami. Tak, żeby dało się wycofać jedną zmianę bez cofania całego wdrożenia.
5. Wdrożenie poza godzinami pracy, z kopią sprzed zmiany i przygotowanym planem wycofania.
6. Obserwacja przez pierwsze dni. Monitoring błędów, bo część problemów ujawnia się dopiero pod prawdziwym ruchem.

Przy tym trybie użytkownik widzi co najwyżej krótkie odświeżenie. Okno serwisowe planuję tylko tam, gdzie zmiana struktury dużych tabel tego wymaga, i mówię o tym z wyprzedzeniem.

Co robić, gdy autor systemu jest nieosiągalny

Kolejność jest zawsze ta sama: najpierw dostępy, potem kod, potem zmiany. Zbierz dostęp do repozytorium, serwera, domeny, bazy i usług zewnętrznych. Jeśli czegoś brakuje, to jest najpilniejsza sprawa, ważniejsza niż każda nowa funkcja. Dopiero mając komplet, można rozmawiać o modernizacji. Rozpisałem to w tekście o przejęciu strony po innym wykonawcy.

Jak nie wrócić do tego samego punktu za trzy lata

Modernizacja jest kosztem jednorazowym tylko wtedy, gdy po niej wchodzi rytm. Wystarczy niewiele: aktualizacje bibliotek co kwartał zamiast co pięć lat, testy w newralgicznych miejscach uruchamiane przy każdej zmianie, monitoring, który mówi o błędzie wcześniej niż klient, i kopie zapasowe, które ktoś raz na jakiś czas naprawdę odtwarza.

Tak wygląda utrzymanie, które oferuję po wdrożeniu, i tak samo prowadzę modernizacje i przejęcia systemów PHP oraz Laravel. Jeśli wolisz prowadzić to samodzielnie, dostajesz dokumentację i listę rzeczy odłożonych świadomie, z powodem, żeby następna osoba nie odkrywała ich od zera.

Ile to trwa i od czego zależy

Nie podam liczby tygodni, bo byłaby zmyślona: ten sam skok wersji przy systemie z testami trwa ułamek tego, co przy systemie bez nich. Na czas realnie wpływają cztery rzeczy: liczba wersji do przeskoczenia, liczba zewnętrznych integracji, to, czy da się odtworzyć środowisko od zera, oraz to, jak szybko po Twojej stronie da się potwierdzić, że kluczowe procesy działają poprawnie.

Ostatni punkt bywa wąskim gardłem. Aktualizacja kończy się nie wtedy, gdy kod się uruchamia, tylko wtedy, gdy ktoś z firmy potwierdzi, że faktury wychodzą, rezerwacje wpadają, a raport miesięczny się zgadza. Warto zaplanować na to czas osoby, która to potrafi sprawdzić.

Jak rozmawiać o tym z wykonawcą

1. Poproś o przegląd przed wyceną, a nie wycenę przed przeglądem. Wycena bez zajrzenia w kod jest zgadywaniem.
2. Zapytaj, co się stanie, jeśli po wdrożeniu coś przestanie działać: czy jest plan wycofania i kopia sprzed zmiany.
3. Ustal, co dostajesz na koniec poza działającym systemem: dokumentację, listę odłożonych rzeczy, dostęp do monitoringu.
4. Zapytaj wprost, co zostanie niezrobione i dlaczego. Uczciwa odpowiedź jest tu lepszym sygnałem niż obietnica, że będzie idealnie.