SLO: co to jest i jak to działa w praktyce dzisiaj

Vijay Krishnaswamy · 3 października 2026 · Data analysis basics

Summary

Service level objective to cel niezawodności wyrażony jako liczba w przedziale czasu, np. 99,9% żądań na 30 dni. Luka pomiędzy 100% a celem to budżet błędów: 43,2 minuty na miesiąc przy 99,9%. Ten przewodnik wyjaśnia SLI, SLO i SLA, a następnie daje formularze Excela i Sheets do śledzenia budżetu, burn rate i statusu wydań.

Złoty retriever siedzący obok laptopa pokazującego zielony wykres dostępności

Co to jest SLO? Service level objective to cel niezawodności, który ustawiasz dla usługi, wyrażony jako liczba w określonym przedziale czasu. „99,9% żądań się powiedzie w ciągu 30 dni" : to przykład SLO. Mówi to zespołowi, jak wiele błędów można zaakceptować, zanim trzeba zatrzymać nowe wdrożenia i zająć się naprawą. Matematyka za tym stoi prosta : zwykły podział : dlatego arkusz kalkulacyjny sobie z tym świetnie radzi.

Biscuit już pogonił za formułami. Ty przynosisz liczby.

Trzy skrótowce, które wszyscy mylą między sobą

SLI, SLO, SLA. Ludzie mieszają je na spotkaniach, więc oto krótka wersja.

SLI (service level indicator) : to, co mierzysz. Procent żądań, które wracają bez błędu, procent stron wczytanych poniżej 300 ms, procent zadań ukończonych na czas.
SLO (service level objective) : cel dla tej miary. „SLI musi wynosić co najmniej 99,9% w ciągu 30 dni".
SLA (service level agreement) : umowa z konsekwencjami, zwykle pieniądze zwrócone, przywiązane do celu.

Najprostsza próba pochodzi z SRE book Google: zapytaj, co się stanie, jeśli chybisz. Jeśli nic formalnego się nie stanie, patrzysz na SLO, nie na SLA. Twoje SLO powinno być bardziej wymogowe niż każda podpisana umowa SLA, żebyś dostał ostrzeżenie, zanim klient dostanie zwrot.

W języku arkuszy kalkulacyjnych: SLI to kolumna pomiarów, SLO to jedna komórka z celem, a SLA to dokument PDF, który ktoś z prawnego przechowuje.

Dlaczego 99,9% i 99,99% to zupełnie inne obietnice

Każdy dodatkowy „9" zmniejsza dopuszczalny czas przerw dziesięciokrotnie. W 30-dniowym miesiącu (43 200 minut), oto co każdy cel Ci zostawia:

99%: budżet 1%, 432 minuty (7,2 godziny) dopuszczalnej przerwy na 30 dni
99,5%: budżet 0,5%, 216 minut (3,6 godziny)
99,9%: budżet 0,1%, 43,2 minuty
99,95%: budżet 0,05%, 21,6 minut
99,99%: budżet 0,01%, 4,32 minuty

Ostatnia linia to pułapka. Cztery minuty na miesiąc oznaczają, że człowiek nie zdąży nawet skończyć czytania alertu, a budżet już się skończył. Większość wewnętrznych narzędzi, dashboardów i małych SaaS nie potrzebuje tego, a gonić za tym kosztuje naprawdę dużo w postaci redundancji i godzin na dyżurze.

Zapomnij o 99,99%, chyba że ktoś Ci za to płaci. Google ma w tym względzie brutalnie szczere: zacznij od łatwego celu, którym możesz się zaostrzać, bo ścisły cel, który trzeba będzie rozluźnić, uczy wszystkich ignorować tę liczbę.

Close-up of a fuel gauge needle, a picture of an error budget being spent

Budżet błędów : liczba, o którą naprawdę się kłóci

Budżet błędów to to, co zostaje po SLO. Cel 99,9%, więc budżet to 0,1%. W ciągu 30 dni to 43,2 minuty „złego" czasu, którą możesz wydać.

Myśl o tym jak o wskaźniku paliwa. Ryzykowne wdrożenia palą paliwo. Słaba migracja bazy danych pali paliwo. Przerwa o trzeciej nad ranem pali dużo paliwa. Jak zbiornik jest pełny, wysyłaj szybciej. Jak jest pusty, zatrzymaj dodawanie funkcji i zajmij się niezawodnością.

