JLI Trading – stabilizacja, optymalizacja i rozwój platformy e-commerce

Wprowadzenie:

Klient: JLI Trading LTD
Branża: e-commerce / re-commerce, model aukcyjny
Zakres: inżynieria aplikacji, optymalizacja infrastruktury, stabilizacja platformy, bieżący rozwój funkcji
Strona: jobalots.com

Kontekst:

Jobalots.com to brytyjska platforma re-commerce oparta na modelu aukcyjnym, która obsługuje tysiące żądań na minutę – przy przeglądaniu ofert, licytacjach, finalizacji zamówień i płatnościach. Gdy przejmowaliśmy platformę, była rentowna i kluczowa dla działania firmy, ale w praktyce nikt już nie brał za nią odpowiedzialności technicznej – pierwotny software house nie rozwijał aktywnie systemu, a platforma przerosła możliwości dotychczasowej konfiguracji, która nie była w stanie jej bezpiecznie obsłużyć.

Wyzwanie:

Klient zgłosił się do nas z powodu gwałtownych, niewyjaśnionych skoków kosztów infrastruktury, których poprzedni zespół nie potrafił zdiagnozować ani opanować. Krótki audyt potwierdził, że skoki kosztów były tylko widocznym wierzchołkiem znacznie większego problemu: kod nie był zgodny z konwencjami Laravela, nie było CI/CD, jasnej strategii branchowania, testów automatycznych ani sensownej dokumentacji.

Wydania odbywały się ręcznie, instancja po instancji. Nie było monitoringu błędów ani wydajności na produkcji. Operator płatności ocenił integrację jako „słabą”, co wiązało się z wymiernymi stratami przychodów. Uptime wynosił poniżej 95%, a incydenty wpływające na przychody zdarzały się regularnie. Platformę trzeba było ustabilizować i zmodernizować, a jednocześnie obsługiwać bieżący ruch i dostarczać funkcje, od których zależał rozwój biznesu.

Cele:

Rozwiązanie:

Wzięliśmy pełną odpowiedzialność techniczną za platformę – kod, infrastrukturę, wydania, incydenty i roadmapę technologiczną – i pracowaliśmy jako zespół zintegrowany z działami produktu i operacji klienta.

Zaczęliśmy od równoległej analizy infrastruktury produkcyjnej i kodu aplikacji, ponieważ okazało się, że skoki kosztów wynikały z nieefektywności na poziomie kodu, a nie wyłącznie z problemów z infrastrukturą. Najpierw usunęliśmy bieżące problemy, a zyskany oddech wykorzystaliśmy, by dogłębnie poznać system i zaprojektować lepiej dopasowaną, autoskalującą się infrastrukturę, która zastąpiła dotychczasową.

Od tego momentu prace toczyły się trzema równoległymi torami, ułożonymi tak, by każdy kolejny etap był bezpieczniejszy i tańszy.

Najważniejsze działania:

• Najpierw siatka bezpieczeństwa – zautomatyzowane CI/CD w GitHub Actions, dzięki któremu większość wydań trafia na produkcję bez przestojów; monitoring błędów i wydajności na produkcji w Sentry; wprowadzenie testów jednostkowych, funkcjonalnych i analizy statycznej w kodzie, który na starcie miał zerowe pokrycie testami.
• Aktualizacja wersji języka, frameworka i bibliotek do bieżących, wspieranych wydań, co przywróciło bezpieczeństwo i możliwość dalszego wsparcia bez przepisywania systemu.
• Prace nad wydajnością i stabilnością oparte na rzeczywistych danych produkcyjnych: optymalizacje zapytań i aplikacji, dzięki którym ta sama infrastruktura obsługuje znacznie większy ruch przy mniejszym obciążeniu; wyraźny spadek liczby błędów 5xx; przebudowa przetwarzania zadań w tle z użyciem równoległych workerów, co wyeliminowało blokowanie i nakładanie się uruchomień; skrócenie importu i eksportu danych z kilkudziesięciu minut do kilkudziesięciu sekund.
• Przebudowa integracji z operatorem płatności zgodnie z rekomendowanym wzorcem, co podniosło ocenę integracji u operatora ze „słabej” na „dobrą” i wyeliminowało znane źródło utraconych przychodów.
• Ciągłe dostarczanie funkcji wpływających na przychody i poprawek równolegle z modernizacją, dzięki czemu firma nigdy nie musiała wybierać między rozwojem a stabilnością.

Przez cały czas kierowaliśmy się zasadą: naprawiać to, co zastaliśmy, zamiast zaczynać od zera. Przepisanie działającej, rentownej, autorskiej platformy re-commerce obsługującej tysiące żądań na minutę łatwo zaproponować – i byłoby to błędem.

To trudniejsza, mniej efektowna praca – uzdrawianie istniejącego systemu bez wyłączania go z użytku – realnie zaoszczędziła klientowi czas i pieniądze i pozwoliła przychodom rosnąć w trakcie naszych prac.

Jak pracowaliśmy

Na co dzień działaliśmy jako zespół inżynierski platformy, a nie zewnętrzny dostawca. Programiści i testerzy QA byli włączeni w proces produktowy klienta, uczestniczyli w planowaniu i ustalaniu priorytetów oraz w pełni odpowiadali za incydenty produkcyjne – od alertów i dyżurów, przez analizę przyczyn źródłowych, po zapobieganie kolejnym. Decyzje o kierunku technicznym platformy należały do nas i zapadały w dialogu z biznesem. Klient mógł polegać na zespole technicznym i skupić się na prowadzeniu firmy.

Efekt

W trakcie współpracy wskaźniki biznesowe i operacyjne platformy zdecydowanie poprawiły się we wszystkich obszarach.

• 2x większy przychód od pierwszego wydania pod naszą opieką
• Ponad 99,99% uptime’u w ostatnim roku (wcześniej <95%)
• 0 → 100% zautomatyzowanych wydań
• Od zera do rosnącego pokrycia testami (jednostkowe, funkcjonalne, statyczne)
• Ze „słabej” na „dobrą” – ocena integracji u operatora płatności
• Z minut do sekund – najdłużej trwające operacje na danych

Liczba rejestracji nowych klientów znacząco wzrosła (według danych klienta), wzrósł też ruch na stronie. Czasy odpowiedzi stron i liczba błędów 5xx wyraźnie spadły. Przetwarzanie w tle działa równolegle. Koszty infrastruktury utrzymały się na tym samym poziomie lub spadły, mimo że platforma obsługuje większy ruch, a nowa autoskalująca się architektura jest dopasowana do rzeczywistego zapotrzebowania, a nie do szacunków na najgorszy scenariusz.

Aplikacja pozostaje tym samym produktem, na którym opiera się biznes – teraz jednak działa na aktualnym stacku technologicznym, jest monitorowana, wdrażana automatycznie i znacznie tańsza w utrzymaniu.

Opinia klienta

Jack Lear

Founder & CEO @ JLI Trading

Efficient Web przejął rentowną, ale kruchą platformę i bez zbędnego hałasu zamienił ją w dobrze zaprojektowany system. W trakcie współpracy przychody się podwoiły, czas dostępności (uptime) wzrósł z niespełna 95% do 99,99%, a koszty infrastruktury pozostały na tym samym poziomie mimo rosnącego ruchu.