Audyt aplikacji legacy

Audyt aplikacji legacy

Audyt nie jest krótkim przeglądem kodu ani listą uwag o stylu. Ma zastąpić przypuszczenia sprawdzonymi informacjami: co system robi, od których procesów zależy firma, gdzie występuje ryzyko i co warto zrobić najpierw. Starsza aplikacja może zawierać cenną wiedzę o wyjątkach, cenach, dokumentach, klientach i integracjach, nawet jeśli jej dokumentacja jest niepełna.

Pytania biznesowe wyznaczają zakres

Audyt zaczyna się od konsekwencji, nie od wersji frameworka. Czy zamówienia, płatności, faktury lub dostęp klientów działają przewidywalnie? Co blokuje rozwój? Które dane muszą pozostać spójne? Kto obsługuje awarię i jak firma dowiaduje się o problemie?

Procesy biznesowe
zamówienia • płatności • dokumenty • dostęp
                    │
                    ▼
Obszary audytu
kod i zależności • dane • integracje • bezpieczeństwo
testy • wdrożenia • workery • monitoring

Przegląd obejmuje między innymi wersje PHP i frameworka, biblioteki, architekturę, zapytania i migracje bazy, integracje API, uwierzytelnianie, autoryzację, granice organizacji, sekrety oraz proces wdrażania. Nie jest automatycznie pełnym audytem bezpieczeństwa ani dowodem braku podatności; jego wnioski zależą od uzgodnionego zakresu i dostępnych materiałów.

Od obserwacji do decyzji

W raporcie rozdzielamy fakt od interpretacji. Log potwierdzający zatrzymanie workera jest dowodem. Ryzyko niewystawienia faktury wynika z tego dowodu i opisu procesu. Priorytet zależy jeszcze od wpływu na firmę, częstotliwości oraz sposobu odtworzenia.

| Element | Przykład | |---|---| | Obserwacja | Worker faktur nie restartuje się po części wdrożeń. | | Dowód | Logi, konfiguracja i historia wydań. | | Ryzyko | Opłacone zamówienia mogą czekać na dokument. | | Zalecenie | Sprawdzanie workerów, widoczny status i procedura wznowienia. | | Priorytet | Ustalony z firmą według skutku i pilności. |

Ilustracyjny system zamówień Symfony

Załóżmy, że starsza aplikacja Symfony obsługuje checkout, płatności, faktury, e-maile i panel pracowników. To przykład hipotetyczny, nie opis projektu klienta GiSoft. Audyt może pokazać, że checkout jest stabilny, lecz callbacki płatnicze nie są dobrze weryfikowane, faktury pracują w kolejce bez czytelnego statusu, a ręczne ponowienie grozi duplikatem.

Nie oznacza to automatycznie konieczności wymiany systemu. Najpierw sprawdzamy autorytatywny stan zamówienia, granicę między logiką aplikacji a dostawcą płatności, zachowanie po timeoutach, trwały zapis prób i testy krytycznego workflow. Stabilny identyfikator pomaga rozpoznać tę samą sprawę, ale idempotencja wymaga także trwałego stanu, ochrony współbieżności, ograniczeń unikalności i zgodnego zachowania dostawcy.

Dane, operacje i bezpieczeństwo

Audyt bada własność danych oraz to, czy synchronizacje nie tworzą dwóch źródeł prawdy. Sprawdza wydajność na podstawie rzeczywistych zapytań i obciążenia, nie zaś na podstawie założenia, że każdy SQL lub monolit wymaga wymiany. Obejmuje też retry, timeouty, webhooks, poświadczenia integracji, pracę workerów, backupy, monitoring i dokumentację odtwarzania.

Kontrola dostępu jest weryfikowana po stronie serwera: tożsamość, role, uprawnienia, izolacja organizacji i konta wyłączonych użytkowników. Ukryty przycisk nie jest zabezpieczeniem. W pracy z informacjami poufnymi ustalamy zakres dostępu, minimalizujemy przekazywane dane i oznaczamy obszary, których nie dało się potwierdzić.

Co może wynikać z audytu

Ustalenia + kontekst firmy
            │
            ├── pozostawić stabilny moduł
            ├── wdrożyć natychmiastową ochronę
            ├── ustabilizować działanie
            ├── modernizować wybrany obszar
            └── zaplanować wymianę lub szerszy rewrite

Raport nie jest gotowym projektem technicznym ani gwarancją rezultatu. Zawiera zakres, potwierdzone ustalenia, założenia i ograniczenia, ryzyka wraz z wpływem biznesowym, rekomendacje oraz uzasadnioną kolejność działań. Wskazuje też, jakie decyzje wymagają dodatkowych danych lub osobnego badania.

GiSoft łączy rozmowy z osobami pracującymi w systemie z analizą techniczną i zachowaniem produkcyjnym. Dzięki temu firma otrzymuje podstawę do wyboru ochrony, stabilizacji, modernizacji etapowej, wymiany modułu lub szerszej przebudowy — zamiast decyzji opartych wyłącznie na wieku technologii.