Polityka błędów Google to konkretnie: jeśli usługa przekroczy budżet w ciągu czterech tygodni, wszystkie zmiany się zatrzymują oprócz napraw P0 i patchy bezpieczeństwa aż do powrotu do celu. Budżet to narzędzie negocjacji, nie kara. Pozwala kierownikowi produktu i inżynierowi kłócić się z tej samej komórki zamiast z przeczuć.

Warto brać pod uwagę, jeśli pracuje nad tym więcej niż jeden zespół. Przesada, jeśli jesteś solo founderem z jedną stroną i formularzem kontaktowym.

Jaki SLI wybrać, żeby użytkownicy go zauważyli

Najlepsze SLI opisują moment, który człowiek by zauważył. Trzy pokrywają większość usług:

Dostępność : procent żądań, które się powiodły. Łatwo mierzyć, łatwo wyjaśnić.
Opóźnienie : procent żądań szybszych niż próg. „95% wyszukiwań wraca w poniżej 300 ms" to lepsze niż średnia, bo średnia ukrywa powolny ogon, który ludzi irytuje.
Świeżość : dla pipelinów danych i raportów, procent uruchomień skończonych przed deadline. To idealne dla ludzi zajmujących się arkuszami: „poranek Ci raport sprzedaży jest zaktualizowany do godziny 8 na 99% dni roboczych".

Zapisz SLI jako ułamek: dobre zdarzenia podzielone przez zdarzenia ważne. Ten jeden zwyczaj sprawia, że każde SLO jest obliczalne w jednej komórce, i zmusza cię, aby zdecydować, co liczy się jako „dobre" zanim dojdzie do incydentu, a nie w jego trakcie.

Co do przedziału czasowego, ostatnie 30 dni w oknie przesuwającym się to standardowy wybór. Miesiąc kalendarzowy jest łatwiejszy do reportowania, ale resetuje budżet 1. dnia, co kusi zespoły do pchnięcia ryzykownych wdrożeń w koniec miesiąca. W arkuszu okno przesuwające się to po prostu filtrowanie zakładki Incydentów do ostatnich 30 dni za pomocą SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Zbuduj tracker SLO w Google Sheets lub Excelu w 10 minut

Nie potrzebujesz platformy monitorowania, żeby zacząć. Potrzebujesz dwóch zakładek: Incydenty i SLO.

Na zakładce Incydenty zaloguj każdą przerwę z czasem rozpoczęcia w kolumnie A, czasem zakończenia w kolumnie B i czasem trwania w kolumnie C:

=(B2-A2)*24*60

B2 i A2 : daty-czasy końca i rozpoczęcia incydentu.
*24*60 : zamienia różnicę opartą na dniach na minuty.

Działa zarówno w Excelu, jak i w Sheets, we wszystkich wersjach.

Teraz zakładka SLO. Umieść te etykiety w kolumnie A i formuły w kolumnie B:

B1: 0.999                         (twój cel SLO)
B2: 30                            (przedział w dniach)
B3: =B2*24*60                     (całkowita liczba minut w przedziale)
B4: =B3*(1-B1)                    (budżet błędów w minutach)
B5: =SUM(Incidents!C2:C)          (przestój do tej pory)
B6: =1-B5/B3                      (rzeczywista dostępność)
B7: =B4-B5                        (pozostały budżet w minutach)
B8: =B5/B4                        (procent budżetu spalonego)

Przy celu 99,9%, B3 zwraca 43200 i B4 zwraca 43,2. Zaloguj przerwę 12-minutową i B8 pokazuje 27,8%. Gotowe.

Uwaga do C2:C w B5: otwarta zakładka to składnia Sheets. W Excelu użyj stałego zakresu jak Incidents!C2:C500 lub referencji do tabeli.

Dodaj komórkę statusu, żeby nikt nie musiał czytać liczby:

=IF(B8>=1,"Zatrzymaj wydania",IF(B8>=0.5,"Ostrożnie","Wysyłaj"))

B8>=1 : budżet całkowicie lub nadmiernie wydany.
B8>=0.5 : połowa wydana, więc przejrzyj ryzykowne zmiany.
Coś innego : zielone światło.

