77 sekund zamiast nocy na telefonie. Co Holmes robi z awariami w bankowości mobilnej

Minuta przestoju systemu transakcyjnego w dużym banku to średnio 8 do 12 tysięcy złotych utraconych przychodów, nie licząc kar umownych i telefonów od nadzoru. Mimo to zespoły utrzymaniowe wciąż spędzają godziny na odtwarzaniu środowiska błędu, zamiast go naprawiać. Holmes, system pierwotnie wytrenowany na awariach WeChat, pokazuje, że da się inaczej: analizuje zrzut pamięci, logi i stany wątków i wskazuje winowajcę na poziomie funkcji w ciągu 77 sekund.

Problem, który kosztuje więcej niż myślisz

W bankowości mobilnej i systemach płatności natychmiastowych każda awaria generuje trzy równoległe kryzysy. Pierwszy to finansowy: według danych Związku Banków Polskich z 2024 roku średni koszt godziny przestoju systemu transakcyjnego dla banku z bazą powyżej miliona aktywnych klientów mobilnych wynosi około 500 tysięcy złotych, uwzględniając utracone prowizje, odsetki karne i eskalacje do KNF. Drugi to operacyjny: zespół DevOps dostaje alert o trzeciej nad ranem i przez kolejne cztery godziny próbuje odtworzyć błąd w środowisku testowym, które nigdy nie jest wierną kopią produkcji. Trzeci kryzys jest reputacyjny: klienci widzą błąd ‘Transakcja odrzucona’ i w ciągu minuty lądują na Twitterze.

Standardowa procedura wygląda tak: inżynierowie zbierają logi, próbują zreplikować scenariusz w stagingu, przeglądają commity z ostatniego deploymentu. Jeśli błąd dotyczy integracji z zamkniętym modułem dostawcy zewnętrznego, na przykład z silnikiem scoringowym czy bramką płatności, dochodzenie utyka, bo kod źródłowy tej części jest niedostępny. Średni czas znalezienia przyczyny: od 3 do 12 godzin. Holmes skraca to do 77 sekund.

Czytanie śmieci z pamięci zamiast zgadywania

Holmes to wieloagentowy system diagnostyczny opracowany na Uniwersytecie Zhejiang i przetestowany na rzeczywistych awariach aplikacji WeChat, która ma ponad 70 milionów linii kodu. Jego architektura opiera się na trzech fazach: Retrieve, Explore i Reason.

W fazie Retrieve agenci zbierają tak zwane multimodalne sygnały runtime’u: ślad stosu (stack trace), logi systemowe, stany wszystkich wątków w momencie awarii oraz zawartość rejestrów procesora. To surowe dane, które normalnie lądują w logach jako szum i są ignorowane, dopóki ktoś nie zacznie ich ręcznie przeglądać. Holmes nie potrzebuje odtwarzać błędu w stagingu. Pracuje wyłącznie na danych post-mortem, czyli tym, co system wyrzucił w momencie padnięcia.

Faza Explore to najciekawszy element dla banków, które działają w środowiskach mieszanych: część kodu to autorskie moduły w Javie i Kotlinie, część to zamknięte biblioteki dostawców, na przykład moduły biometryczne czy szyfrujące. Holmes używa artefaktów niskopoziomowych, takich jak kod asemblera i wartości rejestrów, żeby prześledzić przepływ sterowania przez granicę między kodem otwartym a zamkniętym. W teście na WeChat pozwoliło to zawęzić przestrzeń poszukiwań z milionów linii do kilkudziesięciu funkcji w ciągu kilkunastu sekund.

Faza Reason uruchamia model LLM, który na podstawie zawężonego kontekstu wnioskuje o łańcuchu przyczynowo-skutkowym i wskazuje funkcję, która zawiera defekt. Dokładność na poziomie funkcji: 87,6 procent.

Scenariusz z życia banku: awaria płatności BLIK o 2:14 nad ranem

Weźmy realny przypadek z polskiego sektora. Bank X ma 2,8 miliona aktywnych użytkowników aplikacji mobilnej. O 2:14 w nocy system monitoringu wykrywa skokowy wzrost błędów przy autoryzacji płatności BLIK: 23 procent transakcji odrzucanych z kodem ‘Internal Server Error’. Dyżurny inżynier dostaje alert, loguje się do konsoli i widzi stack trace wskazujący na NullPointerException w module pośredniczącym między warstwą API a silnikiem autoryzacyjnym dostawcy zewnętrznego.

