Cel nauki: zdefiniować dostępność usługi przez wynik obiecany użytkownikowi, a nie przez liczbę zielonych komponentów.

Fikcyjny scenariusz edukacyjny. Portal przyjmuje wniosek i zwraca identyfikator. API, baza i broker odpowiadają, ale zatrzymany konsument nie doprowadza procesu do stanu końcowego. Nie jest to opis konkretnej organizacji ani incydentu.

Dwie prawdziwe odpowiedzi mogą sobie przeczyć

Serwis przyjmujący polecenia może być dostępny, a proces biznesowy — nie. To nie błąd logiki. To dwa różne zobowiązania:

  • akceptacja — system trwale przyjął pracę i potrafi wskazać jej identyfikator;
  • ukończenie — praca osiągnęła uzgodniony stan końcowy w określonym czasie.

Jeżeli dashboard miesza te odpowiedzi, zielony kolor nie jest kłamstwem. Jest odpowiedzią na zbyt małe pytanie.

Drabina dowodów

WarstwaPytaniePrzykładowy dowódCzego nie dowodzi
ProcesCzy komponent żyje?Liveness, restart, wykorzystanie zasobówGotowości do obsługi ruchu
ZależnośćCzy komponent może wykonać swój krok?Readiness, połączenie, uprawnieniaUkończenia całego procesu
PostępCzy przyjęta praca przesuwa się do przodu?Wiek najstarszego zadania, tempo zakończeń, błędy trwałePoprawności skutku dla użytkownika
WynikCzy użytkownik otrzymuje obiecaną usługę?SLI stanu końcowego, kontrolowana próba syntetycznaPrzyczyny ewentualnej awarii

Potrzebne są wszystkie warstwy. Sygnał wyniku wykrywa problem, a sygnały komponentów pomagają go zlokalizować. Jeden wykres nie musi udawać całej architektury.

Zacznij od kontraktu procesu

  1. Nazwij stan przyjęcia i stany końcowe: sukces, odrzucenie, anulowanie albo wymaganie interwencji.
  2. Ustal początek pomiaru, dopuszczalne okno i populację. Nie wpisuj arbitralnego czasu tylko po to, żeby wykres miał próg.
  3. Przenieś identyfikator korelacji przez kolejkę, konsumentów i magazyny stanu. Nie umieszczaj poufnej treści w etykietach metryk.
  4. Mierz opóźnienie i brak postępu. Sama długość kolejki rośnie także podczas zdrowego skoku ruchu.
  5. Uzgodnij zachowanie po przekroczeniu progu: ograniczenie przyjmowania, komunikat o opóźnieniu, ręczna obsługa albo zatrzymanie procesu.

Bezpieczna próba całej ścieżki

Test syntetyczny powinien mieć osobną tożsamość, nieszkodliwe dane, ograniczoną częstotliwość i kontrolowane sprzątanie. Musi potwierdzić stan końcowy, a nie tylko odpowiedź HTTP. Przy operacjach tworzących zobowiązania lepiej użyć izolowanego wariantu testowego niż produkować „fałszywe zamówienia dla monitoringu”. Monitoring też potrafi zostać klientem, tylko zwykle nie płaci faktur.

Test negatywny

Zatrzymaj konsumenta w kontrolowanym środowisku. Oczekuj, że:

  • kontrole komponentów precyzyjnie pokażą, co nadal działa;
  • miernik postępu wykryje starzenie się pracy;
  • SLO wyniku zacznie zużywać budżet zgodnie z kontraktem;
  • po wznowieniu nie powstaną podwójne skutki;
  • operator potrafi wskazać stan każdej przyjętej pracy.

Granica tej techniki

Pełna próba end-to-end nie zastępuje diagnostyki, testów bezpieczeństwa ani uzgodnienia pojemności kolejki. SLO nie naprawia procesu; mówi, kiedy rzeczywisty wynik odbiega od zaakceptowanej obietnicy. Najpierw trzeba tę obietnicę ustalić.

Przećwicz decyzję na zatrzymanym procesie →

Źródła i podstawa metody: Google SRE — Monitoring Distributed Systems; Google SRE Workbook — Implementing SLOs; OpenTelemetry — traces. Drabina dowodów i scenariusz są autorskim opracowaniem ArchitectMentor. Źródła sprawdzono 19.10.2026.