Ustaw swoje progi. Pięćdziesiąt procent to zarabiający kezdet, nie prawo fizyki.

Utknąłeś na składni do swojej wersji arkusza? Opisz to zwykłym angielskim i pozwól narzędziu go napisać.

Liczenie żądań zamiast minut

Śledzenie oparte na czasie jest łatwe do wyjaśnienia, ale surowe. Jeśli twoja usługa jest „niedostępna" przez 5 minut o 4 rano, kiedy nikt nie jest online, boli to mniej niż 5 minut w południe. Poważniejsze zespoły definiują SLI poprzez żądania.

Wklej export dziennika żądań do zakładki, ze statusem HTTP w kolumnie B. Wtedy:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

COUNTIF(B2:B,">=500") : liczy żądania, które zwróciły błąd serwera.
COUNTA(B2:B) : liczy wszystkie żądania. Jeden minus procent błędu daje procent sukcesu.

Wynik to twój SLI dostępności jako ułamek. Porównaj go z komórką celu i masz całe SLO w jednej linii. Excel 2016 i 365 oba akceptują COUNTIF; po prostu zamień B2:B na ograniczony zakres.

Dwie szczere ostrzeżenia. Arkusze zacinają się na milionach rzędów, więc wyeksportuj zamiast tego dzienne sumy. Odpowiedź 4xx to zwykle błąd użytkownika, nie twoja przerwa, więc zdecyduj tę regułę raz i zapisz ją.

Notebook, pencil, coffee and a stopwatch laid out for tracking uptime by hand

Burn rate : formuła, która ostrzega cię, zanim będzie za późno

Wiedza o tym, że spaliłeś 27,8% budżetu, jest miła. Wiedza o tym, że paliszgo szybciej niż kalendarz, jest przydatna. Ten stosunek to burn rate.

=B8/(B9/B2)

B8 : procent budżetu spalonego do tej pory.
B9 : dni upłynęły w oknie (wprowadź ręcznie lub użyj =TODAY()-B10, z datą rozpoczęcia okna w B10).
B2 : całkowity przedział w dniach.

Burn rate 1 oznacza, że skończysz okno z dokładnie zerowym budżetem. Powyżej 1 zmierzasz do zawieszenia. Poniżej 1 masz przestrzeń. Jeśli jesteś 10 dni w 30-dniowe okno i już spaliłeś 60%, burn rate to 1,8. To ta liczba do wyświetlenia na ekranie.

To ta sama idea, którą duże narzędzia monitorowania używają do alertów burn rate. Arkusz cię nie zbudzi o trzeciej nad ranem, więc traktuj go jako warstwę raportowania, nie alarm.

Oto pracowany przykład z prawdziwymi liczbami. Twoje SLO to 99,9% w ciągu 30 dni, więc budżet to 43,2 minuty. Dni 1-8: słabe wdrożenie wyłącza stronę kasy przez 14 minut. To 32,4% budżetu spalonego w jedną czwartą okna, burn rate około 1,2. Nic nie paląc, ale arkusz mówi „Ostrożnie", i następna ryzykowna migracja bazy danych dostaje drugie spojrzenie. Dzień 15: przerwa u dostawcy dodaje 30 minut. Razem 44 minuty, 101,9% spalone. Komórka statusu przerzuca się na „Zatrzymaj wydania", i rozmowa o priorytetach dzieje się z liczbą na stole zamiast z przeczuciem.

To całą wartość tego ćwiczenia. Nie dziewiątki, ale wspólna komórka, na którą wszyscy mogą wskazać.

Kiedy arkusz przestaje wystarczać

Tracker taki jak ten działa dla jednej lub dwóch usług i tygodniowego przeglądu. Rozpada się, gdy masz tuziny usług, potrzebujesz automatycznej zbierania danych, lub chcesz alertów, które się zapalają w minuty zamiast na następnym poniedziałkowym spotkaniu.

Czas spojrzeć na prawdziwe narzędzie obserwowalności. Datadog i Grafana mają natywne funkcje SLO, które ciągną SLI wprost z metryki i rysują dla ciebie budżet.

Wybierz Grafanę, jeśli chcesz open source i już uruchamiasz Prometheus. Wybierz Datadog, jeśli wolisz płacić, żeby nic nie uruchamiać samemu. Tak czy inaczej, zachowaj arkusz do poniedziałkowego słajdu przeglądu, bo każdy w pokoju może go otworzyć i nikt nie potrzebuje loginu u dostawcy.

