1. Wprowadzenie

Awaria, która nie zostaje zauważona - to jeden z najgorszych scenariuszy w dużych organizacjach. Kiedy UI aplikacji działa poprawnie, ale realny proces pod spodem już dawno się zatrzymał, organizacja traci kluczową widoczność. W tym case study analizujemy rzeczywisty incydent z jednego z największych banków w Polsce - incydent, który przez 6 godzin pozostawał niewidoczny zarówno dla zespołów IT, jak i biznesu.

Zobacz, jak MATE wykryłby tę awarię w mniej niż pięć minut i jak mógłby automatycznie przywrócić działanie procesu.

2. Tło sytuacji: co właściwie działało, a co nie?

UI: działa bez zarzutu

Użytkownicy mogli logować się do systemu, wprowadzać dane, klikać przyciski i składać wnioski. Interfejs nie wykazywał żadnych błędów.

Proces biznesowy: zatrzymany

Wnioski po wysłaniu trafiały do kolejki (RabbitMQ/Kafka). Następnie powinny być pobierane przez konsumenta i zapisywane w bazie danych. Problem? Konsument przestał działać. Przetwarzanie spadło do 0/h a najgorsze: nikt tego nie zauważył.

3. Root cause: jedna zmiana w bazie danych

Po wdrożeniu zmiany w DB (alter табли, modyfikacja kolumny) wystąpiła blokada.
Kolumna została zablokowana, a konsument próbujący zapisać dane - po prostu zawisł.

To klasyczny przypadek awarii backendu, która:

• nie powoduje błędów UI,

• nie jest widoczna w monitoringu infrastrukturalnym,

• nie powoduje awarii serwerów,

• nie generuje błędów aplikacji.

4. Skutki biznesowe

Poniżej zbiorcze skutki jednego dnia takiego przestoju:

Wszystko dlatego, że nikt nie zauważył zatrzymania procesu.

5. Co widzą zespoły bez MATE?

✔ UI działa

✔ Serwer HTTP działa

✔ Baza danych odpowiada

✔ Dashboard aplikacyjny pokazuje „OK”

✔ Brak błędów w logach

A jednocześnie:

❌ Proces stoi

❌ Kolejka nie jest konsumowana

❌ Dane nie trafiają do systemu głównego

6. Co zrobiłby MATE - krok po kroku

Test syntetyczny E2E

MATE co pięć minut wykonałby syntetyczny test:

1. Otwórz UI i złóż wniosek testowy  
2. Sprawdź status przetwarzania w kolejce  
3. Zapytaj DB o status wniosku  
4. Zweryfikuj processed/min na KPI procesowym  
5. Porównaj do wartości progowych

Wynik: natychmiastowa detekcja braku zmian w KPI.

Alert progowy na „processed/min”

Alert zdefiniowany byłby np. tak:

IF processed_5min < 10 THEN
   trigger_alert("CRITICAL: queue stall")
END

MATE wysłałby SMS/e-mail/Slack/Teams w <5 minut od pierwszego zatrzymania procesu.

Automatyczna reakcja (auto-remediation)

Przykładowa sekwencja automatycznej reakcji:

1. Restart consumer service
2. Ponowna walidacja kolejki
3. Weryfikacja zapisu w DB
4. Oznaczenie incydentu jako resolved

W większości przypadków to wystarczy, aby proces wrócił do działania.

7. Efekty zastosowania MATE

„Bez testów E2E nie jesteśmy w stanie zobaczyć, że proces stoi. UI może działać idealnie — a cała operacja jest martwa. MATE skraca czas wykrycia z godzin do minut.”

9. Wnioski końcowe

Ta awaria była przykładem „cichego” przestoju - takiego, który nie generuje błędów, nie powoduje crashy i nie jest sygnalizowany przez monitoring infrastruktury. To jeden z najdroższych typów incydentów, bo organy IT i biznesu dowiadują się o nim dopiero od klientów.

MATE rozwiązuje ten problem całkowicie, bo monitoruje proces end-to-end, a nie tylko fragmenty infrastruktury.