# Czym jest SLO? Przewodnik dla dev solo bez zespołu SRE

URL: https://whatshouldibuildnext.com/pl/journal/czym-jest-slo
Type: blog
Locale: pl
Published: 2026-10-17
Updated: 2026-10-17

---

> SLO to liczba określająca, jak często usługa ma działać w ustalonym oknie czasu. Pokazujemy, jak wybrać SLI, ustawić cel i użyć budżetu błędów w projekcie solo.

Czym jest SLO? To liczba, którą ustawiasz sobie w sprawie tego, jak często usługa ma działać, mierzona w ustalonym oknie czasu. „99.9% żądań kończy się sukcesem w ciągu 30 dni” to właśnie SLO. Zamienia ono „strona chyba działa” w coś, co da się sprawdzić, i mówi, kiedy przestać wrzucać nowe funkcje, a zamiast tego naprawić to, co się psuje.

Do tego nie potrzebujesz zespołu platformy. Dev solo z jednym API i bazą Postgres napisze użyteczne SLO po południu. Poniżej: co oznacza ten termin, jak wybrać liczbę i gdzie to najczęściej idzie źle.

Wyobraź sobie projekt poboczny z 400 użytkownikami tygodniowo. Pewnej nocy endpoint checkoutu zaczyna zwracać błąd 500 przez około 20 minut. Nikt nie pisze na Twitterze, nikt nie wysyła maila. Dowiadujesz się o tym trzy dni później z jednej wiadomości od wsparcia.

Czy to był zły wynik? Bez celu nie da się odpowiedzieć. Z celem już tak: jeśli SLO dopuszcza około 43 minuty awarii miesięcznie, a Ty właśnie zużyłeś 20 minut, wiesz, że jedna zła noc pochłonęła prawie połowę limitu. O to chodzi w SLO. Zamienia odczucie w budżet.

## SLI, SLO i SLA bez żargonu

Ludzie stale mieszają SLI, SLO i SLA, więc oto wersja krótka.

**SLI** (wskaźnik poziomu usług) to pomiar. „Odsetek żądań HTTP, które zwróciły status inny niż 5xx w ciągu ostatnich 30 dni” to SLI. Jest to stosunek dobrych zdarzeń do wszystkich zdarzeń.

**SLO** (cel poziomu usług) to cel dla tego pomiaru. „Ten stosunek ma utrzymać się na poziomie co najmniej 99.9%” to SLO. Jest wewnętrzne. Ty je ustawiasz, możesz je zmienić, a nikt nie pozwie Cię za nie.