Jeśli chcesz pomocy w zredagowaniu pierwszego zestawu SLI dla usługi, ogólny asystent to nienły partner do burzy mózgów. Zweryfikuj każdą liczbę, którą Ci daje, bo chętnie wymyśla plausible-sounding target.

Błędy, które sprawdzają SLO bezużytecznym i co zrobić w poniedziałek

Kilka wzorów, które Biscuit widział źle skończyć:

Kopiowanie twojej obecnej wydajności jako celu. Jeśli byłeś na 99,97% w ostatnim kwartale, SLO 99,97% blokuje tempo, które możesz nie być w stanie utrzymać.
Zbyt wiele SLO. Dwa lub trzy na usługę. Poza tym nikt nie pamięta, co ma znaczenie.
Mierzenie tego, co jest łatwe, nie tego, co użytkownicy czują. Użycie CPU nie jest SLI. Nieudane kasy są.
Brak konsekwencji. SLO bez polityki budżetu błędów to życzenie. Zdecyduj z wyprzedzeniem, co się stanie przy 50%, 100% i 150% spalonym.
Nigdy nie przeanalizowanie celu. Przejrzyj go co kwartał. Jeśli nigdy nie zbliżysz się do wydania budżetu, cel jest zbyt łagodny.

Golden retriever asleep in a quiet home office at night while the dashboard stays green

Teraz część poniedziałkowa. Wybierz jedną usługę. Zapisz jeden SLI w jednym zdaniu, które osoba niebędąca inżynierem mogła by śledzić. Ustaw łagodny cel, 99,5% lub 99,9%. Zbuduj dwie zakładki wyżej, zaloguj incydenty z ostatniego miesiąca, i zobacz co budżet mówi.

Jeśli odpowiedź brzmi „spaliśmy 300% tego", właśnie odkryłeś, dlaczego wszyscy czują się zmęczeni. Jeśli odpowiedź brzmi „spaliśmy 4%", zaostrzaj cel lub wysyłaj szybciej. Tak czy inaczej, masz teraz liczbę do kłócenia się o zamiast uczucia.

Chłopak dobry. Teraz idź i zaloguj te incydenty.

Frequently asked questions

Co to jest SLO w prostych słowach?

SLO (service level objective) to cel niezawodności dla usługi, taki jak '99,9% żądań się powiedzie w ciągu 30 dni'. Zamienia niejasny cel w taki jak 'bądź niezawodny' na liczbę, którą zespół może mierzyć i śledzić.

Jaka jest różnica między SLO a SLA?

SLO to cel wewnętrzny. SLA to umowa z konsekwencjami, zwykle zwrotami lub kredytami, jeśli cel zostanie pominięty. Jeśli brak celu nie niesie żadnej kary umowy, to SLO. Ustaw swoje SLO bardziej wymogowe niż SLA.

Co to jest budżet błędów?

Budżet błędów to ilość awarii, którą pozwala SLO. SLO 99,9% pozostawia budżet 0,1%, czyli 43,2 minuty przestojów w ciągu 30 dni. Zespoły wydają go na incydenty i ryzykowne wydania, i spowalniają się, gdy się skończy.

Jak oblicza się SLO w Excelu lub Google Sheets?

Oblicz całkowitą liczbę minut w oknie (dni*24*60), pomnóż przez (1 - cel) aby uzyskać budżet, a następnie odejmij zarejestrowany czas przestojów. W przypadku SLI opartych na żądaniach podziel dobre żądania przez całkowitą liczbę żądań, na przykład przy użyciu COUNTIFS i COUNTA.

Co to jest dobry cel SLO?

Zacznij od łatwo osiąganego, a następnie zaostrzaj. 99,5% lub 99,9% pasuje do większości narzędzi wewnętrznych i małych produktów. 99,99% pozostawia około 4 minuty przestojów na miesiąc i rzadko warte kosztu, chyba że za to płaci klient.

Ile SLO powinno mieć usługa?

Dwa lub trzy, które mapują to, co użytkownicy faktycznie czują, takie jak dostępność i opóźnienie. Więcej niż to i nikt nie pamięta, które naprawdę ma znaczenie.