Czym jest SLO? Service Level Objectives wyjaśnione

Czym jest SLO? Service Level Objective (SLO) to wewnętrzny cel niezawodności, który Twój zespół ustala dla siebie. Nie umowa z klientami, nie surowa metryka z rozwiązania monitoringu. SLO odpowiada na jedno pytanie: jak niezawodna musi być ta usługa i jak będziemy to mierzyć?

Kompletne SLO wygląda tak: 99,9% żądań HTTP do /api/checkout zwraca status powodzenia i kończy się w ciągu 300ms, mierzone w rolującym oknie 30 dni. Trzy komponenty: pomiar, cel i okno. Wszystkie trzy mają znaczenie.

SLI, SLO, SLA: Trzy skróty o różnych znaczeniach

Te trzy terminy pojawiają się razem stale. Zespoły używają ich zamiennie. Opisują różne rzeczy.

SLI (Service Level Indicator) to surowy pomiar, który produkuje Twój system monitoringu. Wskaźnik błędów jako procent całkowitych żądań. Latencja P99 w milisekundach. Procent pomyślnych zapisów do bazy danych. SLI to liczba, która wychodzi z Datadog, Grafany lub innego stosu, którego używasz. Mówi Ci, co się stało.

SLO (Service Level Objective) to cel, który definiujesz na podstawie SLI. Odpowiada: z wszystkich możliwych wartości, które może przyjąć SLI, który zakres liczy się jako akceptowalny? Jeśli Twój SLI to wskaźnik błędów, a Twoje SLO to „wskaźnik błędów poniżej 0,1% przez 99% pięciominutowych okien", masz test pass/fail, a nie tylko liczbę na dashboardzie.

SLA (Service Level Agreement) to zewnętrzna wersja tej samej logiki, z konsekwencjami umownymi. Twoja SLA może mówić: „uptime 99,5% lub wystawimy kredyt serwisowy 20%". Twoje SLO powinno siedzeć powyżej tego progu, aby Twój zespół wiedział o degradacji zanim naruszenie SLA stanie się rozmową z klientem.

Przerwa między SLO a SLA to nie zapas na brak uwagi. To zaplanowany margines, który zamienia „zmierzamy ku naruszeniu" w „mamy czas to naprawić teraz".

Jedno ważne rozróżnienie: SLI są mierzone ciągle, ale SLO są oceniane w oknie. Ten sam wskaźnik błędów mierzony przez siedem dni w stosunku do 30 dni daje bardzo różne wyniki pass/fail. Jeden zły час znacząco wpływa na siedmiodniowe okno. W oknie 30 dni to mniej więcej jeden procent okresu. Wybranie właściwego okna jest równie ważne co wybranie właściwego celu.

Czy „Jak niezawodna?" to kompletne pytanie?

Zanim wybierzesz liczbę, musisz zrozumieć, co użytkownik doświadcza, gdy usługa się degraduje. „Potrzebujemy pięciu dziewiątek" to stwierdzenie ambicji, nie pomiar. Interfejs API checkout na poziomie dostępności 99,999% oznacza mniej więcej 26 sekund błędów miesięcznie. Dla usługi przetwarzającej dziesięć transakcji na sekundę, może to być akceptowalne. Dla usługi obsługującej rozliczenia finansowe w czasie rzeczywistym, może nie być.

Właściwe SLO zależy od dwóch czynników: wpływu degradacji na użytkownika oraz operacyjnych kosztów utrzymania ściślejszego celu.

Jeśli Twoja usługa zanotowała dostępność 99,3% w ciągu ostatnich 90 dni, rozpoczęcie pierwszego SLO na poziomie 99,9% to aspiracja, nie kalibracja. Praktyczne podejście: wyciągnij dane SLI z ostatnich 90 dni, ustaw SLO trochę ściślejsze niż obecna wydajność, a następnie przegląd co kwartał. SLO 99,5% z rzeczywistą polityką error budget bije SLO 99,9%, które jest ignorowane za każdym razem, gdy się narusza.

Typowe cele SLO według typu usługi:

• API skierowane do użytkownika (checkout, autentykacja): dostępność 99,9%, latencja P99 poniżej 500ms

• Usługi wewnętrzne (potoki danych, zadania wsadowe): wskaźnik sukcesu 99,5%, mierzony przy ukończeniu zadania

• Narzędzia administratorskie: dostępność 99% jest zazwyczaj wystarczająca

• Pracownicy w tle: SLO na czas ukończenia zadania zamiast statusu HTTP

Wybierając, które SLI mierzyć, użyj czterech sygnałów z książki Google SRE jako punktu wyjścia: dostępność (czy żądanie się udało?), latencja (jak długo to trwało?), przepustowość (ile żądań system obsługuje?) i wskaźnik błędów (jaka frakcja się nie powiodła?). Nie każda usługa potrzebuje wszystkich czterech. Większość zespołów zyskuje rzeczywisty sygnał z dostępności plus jeden percentyl latencji. Dodawanie więcej SLI zanim masz niezawodną linię bazową dla pierwszych dwóch to powszechny sposób na stworzenie szumu bez wglądu.

Error Budget: Od celu do decyzji operacyjnej

Error budget to matematyczna odwrotność Twojego SLO. Jeśli Twoje SLO dostępności to 99,9%, to 0,1% żądań w oknie pomiaru może się nie powieść. Dla usługi otrzymującej milion żądań miesięcznie, to 1000 nieudanych żądań zanim SLO się narusza.

Error budget czyni SLO operacyjnie użytecznym. Bez niego, SLO to próg, który się narusza, a potem się dyskutuje. Z polityką error budget, staje się ramą decyzyjną.

Kiedy error budget jest zdrowy, powiedzmy, że 80% pozostaje przy dwóch tygodniach do końca okna, zespół może wysyłać szybko. Nowe funkcje, eksperymenty, bardziej ryzykowne wdrożenia, wszystko jest w normie. Error budget to sygnał, że prędkość nie jest obecnie ograniczeniem.

Kiedy error budget się wypalnia, zespół się zmienia. Niekrytyczne zmiany czekają. Polityka wdrażania się zaostrza. Naprawy niezawodności otrzymują priorytet. Error budget podjął decyzję, nie osąd kierownika o tym, czy rzeczy „czują się stabilne wystarczająco".

Konkretny scenariusz: usługa checkout miała 12-minutową degradację we wtorek po południu, zużywając 15% miesięcznego error budget. Drugi incydent w czwartek zużył kolejne 12%. Przy 27% zużytym w pierwszym tygodniu miesiąca, polityka error budget się aktywuje: brak nowych wdrożeń funkcji do czasu ukończenia pośmiertnej analizy i zastosowania poprawki głównej przyczyny. Ta decyzja nie jest negocjacją produktu/inżynierii. To odczyt z danych.

Google opublikowało swoją politykę error budget w SRE Workbook: pojedynczy incydent zużywający więcej niż 20% kwartalnego error budget wymaga pośmiertnej analizy. To jedna konkretna polityka do dostosowania.

Alerty burn rate idą dalej. Zamiast czekać, aż error budget prawie się skończy, alert burn rate się wyzwala, gdy tempo konsumpcji sugeruje, że wyczerpiesz budget zanim okno się skończy. Jeśli Twoja usługa zużywa error budget 14 razy szybciej niż normalnie, wyczerpiesz 30-dniowy budget w mniej więcej 50 godzin. Alert przy tym tempie daje zespołowi dwa dni na odpowiedź zamiast powiadomienia o naruszeniu po tym, jak klienci już zauważyli. Narzędzia takie jak Datadog i Grafana obsługują alerty multi-window, multi-burn-rate od razu. Skonfigurowanie tego zajmuje popołudnie. Brak tego oznacza odkrycie naruszeń SLO po tym, jak klienci już zauważyli.

Ustawianie pierwszego SLO bez błędu w liczbie

Najczęstszy błąd to rozpoczęcie od celu zanim ustalisz pomiar.