**SLA** (umowa o poziomie usług) to kontrakt z konsekwencjami, zwykle zwrotami lub kredytami. Większość projektów pobocznych nie ma SLA i to w porządku, bo SLO da się prowadzić bez niego. Jeśli chcesz dłuższą wersję, standardowym źródłem jest [rozdział o wdrażaniu SLO z Google SRE workbook](https://sre.google/workbook/implementing-slos/).

Kolejność ma znaczenie: najpierw wybierz SLI, potem SLO, a o SLA myśl dopiero wtedy, gdy płacący klient zażąda go na piśmie.

![Stoper i szkic w notesie przedstawiający częściowo zapełniony pasek budżetu błędów](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/70d162-i1.webp)

## Budżet błędów: część, która zmienia sposób pracy

SLO na poziomie 99.9% oznacza też, że 0.1% zdarzeń może się nie udać. Ten zapas to budżet błędów i to on jest użyteczną połową całego pomysłu.

Przy miesiącu 30-dniowym dostępność 99.9% zostawia około 43 minut dozwolonej niedostępności. Rachunek jest prosty: 30 dni razy 24 godziny razy 60 minut daje 43,200 minut, razy 0.001. Cel 99% daje około 7.2 godziny. Cel 99.99% daje około 4.3 minuty.

Te dwie ostatnie liczby pokazują, dlaczego mały projekt nie powinien celować wysoko. Cztery minuty miesięcznie oznaczają, że jeden zły deploy i rollback już łamią cel. W praktyce pułapka jest taka: im wyżej celujesz, tym więcej czasu idzie na bronienie liczby zamiast na budowanie produktu.

Budżet daje też regułę decyzji, co budować dalej. Budżet w większości nietknięty: wypuść ryzykowną funkcję. Budżet spalony: najpierw napraw to, co się sypie. Bez spotkania, wystarczy liczba na dashboardzie.

Sprawdzaj budżet w połowie miesiąca, a nie tylko na jego końcu. Koniec miesiąca to już za późno, żeby cokolwiek zmienić, a połowa okresu daje czas na korektę planu. Jeśli w połowie widzisz, że większość budżetu jest zużyta, przesuń ryzykowne prace na kolejny okres i zajmij się stabilnością.

## Jak wybrać SLI i liczbę, zaczynając od niższego progu

Zacznij od tego, co użytkownik nazwałby zepsutym. W aplikacji webowej sprowadza się to zwykle do dwóch pytań: czy żądanie się udało i czy było wystarczająco szybkie? W większości projektów pobocznych dwa SLI pokrywają 90% wartości:

- 
**Dostępność**: dobre żądania podzielone przez wszystkie żądania, gdzie „dobre” znaczy odpowiedź inną niż 5xx.

- 
**Opóźnienie**: odsetek żądań obsłużonych poniżej progu, na przykład 95% żądań poniżej 500 ms.

Zwróć uwagę, że opóźnienie zapisujemy jako odsetek żądań poniżej progu, a nie jako średnią. Średnia ukrywa długi ogon, a to właśnie tam użytkownicy się poddają. Myślenie w percentylach ma tu znaczenie: średnia 300 ms może leżeć obok p99 wynoszącego 4 sekundy.

Mierz jak najbliżej użytkownika. Health check pingujący `/healthz` z wnętrza tej samej sieci VPC mówi, że proces żyje, ale nie to, że użytkownicy mogą się zalogować. Jeśli stać Cię tylko na jeden pomiar, sprawdzaj prawdziwą ścieżkę użytkownika, na przykład logowanie albo checkout, z zewnątrz.

Uczciwa odpowiedź dla nowego projektu to 99% albo 99.5%. Spójrz na dane z ostatnich 30 dni, sprawdź, co faktycznie dostarczyłeś, ustaw SLO nieco poniżej tej wartości, a zaostrzysz je później, jeśli użytkownicy zaczną narzekać. Dla projektu solo orientacyjnie:

- 
**Hobbystyczne narzędzie bez przychodów**: 99% w zupełności wystarczy. Około 7 godzin awarii miesięcznie jest niewidoczne dla większości użytkowników.

- 
**Płatny SaaS z kilkudziesięcioma klientami**: od 99.5% do 99.9%, zależnie od tego, jak bardzo produkt jest wrażliwy na czas.

- 
**Wszystko, na czym klienci polegają w godzinach pracy**: 99.9%, a ścieżkę rollbacku przetestuj, zanim cokolwiek obiecasz.

Przetestowane, nie optymalne, i warto to zrobić mimo wszystko: SLO, które trafiasz w 100% przypadków, jest ustawione za nisko, a SLO, którego nigdy nie trafiasz, nikt nie traktuje poważnie. Celuj w to, żeby czasem go nie trafić, bo wtedy budżet wykonuje swoją robotę.

![Laptop w kawiarni w Bangkoku pokazujący płaski, stabilny wykres opóźnień o zmierzchu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/d85f1c-i2.webp)

## Mały SLO, który możesz zapisać dziś

Czy SLO to tylko monitoring uptime z dodatkowymi krokami? Trochę się pokrywa, ale nie do końca. Ping mówi, że strona odpowiedziała w danej minucie. SLO mówi, jaki odsetek prawdziwych żądań działał przez miesiąc i co to znaczy dla Twojej następnej decyzji.

Wyobraź sobie dwa tygodnie, w których monitor pingu pokazuje zielono co minutę, a jedno wolne zapytanie do bazy powoduje, że dashboard przekracza czas oczekiwania u 3% zalogowanych użytkowników. Monitor mówi, że wszystko gra. SLI mówi, że chybiłeś celu opóźnienia. Tylko jedno z tych dwóch zmienia to, co zrobisz w poniedziałek.

Monitora pingu nie wyrzucaj. Jest tani i szybko łapie całkowite awarie. Traktuj go jako jedno z wejść, a nie jako definicję „działania”.

Nie potrzebujesz dostawcy, żeby zacząć. Zapisz to w repo, w pliku `SLO.md`:

`service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: all requests except /healthz
  latency:
    good: response_time < 500ms
    total: all requests except /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - wstrzymaj mniej pilne funkcje
  - najpierw napraw główne źródło błędów`Jeśli stack już eksportuje liczniki żądań, SLI dostępności w składni Prometheus to jedna linijka:

`sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))`Ten stosunek porównany z celem to cały Twój dashboard SLO. Reszta to szlif. Wystarczą trzy panele: bieżący SLI, pozostały budżet i wykres burn rate.

Trzymaj też plik SLO.md w tym samym repo co kod. Wtedy zmiana celu przechodzi przez review tak jak każda inna zmiana, a każdy, kto kiedyś otworzy projekt, od razu widzi, na czym Ci zależy. Dla jednoosobowego projektu to może brzmieć przesadnie, ale za pół roku sam sobie będziesz wdzięczny za ten zapis.

## Alerty na burn rate, a nie na każde drgnięcie

Błąd, który popełnia prawie każdy: alarm, gdy wskaźnik błędów przekroczy próg. Budzi Cię o trzeciej w nocy z powodu 90-sekundowego skoku, który kosztował 0.2% miesięcznego budżetu.

Burn rate to rozwiązanie. Pyta, jak szybko zużywasz budżet w porównaniu z tempem, które zużyłoby go dokładnie na koniec okna. Burn rate równy 1 oznacza, że miesiąc skończysz z pustym budżetem i bez niespodzianek. Burn rate równy 10 oznacza, że budżet opróżni się w trzy dni. Dobra wiadomość: burn rate liczysz z tych samych danych co SLI, więc nie potrzebujesz osobnego systemu. To ta sama liczba, tylko patrzona pod innym kątem.

Rozsądny zestaw dla jednej osoby to dwa alerty. Szybki, na przykład dla burn rate powyżej 10 w ciągu godziny, który Cię obudzi. Wolny, na przykład dla burn rate rzędu 2 w ciągu doby, który staje się zgłoszeniem na rano. [Rozdział o celach poziomu usług z Google SRE book](https://sre.google/sre-book/service-level-objectives/) tłumaczy uzasadnienie, a wersja wielookienkowa jest w workbooku, o którym była mowa wyżej.

Przy tym nie chodzi o to, żeby mieć jak najwięcej alertów. Każdy alert, który nie prowadzi do działania, uczy Cię ignorować powiadomienia, a to najgorsza możliwa sytuacja. Jeśli alert nie wymusza żadnej decyzji, usuń go albo przenieś do raportu tygodniowego.

![Telefon na nocnej szafce, który zapala się nocnym alertem](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-10/838592-i3.webp)

## Które narzędzie, gdy jesteś całym zespołem ops

Przez miesiąc możesz prowadzić SLO w arkuszu i z crona, dopóki nie wiesz, na czym Ci naprawdę zależy. Gdy liczby zaczynają mieć znaczenie, narzędzie się zwraca. Trzy warte uwagi, z zastrzeżeniem, że Twój stack rozstrzyga więcej niż lista funkcji. Nie musisz od razu za nic płacić. Darmowe plany wystarczają, żeby sprawdzić, czy w ogóle zaglądasz do swoich liczb.

Grafana to domyślny wybór dla osób, które już eksportują metryki Prometheus. Darmowy plan jest hojny jak na projekt poboczny, a funkcja SLO działa na danych, które prawdopodobnie już masz. Odpuść, jeśli nie masz jeszcze potoku metryk i nie masz ochoty go budować.

New Relic ma darmowy plan z 100 GB pozyskanych danych miesięcznie i wbudowane narzędzia SLO. Pasuje, jeśli chcesz konfiguracji opartej na agencie i niewielkiej liczbie ustawień. Kompromis jest taki, że koszty stają się mniej przewidywalne po przekroczeniu darmowego limitu.

Datadog to najbardziej kompletna i zarazem najdroższa opcja, z infrastrukturą, APM i logami rozliczanymi osobno. Warto, gdy wokół Ciebie rośnie zespół. Dla projektu solo odpuść, chyba że płaci ktoś inny.

Cokolwiek wybierzesz, nie definiuj piętnastu SLO pierwszego dnia. Jedno SLO dostępności i jedno opóźnienia na usługę widoczną dla użytkownika wystarczą, żeby się czegoś nauczyć.

## Jeden miesiąc z prawdziwą arytmetyką

Załóżmy, że Twoje SLO to 99.5% dostępności w ciągu 30 dni, a obsługujesz około 600,000 żądań miesięcznie. Ten cel dopuszcza 0.5% porażek, czyli 3,000 nieudanych żądań, zanim budżet się wyczerpie.

Dnia 9 zła migracja zwraca błędy 500 przez 25 minut i kosztuje Cię 1,100 nieudanych żądań. W jeden wieczór zużyłeś około 37% budżetu. Dnia 17 zewnętrzne API przekracza czas oczekiwania i spala kolejne 900. Jesteś teraz na około 67% wydatku, z 13 dniami do końca miesiąca.

Tu budżet zaczyna pracować na Ciebie. Nie musisz panikować, ale nie wypuszczaj ryzykownego refaktoryzowania, które planowałeś na dzień 20. Dodajesz timeout i fallback dla tego wywołania zewnętrznego, piszesz sprawdzenie migracji, które pominąłeś, a refaktoryzację przenosisz na przyszły miesiąc.

Zwróć uwagę, że w tym scenariuszu nie ma dramatu. Nikt nie wstaje w nocy i nikt nie zwołuje spotkania. Decyzja zapada na podstawie liczby, którą miałeś przed oczami przez cały miesiąc.

Wniosek nie brzmi, że awarie są złe. Awarie się zdarzają i są uwzględnione w kalkulacji. Liczba daje spokojną, wspólną odpowiedź na pytanie „czy stać nas na to ryzyko teraz?”, nawet gdy w pokoju siedzi tylko jedna osoba.

Przeglądaj liczbę raz na kwartał albo po każdym miesiącu, w którym mocno przekroczyłeś budżet albo go wcale nie ruszyłeś. Dwa razy z rzędu chybiony cel oznacza, że system wymaga realnej pracy albo cel był ambitny jak na Twój etap. Oba fakty są przydatne. Zapisuj też, co zmieniłeś po każdym przeglądzie. Po kilku kwartałach zobaczysz, które decyzje faktycznie poprawiły wynik, a które były tylko poprawianiem wrażenia.

Gdy zdobędziesz płacących klientów, zapytaj ich, co dla nich znaczy „zepsute”. Klient, który puszcza tygodniowy raport, dba o poniedziałkowy poranek, a nie o sobotni skok. SLO może to odzwierciedlić węższym celem w jego godzinach pracy.

## Trzy błędy, przez które SLO nic nie daje

**Mierzenie tego, co łatwe, zamiast tego, co czuje użytkownik.** Wykorzystanie CPU nie jest SLI. Użytkownikom nie zależy na tym, że CPU ma 40%. Chcą, żeby strona się załadowała.

**Ustawianie celu z ambicji.** „Chcemy pięciu dziewiątek” brzmi poważnie i nic nie znaczy, jeśli baza to pojedyncza instancja na małej maszynie. Ustaw SLO na podstawie zaobserwowanej rzeczywistości, potem ulepsz system, a dopiero na końcu zaostrz liczbę.

**Nieużywanie budżetu.** Jeśli kończysz każdy miesiąc z 98% budżetu, wypuszczasz za wolno albo cel jest za luźny. Niewykorzystany budżet to zmarnowana zdolność do podejmowania ryzyka.

Na jaką usługę założyłbyś SLO jako pierwszą? Wybierz jeden endpoint, który użytkownicy zauważyliby, gdyby padł. Zapisz SLI prostym językiem, ustaw cel 0.5 punktu procentowego poniżej tego, co dostarczyłeś w zeszłym miesiącu, i sprawdź ponownie za 30 dni. Jeśli chcesz projektu, który zmusi Cię do ćwiczenia tego, mały dashboard uptime i opóźnień dla własnych aplikacji to przyzwoity weekendowy build. Która z Twoich usług jest teraz najmniej godna zaufania?

## FAQ

### Czym różni się SLI od SLO?

SLI to pomiar, na przykład odsetek udanych żądań w ciągu 30 dni. SLO to cel dla tego pomiaru, na przykład 99.9%. Najpierw wybierasz SLI, potem ustawiasz SLO.

### Czy SLO to to samo co SLA?

Nie. SLO jest wewnętrzne i możesz je zmienić w dowolnej chwili. SLA to umowa z klientem, zwykle ze zwrotami lub kredytami. Projekt solo może mieć SLO bez SLA.

### Jakie SLO ustawić na start w projekcie solo?

Zacznij od 99% lub 99.5%, opartego na danych z ostatnich 30 dni. Zaostrzaj dopiero wtedy, gdy system na to pozwoli albo klienci tego zażądają.

### Ile niedostępności dopuszcza 99.9% w miesiącu?

Około 43 minut w 30-dniowym miesiącu. Dla 99% to około 7.2 godziny, a dla 99.99% około 4.3 minuty.

### Czy do SLO potrzebuję narzędzia?

Nie. Na początek wystarczy plik SLO.md i zapytanie o wskaźnik z metryk, które już zbierasz. Narzędzie ma sens, gdy liczby zaczynają wpływać na decyzje.

### Co to jest burn rate?

To tempo zużycia budżetu błędów w porównaniu z tempem, które wyczerpałoby go dokładnie na koniec okna. Burn rate 1 oznacza równe tempo, a 10 oznacza wyczerpanie budżetu w trzy dni.

### Jak często przeglądać SLO?

Raz na kwartał albo po miesiącu, w którym mocno przekroczyłeś budżet lub go wcale nie ruszyłeś.