Audyt systemu przed modernizacją – co sprawdzić najpierw

Przed modernizacją systemu najpierw sprawdza się to, co może zablokować każdy wariant prac: wersje PHP, frameworka i bazy danych oraz ich wsparcie, stan zależności i znane podatności, strukturę kodu i miejsca bez testów, integracje z innymi systemami, zadania cykliczne, proces wdrożeń, kopie zapasowe i to, kto w zespole rozumie, jak system działa. Do tego dochodzi część biznesowa: które procesy system obsługuje, gdzie użytkownicy tracą czas i co musi działać bez przerwy. Wynikiem audytu jest mapa ryzyk i plan etapów, a nie sama lista problemów. Poniżej znajdziesz checklistę, z której korzystamy.

Dlaczego audyt jest pierwszym krokiem

Zanim firma zacznie przepisywać system, warto ustalić, co realnie blokuje rozwój. Problemem może być kod, ale równie często są nim dane, brak dokumentacji, kruche integracje albo ręczne procesy wokół aplikacji. Audyt pozwala oddzielić części wymagające natychmiastowej interwencji od modułów, które mogą działać jeszcze długo bez zmian. Dzięki temu modernizacja nie staje się kosztownym projektem bez jasnego celu, uruchomionym wyłącznie z frustracji ze starego kodu.

Checklista techniczna

1. Wersje i wsparcie

• Wersja PHP na produkcji i na środowiskach testowych. PHP 8.1 nie ma wsparcia bezpieczeństwa od 31 grudnia 2025 roku; aktualnie wspierane gałęzie to m.in. PHP 8.3 i 8.4. Starsze wersje, np. PHP 7.x, od dawna nie dostają poprawek.
• Framework i jego wersja. Dla Laravel aktualnie wspierane są wersje 12 i 13; każda starsza wymaga zaplanowanej aktualizacji. W starych frameworkach lub kodzie bez frameworka ocenia się, jak głęboko logika jest z nimi spleciona.
• Silnik bazy danych i jego wersja oraz status wsparcia.
• Frontend: wersja Vue, React lub jQuery. Vue 2 ma status end of life od 31 grudnia 2023 roku.
• System operacyjny serwera, serwer WWW, wersje Node.js używane przy budowaniu frontendu.

2. Zależności

• Lista pakietów Composer i npm z wersjami, np. z `composer outdated` i `npm outdated`.
• Znane podatności – `composer audit` i `npm audit` dają szybki przegląd.
• Pakiety porzucone przez autorów lub skopiowane do repozytorium i zmodyfikowane ręcznie.
• Biblioteki, które blokują aktualizację PHP lub frameworka.

3. Kod

• Struktura: czy jest podział na warstwy, czy logika biznesowa siedzi w widokach i kontrolerach.
• Pokrycie testami i miejsca, gdzie testów nie ma wcale – zwłaszcza obliczenia cen, rabatów, stanów i dokumentów.
• Analiza statyczna, np. PHPStan lub Larastan na niskim poziomie – liczba błędów pokazuje skalę problemu.
• Duplikacja kodu i „pliki-giganty”, których nikt nie chce ruszać.
• Kod martwy: moduły nieużywane od lat, ale wciąż utrzymywane.

4. Baza danych

• Schemat: klucze obce, indeksy, spójność typów, kodowanie znaków.
• Tabele bez właściciela i dane tymczasowe, które stały się stałe.
• Wolne zapytania na podstawie logów.
• Rozmiar bazy, tempo przyrostu, czas odtworzenia z kopii.
• Logika w procedurach składowanych i wyzwalaczach, o której nie wie zespół aplikacji.

5. Integracje i zadania cykliczne

• Lista wszystkich integracji: z ERP, sklepem, przewoźnikami, bankami, systemami partnerów – kierunek, format, częstotliwość.
• Zadania cron i skrypty uruchamiane ręcznie.
• Obsługa błędów: czy nieudana synchronizacja jest gdzieś widoczna.
• Dane dostępowe zapisane na sztywno w kodzie.

6. Bezpieczeństwo

• Uwierzytelnianie, przechowywanie haseł, zarządzanie sesjami.
• Uprawnienia: czy każdy użytkownik widzi tylko swoje dane.
• Typowe podatności aplikacji webowych: wstrzykiwanie SQL, XSS, brak ochrony CSRF, niezabezpieczone przesyłanie plików.
• Sekrety w repozytorium i dostęp do serwerów.
• Kopie zapasowe: czy są, gdzie są i czy ktoś kiedykolwiek sprawdził odtworzenie.

