SLI, SLO, SLA i budżet błędów
Zdefiniujesz mierzalny cel dostępności i opóźnienia oraz zinterpretujesz prosty budżet błędów.
1. Krótka teoria
SLI to wskaźnik poziomu usługi, na przykład udział poprawnie obsłużonych żądań orders-api w określonym czasie. SLO to wewnętrzny cel dla wskaźnika: co najmniej 99,9% poprawnych żądań w ciągu 30 dni. SLA jest zobowiązaniem wobec odbiorcy usługi i może określać konsekwencje niespełnienia uzgodnionego poziomu. Wskaźnik dostępności musi mieć jasny mianownik, bo brak ruchu nie jest automatycznie dowodem pełnej dostępności. Dla API warto osobno rozważyć cel opóźnienia, na przykład 95% żądań poniżej 500 ms. Budżet błędów to dopuszczalna część niepowodzeń wynikająca z SLO. Przy celu 99,9% pozostaje 0,1% błędnych żądań w tym samym oknie; to nie jest przyzwolenie na ignorowanie pojedynczego krytycznego incydentu. Uproszczony odpowiednik czasowy dla 30 dni to 43,2 minuty niedostępności, ale tylko wtedy, gdy dostępność mierzona jest czasowo. Wskaźnik oparty na żądaniach liczy się inaczej. Porównuj SLI z celem i zapisuj okno, wyłączenia oraz sposób pomiaru. Nie potrzebujesz złożonych formuł SRE, aby wiedzieć, kiedy jakość usługi odbiega od obietnicy.
2. Przykłady komend
curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
Zbiera pojedynczy pomiar kodu i czasu do definicji wskaźnika.
$ curl -sS -o /dev/null -w '%{http_code} %{time_total}
' http://127.0.0.1:8000/health
python3 -c 'total=10000; good=9980; print(f"{good / total:.2%}")'
Liczy uproszczony SLI poprawnych żądań: 99,80%.
$ python3 -c 'total=10000; good=9980; print(f"{good / total:.2%}")'
99.80%
python3 -c 'print(round(30 * 24 * 60 * (1 - 0.999), 1))'
Liczy czasowy odpowiednik budżetu przy 99,9% dostępności przez 30 dni.
$ python3 -c 'print(round(30 * 24 * 60 * (1 - 0.999), 1))'
43.2
date -u --iso-8601=seconds
Zapisuje czas UTC potrzebny do jednoznacznego okna pomiaru.
$ date -u --iso-8601=seconds
journalctl -u orders-api --since '30 minutes ago' --no-pager
Porównuje pogorszenie SLI ze zdarzeniami aplikacji.
$ journalctl -u orders-api --since '30 minutes ago' --no-pager
git rev-parse HEAD
Zapisuje wersję kodu związaną z okresem pomiaru.
$ git rev-parse HEAD3. Zadanie praktyczne
orders-api zapisz dwa SLI: udział poprawnych żądań i udział żądań poniżej 500 ms. Ustal SLO 99,9% oraz 95% w oknie 30 dni. Oblicz wynik dla 9980 poprawnych odpowiedzi z 10000 i wskaż, czy cel dostępności został spełniony. W notatce odróżnij budżet błędnych żądań od uproszczonego budżetu czasu niedostępności i opisz, czego wymagałoby formalne SLA.
4. Typowe błędy
- Mylenie SLI będącego pomiarem z SLO będącym celem.
- Traktowanie wewnętrznego SLO jako automatycznej umowy SLA.
- Przeliczanie budżetu żądań na minuty bez założeń o ruchu i metodzie pomiaru.
- Podawanie procentu bez okresu i mianownika.
- Ignorowanie ważnego incydentu tylko dlatego, że budżet nie został jeszcze wyczerpany.
5. Podsumowanie
SLI mierzy usługę, SLO wyznacza cel, a SLA opisuje zobowiązanie wobec odbiorcy. Budżet błędów wynika z celu i tego samego okna pomiaru. Dobrze opisany wskaźnik pomaga podejmować decyzje bez mylenia procentu żądań z minutami niedostępności.