„System ma być dostępny” nie mówi jeszcze, co zobaczy użytkownik ani kiedy zespół powinien zmienić priorytety. SLI, SLO i budżet błędów pomagają zamienić ogólny wymóg niezawodności w pomiar oraz decyzję. Najpierw wybierz ważną czynność użytkownika; dopiero potem ustal procent.

Trzy pojęcia, trzy różne role

  • SLI (wskaźnik poziomu usługi) to zmierzona proporcja poprawnych zdarzeń do wszystkich zdarzeń, które uzgodniliśmy liczyć. Może dotyczyć na przykład udanych zakończeń procesu zamówienia w określonym czasie.
  • SLO (cel poziomu usługi) mówi, jaką wartość SLI chcemy utrzymać w danym oknie, na przykład 99,9% w kolejnych czterech tygodniach.
  • Budżet błędów to liczba lub udział zdarzeń, które mogą nie spełnić SLO w tym oknie. SLA jest odrębnym zobowiązaniem wobec klienta, często z konsekwencjami umownymi.
Przykład fikcyjny: w ciągu czterech tygodni system otrzymuje 1 000 000 kwalifikujących się prób złożenia zamówienia. Przy SLO 99,9% budżet wynosi 0,1%, czyli 1 000 nieudanych prób. Jeżeli 700 prób nie spełni zdefiniowanego warunku, pozostaje 300. To ilustracja rachunku, a nie rekomendowana wartość SLO dla każdego systemu.

Co właściwie liczyć?

W przykładowym projekcie za „dobre” zdarzenie można uznać potwierdzenie zamówienia w ciągu uzgodnionych dwóch sekund od poprawnego żądania. Trzeba opisać punkt pomiaru, kwalifikujące się próby, sposób traktowania anulowania przez użytkownika, powtórzeń, błędnych danych i brakujących pomiarów. Bez jawnego mianownika można poprawić wykres przez wykluczenie trudnych przypadków, nie poprawiając doświadczenia klienta.

Pomiar na granicy ścieżki użytkownika bywa cenniejszy niż sam wskaźnik dostępności poszczególnych usług. API płatności i magazynu mogą raportować dobrą dostępność osobno, podczas gdy zamówienie jako całość zbyt często się nie kończy. CPU i liczba podów są przydatne do diagnozy, lecz nie zastępują wyniku odczuwanego przez użytkownika.

Jak przełożyć budżet na decyzję?

  1. Uzgodnij z właścicielem produktu krytyczną ścieżkę, definicję SLI, realistyczny cel i okno pomiarowe. Sprawdź dane historyczne oraz jakość instrumentacji.
  2. Spisz z zespołem zasady reakcji: kto analizuje szybkie zużycie budżetu, kiedy ogranicza ryzykowne wdrożenia, a kiedy inwestuje w odporność. Nie traktuj jednego progu jako uniwersalnej polityki.
  3. Po incydencie rozdziel przyczynę od skutku. Sprawdź, czy opóźniona zależność, retry, wspólna pula zasobów lub błąd pomiaru rzeczywiście odpowiadają za utracone „dobre” zdarzenia. Dopiero wtedy wybierz zmianę architektury.
Fragment przykładowego ADR: Kontekst: decyzje o wdrożeniach opierają się na dostępności pojedynczych API, choć użytkownicy zgłaszają nieukończone zamówienia. Decyzja: mierzymy udział kwalifikujących się zamówień potwierdzonych w uzgodnionym czasie; cel i próg reakcji ustalimy z produktem po przeglądzie danych. Odrzucony wariant: sama dostępność API nie pokazuje wyniku całej ścieżki. Konsekwencja: potrzebujemy spójnego identyfikatora próby, danych o opóźnieniach i przeglądu jakości pomiaru. Weryfikacja: spowalniamy zależność w teście i sprawdzamy, czy SLI odzwierciedla utracone potwierdzenia.

Pytanie do projektu: czy potrafisz wskazać jedną krytyczną czynność użytkownika, policzyć jej niepowodzenia z wiarygodnych danych i wyjaśnić, jaka decyzja zmieni się po szybkim zużyciu budżetu?

Źródła i zakres: definicje i podejście do ustalania SLO opierają się na Google SRE — Service Level Objectives oraz Google SRE Workbook — Implementing SLOs. Rachunek 99,9% przy milionie żądań przez cztery tygodnie ilustruje Example Error Budget Policy. Opis sklepu, ADR, próg dwóch sekund i proponowane kroki są autorską ilustracją, nie opisem rzeczywistego wdrożenia.