7. Proces wdrożeń i środowiska

• Czy istnieje środowisko testowe zbliżone do produkcji.
• Jak kod trafia na serwer: ręczne kopiowanie, skrypt, CI.
• Czy migracje bazy są wersjonowane.
• Czy jest monitoring błędów i dostępności.

7a. Wydajność i infrastruktura

• Czasy odpowiedzi najważniejszych ekranów i operacji, np. listy zamówień, wyszukiwarki, generowania dokumentów.
• Operacje wykonywane synchronicznie, które powinny działać w tle – eksporty, importy, wysyłka maili.
• Wykorzystanie zasobów serwera w godzinach szczytu i przy zadaniach nocnych.
• Pliki przechowywane na dysku serwera aplikacji zamiast w osobnym magazynie, co utrudnia przeniesienie systemu.
• Zależność od jednego serwera: co się dzieje, gdy przestanie działać, i ile trwa przywrócenie usługi.

Te informacje są potrzebne nie tylko do oceny kodu. Pokazują, czy modernizacja może odbywać się na obecnej infrastrukturze, czy równolegle trzeba zaplanować jej zmianę.

Checklista biznesowa i organizacyjna

8. Procesy i użytkownicy

Najlepsze efekty daje rozmowa z osobami, które używają systemu codziennie. Warto zapytać:

• które operacje zabierają najwięcej czasu,
• gdzie pojawiają się błędy i obejścia – arkusze, notatki, ręczne poprawki,
• co blokuje sprzedaż lub obsługę klienta,
• które funkcje są krytyczne i nie mogą przestać działać nawet na godzinę.

9. Wiedza w zespole

To punkt często pomijany, a bywa największym ryzykiem:

• Kto zna system i czy ta osoba nadal pracuje w firmie lub u dostawcy.
• Czy istnieje dokumentacja – nawet szczątkowa.
• Czy wiadomo, dlaczego pewne rzeczy zrobiono „dziwnie”, np. z powodu wymagań klienta lub przepisów.
• Które obszary są „nietykalne”, bo nikt nie wie, co się stanie po zmianie.

Co powinno wyjść z audytu

Dobry audyt nie kończy się listą problemów. Powinien zawierać:

1. Mapę systemu – moduły, integracje, dane i ich właścicieli.
2. Listę ryzyk z priorytetem – co grozi awarią lub incydentem bezpieczeństwa teraz, co za rok.
3. Działania natychmiastowe – np. aktualizacja zależności z podatnościami, przywrócenie kopii zapasowych, usunięcie sekretów z kodu.
4. Rekomendację wariantu modernizacji – refaktoryzacja, modularyzacja, nowa warstwa API czy przepisanie – z uzasadnieniem. Kryteria wyboru opisujemy we wpisie Modernizacja backendu – kiedy przepisać system.
5. Plan etapów – kolejność prac z punktami kontrolnymi, tak żeby każdy etap dawał wartość i nie zatrzymywał firmy.
6. Założenia i niewiadome – czego nie dało się sprawdzić i co wymaga dodatkowej analizy.

Dopiero połączenie technicznego obrazu systemu z procesem biznesowym pokazuje prawdziwy priorytet prac.

Typowe błędy przy audycie

• Ocena wyłącznie kodu, bez rozmów z użytkownikami.
• Pominięcie zadań cyklicznych i skryptów poza repozytorium.
• Audyt na podstawie kopii kodu, która różni się od tego, co działa na produkcji.
• Raport bez priorytetów, w którym wszystko jest „do poprawy”.
• Brak sprawdzenia kopii zapasowych w praktyce.
• Pominięcie licencji i umów – np. komponentów, których licencja nie pozwala na dalszy rozwój, albo usług zewnętrznych z kończącą się umową.
• Traktowanie audytu jako oceny poprzedniego zespołu zamiast jako narzędzia do planowania. Nastawienie na szukanie winnych utrudnia zebranie rzetelnych informacji od osób, które znają system najlepiej.

Następny krok

Przygotuj dostęp do repozytorium, opis serwerów, listę integracji i wskaż dwie, trzy osoby, które na co dzień pracują z systemem. To wystarczy, żeby rozpocząć audyt. Zobacz, jak wygląda audyt systemu B2B i nasza modernizacja backendu, albo umów się na rozmowę.