Warsztat decyzji · ArchitectMentor Daily · 15.10.2026

Wszystkie kontrolki świecą na zielono. Dlaczego klient nie może zakończyć operacji?

Rozpoznaj ryzyko, podejmij decyzję i porównaj swój tok myślenia z analizą seniora. W wybranych ćwiczeniach zadasz też pytanie mentorowi AI.

CEL ĆWICZENIARozróżnić zdrowie komponentu od dostępności ścieżki biznesowej oraz zdefiniować mierzalne dowody gotowości usługi.2 minuty lub warsztat z mentorem

01SCENARIUSZŚredni

Co wiemy?

Fikcyjny scenariusz edukacyjny

Portal pozwala użytkownikowi złożyć wniosek. Serwis WWW, API, baza danych i broker komunikatów mają zielone health-checki; dashboard infrastruktury pokazuje 99,99% dostępności. Endpoint /health zwraca 200, a API utworzenia wniosku przyjmuje żądanie i oddaje identyfikator.

Jednak od pewnego czasu potwierdzenie złożenia nie pojawia się w portalu: konsument zdarzeń zatrzymał się po błędzie deserializacji. Wnioski gromadzą się w kolejce, a status pozostaje „w realizacji”. Operator proponuje uznać usługę za dostępną, bo infrastruktura działa, i zwiększyć liczbę instancji API. Nie wiadomo jeszcze, jaki jest uzgodniony czas ukończenia procesu ani czy wszystkie zaległe komunikaty można bezpiecznie ponowić.

Pytanie do Ciebie

Czy uznasz usługę za dostępną? Jaką granicę usługi, mierniki i kontrolowaną próbę zaproponujesz? W 2–3 zdaniach wyjaśnij decyzję i warunek jej zmiany.

Za co mentor ocenia odpowiedź?

Wynik jest wskazówką do nauki, nie oceną zawodowych kompetencji.

Granica usługi
Postęp i cele
Bezpieczny test negatywny

Zobacz pytania naprowadzające

Czy kod HTTP 200 na /health jest dowodem zakończenia procesu użytkownika?
Który etap jest asynchroniczny i jak wykryjesz zatrzymanie postępu?
Jak odróżnisz zaległość, błąd trwały i opóźnienie w dopuszczalnym oknie?
Jak przetestujesz wznowienie bez duplikowania skutków biznesowych?

Zacznij od wyboru albo od razu uzasadnij decyzję mentorowi. Wariant możesz zmienić w każdej chwili.

Nie wiem — pokaż wskazówkę

Oceń ścieżkę użytkownika, sygnały braku postępu i bezpieczeństwo próby.

03ANALIZA SENIORA

Porównaj tok rozumowania

Pełna analiza jest dostępna również bez oceny AI.

Zielony komponent to nie zielony proces

Nie uznawaj pełnej ścieżki biznesowej za zdrową na podstawie samych health-checków. Kontrola /health mówi, że komponent odpowiada na wybrany test, a nie że wniosek został ukończony. API może poprawnie zaakceptować polecenie przy niedziałającej części asynchronicznej. Jeżeli kontrakt mówi tylko o przyjęciu wniosku, trzeba osobno odróżnić dostępność przyjmowania od terminowości przetwarzania — nie wymyślać obietnicy natychmiastowego zakończenia.

Trzy warianty

A — Sam uptime usług. Prostota wdrożenia i szybkiej diagnostyki infrastruktury, ale brak informacji o zatrzymanym procesie; fałszywy obraz doświadczenia użytkownika.
B — Jeden syntetyczny test end-to-end na produkcji. Wcześnie wykrywa problemy z integracją, ale może generować skutki biznesowe, dane testowe i fałszywe alarmy; potrzebuje izolacji, sprzątania i granic uprawnień.
C — Warstwowe sygnały oraz bezpieczna próba syntetyczna. Zachowaj liveness/readiness komponentów, dołóż wiek najstarszego nieobsłużonego zdarzenia, tempo postępu, odsetek procesów zakończonych w uzgodnionym czasie i kontrolowany test całej ścieżki. W tym scenariuszu wybór C daje najlepszą obserwowalność pod warunkiem, że zespół uzgodni znaczenie „zakończony” i dopuszczalny czas.

Sygnały, których potrzebujesz

Oddziel status przyjęcia od zakończenia. Zdefiniuj stan wniosku, moment rozpoczęcia pomiaru i oczekiwane zachowanie UI przy opóźnieniu.
Mierz postęp, a nie tylko rozmiar kolejki. Śledź wiek najstarszej pracy, tempo konsumpcji i błędy trwałe / DLQ; sama liczba wiadomości bywa myląca przy zmianie ruchu.
Wybierz SLI i SLO użytkownika. Na przykład odsetek poprawnie przyjętych wniosków, które osiągnęły stan końcowy w uzgodnionym czasie — bez arbitralnego wpisywania czasu w publikacji.
Sprawdź ścieżkę syntetycznie. Użyj dedykowanego konta i nieszkodliwych danych testowych; nie twórz realnych zobowiązań. Potwierdź stan końcowy, obsługę duplikatów, możliwość sprzątania i limit częstotliwości.

Bramka decyzji

Przed dopuszczeniem usługi sprawdź kontrolowane zatrzymanie konsumenta. API nadal może być gotowe do przyjmowania, ale monitor powinien wykryć brak postępu we właściwym czasie. Po wznowieniu przetwórz zaległości i potwierdź, że ponowienie nie tworzy podwójnych rezultatów. W przypadku awarii stałej przyjmowanie nowych wniosków może wymagać ograniczenia albo komunikatu dla użytkownika zależnie od pojemności kolejki i uzgodnionego kontraktu.

Dostępność elementów jest niezbędną wskazówką operacyjną, ale nie zastępuje dowodu, że użytkownik otrzymuje obiecaną usługę.

POWIĄZANA WIEDZA