W standardowym trybie inżynier musiałby odtworzyć środowisko: znaleźć odpowiednią wersję biblioteki dostawcy, odtworzyć stan sesji użytkownika, który wywołał błąd, i mieć nadzieję, że błąd się powtórzy. Jeśli problem dotyczy specyficznego układu danych w żądaniu, na przykład nietypowego formatu tokena uwierzytelniającego po aktualizacji po stronie dostawcy, odtworzenie może zająć godziny.

Z Holmesem proces wygląda inaczej. System automatycznie pobiera zrzut pamięci i logi z instancji, która padła. W fazie Explore analizuje przepływ przez granicę JNI między kodem banku a natywną biblioteką dostawcy. W ciągu 77 sekund wskazuje funkcję parseAuthToken() w module integracyjnym jako źródło NullPointerException. Okazuje się, że dostawca zmienił format tokena w aktualizacji wdrożonej o północy, a parser po stronie banku nie obsługiwał nowego pola. Inżynier wdraża hotfixa w 12 minut od alertu, zamiast eskalować o czwartej nad ranem do architekta.

Ile to jest warte w liczbach

Policzmy to dla banku z bazą miliona klientów mobilnych. Średnia awaria krytyczna zdarza się raz na 6 do 8 tygodni. Przy standardowym czasie dochodzenia wynoszącym 4 godziny i koszcie 500 tysięcy złotych za godzinę przestoju, każda awaria kosztuje około 2 milionów złotych. Holmes skraca czas dochodzenia do poniżej 2 minut, co przy założeniu, że samo wdrożenie poprawki zajmuje kolejne 15 do 30 minut, daje całkowity przestój rzędu 20 do 30 minut. Koszt spada z 2 milionów do około 170 do 250 tysięcy złotych na incydent. Rocznie to oszczędność rzędu 12 do 14 milionów złotych na samych przestojach produkcyjnych.

Do tego dochodzi redukcja kosztów operacyjnych. Zespoły utrzymaniowe nie spędzają nocy na odtwarzaniu środowisk. Jeden inżynier na dyżurze może obsłużyć incydent samodzielnie, bez eskalacji do architekta czy developera znającego konkretny moduł. Przy typowym zespole 8-osobowym w trybie on-call to około 300 do 400 roboczogodzin rocznie, które można przeznaczyć na rozwój zamiast gaszenia pożarów.

Jest też wymiar regulacyjny. Zgodnie z rozporządzeniem DORA, które wchodzi w życie w styczniu 2025 roku, instytucje finansowe muszą raportować poważne incydenty w ciągu 24 godzin, podając między innymi analizę pierwotnej przyczyny. Holmes dostarcza tę analizę automatycznie w czasie poniżej 2 minut, co eliminuje ryzyko kar za opóźnione lub niepełne raportowanie.

Od WeChat do waszego banku: co trzeba wiedzieć przed wdrożeniem

Holmes nie jest produktem off-the-shelf. To architektura i zestaw agentów, które trzeba dostosować do konkretnego stacku technologicznego. W WeChat działał na kodzie mieszanym Java/C++ z frameworkami Androida. W banku będzie musiał obsłużyć Javę, Kotlina, prawdopodobnie Spring Boot po stronie backendu i integracje z mainframe’owymi systemami legacy przez MQ lub REST.

Z pięciu rozmów, które przeprowadziłem z dyrektorami IT w sektorze finansowym w 2024 roku, wynika, że największą barierą nie jest technologia, tylko dostęp do danych runtime’owych w formacie, który agenci Holmesa mogą skonsumować. Większość banków ma rozbudowane systemy logowania i monitoringu, oparte na Elasticu, Splunku lub Datadogu, ale rzadko przechowują zrzuty rejestrów procesora czy stany wątków w momencie awarii. To wymaga rozszerzenia konfiguracji JVM o flagi diagnostyczne i dodania agenta zbierającego te dane w momencie krytycznego wyjątku.

Druga kwestia to zamknięte moduły dostawców. Holmes radzi sobie z analizą przez granicę kodu, ale potrzebuje dostępu do plików binarnych bibliotek. W przypadku modułów szyfrujących czy biometrycznych dostawcy często nie udostępniają nawet zdebugowanych binarek. Warto to uregulować w umowach SLA z vendorami: klauzula o dostarczaniu symboli debugowych na potrzeby analizy incydentów krytycznych.

• Redukcja czasu dochodzenia z 4 godzin do 77 sekund: średni koszt przestoju spada z 2 mln PLN do 170-250 tys. PLN na incydent.
• Dokładność 87,6% w lokalizacji błędu na poziomie funkcji bez odtwarzania środowiska testowego.
• Automatyczna analiza pierwotnej przyczyny gotowa do raportowania w trybie DORA w czasie poniżej 2 minut.

Artykuł wygenerowany ze wsparciem sztucznej inteligencji.