Krok 1: Zdefiniuj SLI. „Dostępność" to nie SLI. „Żądania HTTP zwracające status bez błędu (2xx/3xx), podzielone przez wszystkie żądania HTTP" to SLI. Pomiar musi być tworzony z telemetrii, którą już masz. Obietnica instrumentacji czegoś „wkrótce" oznacza, że SLO nie ma źródła danych.

Krok 2: Wyciągnij dane historyczne. Spójrz na ostatnie 60 do 90 dni. Jak faktycznie wygląda SLI? Jakie były dwa lub trzy najgorsze dni? To mówi Ci, jaki cel jest osiągalny dzisiaj i ile marginesu masz zanim pierwsze naruszenie.

Krok 3: Ustaw okno pomiaru. Rolujące okna 30 dni są najczęstsze i dają Ci responsywne, zawsze aktualne dane. Okna kalendarza miesięcznego tworzą efekty klifu na granicach miesięcy. Siedmiodniowe rolujące okna są bardziej czułe, ale mogą wyzwalać zbyt często dla zespołów wciąż budujących mięśnie niezawodności.

Krok 4: Napisz politykę error budget zanim jej będziesz potrzebować. Przy jakim tempie spalania error budget zespół wstrzymuje zmiany niekrytyczne? Przy jakim tempie spalania on-call eskaluje? Udokumentuj to zanim incydent, nie w jego trakcie.

Krok 5: Zacznij od jednej usługi. Definiowanie SLO dla 15 usług na raz produkuje 15 dashboardów, które nikt nie czyta. Zacznij od najbardziej widocznej dla użytkownika usługi, uruchom jeden kwartał, dostosuj, a następnie rozszerz.

Opcje okna pomiaru i ich kompromisy:

• 7-dniowe rolujące: szybka informacja zwrotna, bardziej wrażliwe na krótkie incydenty, mogą tworzyć zmęczenie alertów

• 30-dniowe rolujące: najczęstsze, balansuje sygnał i szum

• 90-dniowe rolujące: przydatne dla rzadkich, ale krytycznych operacji, takich jak zadania wsadowe

Wypracowany przykład: dla API e-commerce możesz ustawić pierwsze SLO jako „95% żądań do /checkout powiodło się i zwróciło w ciągu 500ms, mierzone w rolującym oknie 28 dni". To daje Ci konkretne SLI (wskaźnik sukcesu w połączeniu z latencją), konkretny cel (95%) i zdefiniowane okno (28 dni). Od tego miejsca obliczasz error budget: 5% całkowitych żądań może się nie powieść lub być powolnym. Jeśli otrzymujesz 200 000 żądań dziennie, Twój miesięczny error budget to mniej więcej 280 000 nieudanych żądań zanim SLO się narusza.

Gdzie monitorowanie SLO łączy się z pracą nad codebase

Error budget spalający się szybciej niż oczekiwane to problem codebase częściej niż problem infrastruktury. Skoki latencji śledzą N+1 zapytania, które przeszły niezauważone w przeglądzie kodu. Spadki dostępności śledzą wyjątek nullowego wskaźnika w ścieżce kodu, która wyzwala się tylko pod konkretną kombinacją obciążenia. SLO wykrywa objawy. Codebase zawiera przyczynę.

Tu właśnie czas między „alert się wyzwala" a „przyczyna główna zidentyfikowana" staje się praktycznym ograniczeniem. Kiedy usługa checkout zużywa 30% error budget w trzy dni, a inżynier on-call musi grep'ować 150 000-liniowy monorepo, aby znaleźć logikę ponowienia prób, która zachowuje się inaczej pod obciążeniem, SLO robi swoją pracę. Narzędzia do analizy głównej przyczyny nie.

Zespoły, które wyposażyły wyszukiwanie kodu wspomaganego przez AI obok stosu obserwacyjności, raportują znacznie krótszy czas diagnostyki podczas incydentów. Zapytanie w języku naturalnym o to, gdzie usługa płatności obsługuje ponowne próby na odpowiedziach 503, powierzchniuje odpowiednią funkcję w sekundach zamiast 20 minut potrzebnych do czytania pięciu plików i jednej strony Confluence. 43-minutowe okno error budget spędzane jest na naprawieniu problemu, a nie na czytaniu kodu.

Cztery sposoby, na które zespoły źle interpretują SLO

Zbyt wiele SLO. Zespół śledący jednocześnie 12 SLO będzie traktować alerty jako szum w tle w ciągu dwóch miesięcy. Trzy do pięciu SLO skupionych na najbardziej widocznych dla użytkownika zachowaniach to rozsądny pułap dla zespołu 10 inżynierów. Jeśli potrzebujesz więcej, organizuj je warstwami: krytyczne SLO, które wyzwalają polityki error budget, oraz informatyczne SLO, które po prostu generują dane.

Pomiar infrastruktury, a nie doświadczenia użytkownika. Wykorzystanie CPU, użycie pamięci i I/O dysku to przydatne sygnały debugowania. To słabe SLI, chyba że możesz udowodnić, że bezpośrednio korelują z widoczną dla użytkownika degradacją. Mierz, co użytkownik doświadcza: wskaźnik sukcesu żądania, czas odpowiedzi na P95 lub P99, czas do renderowania pierwszego znaczącego kawałka danych.

SLO ustalone bez analizy kosztów operacyjnych. Osiągnięcie dostępności 99,99% zazwyczaj wymaga aktywnej redundancji, failover wieloregionowego i natychmiastowej odpowiedzi on-call o każdej porze. Jeśli zespół nie może zrównoważenie operować w ten sposób, SLO będzie regularnie naruszane, a potem ignorowane. Naruszane i ignorowane SLO jest gorsze niż brak SLO: trenuje zespół do odrzucania alertów niezawodności.

Korzystanie z danych error budget do przypisania winy. Jeśli pierwszą odpowiedzią na spalony error budget jest identyfikacja, kto wysłał zmianę, która to spowodowała, raportowanie przestanie być szczere. Error budget to zasób zespołu. Kiedy budget się wyczerpuje, pytanie to „co naprawiamy?" nie „kto jest odpowiedzialny?"

Test zdrowia organizacyjnego: czy podzielibyś aktualny status error budget na all-hands inżynierskie bez wyzwolenia dyskusji politycznej? Jeśli nie, kultura wokół SLO potrzebuje więcej uwagi niż samy cele. Metryki niezawodności działają jako narzędzia decyzyjne tylko wtedy, gdy zespół ufa, że zgłoszenie problemu nie stwarza osobistego ryzyka.

SLO potrzebuje przeglądów kwartalnych, nie rocznych

Ustawianie SLO to nie jednorazowa kalibracja. Usługi się zmieniają, wzorce ruchu się przesuwają i koszt utrzymania danego poziomu niezawodności zmienia się wraz z nimi.

Co 90 dni, przejdź przez cztery pytania:

1. Czy SLO się utrzymało? Jeśli tak, było wygodne, sugerując, że cel mógłby być ściślejszy?

2. Czy error budget całkowicie się spalił? Jakie incydenty to spowodowały?

3. Czy SLO wygenerowało użyteczny sygnał, czy zespół zastępował politykę error budget?

4. Czy okno pomiaru jest wciąż odpowiednie dla sposobu, w jaki usługa jest używana?

Jeśli zespół zastępował politykę error budget więcej niż dwukrotnie w kwartale, SLO jest prawdopodobnie źle skalibrowane. Albo cel jest zbyt ścisły, albo okno jest zbyt krótkie, albo pomiar nie odzwierciedla tego, co użytkownicy faktycznie doświadczają.

SLO to narzędzia kalibracji. Mają być dostosowywane w miarę poprawy niezawodności, wzrostu ruchu i zmian tolerancji biznesu na przestój. Zespół, który przegląda i dostosowuje swoje SLO co kwartał, prowadzi praktykę niezawodności. Zespół, który je ustanowił raz i nie dotykał ich od tego czasu, ma dashboard z liczbami, które nic dla nikogo nie znaczą.