SLI (service level indicator, wskaźnik poziomu usług) to pomiar tego, jak zachowuje się Twoja usługa, na przykład odsetek udanych żądań. SLO (service level objective, cel poziomu usług) to wewnętrzny cel dla tego pomiaru, na przykład 99,9% udanych kontroli w ciągu 30 dni. SLA (service level agreement, umowa o poziomie usług) to obietnica składana klientom, zwykle z niższym celem niż SLO i konsekwencją w razie jego niedotrzymania, na przykład rekompensatą (service credit). Wskaźnik to to, co mierzysz, cel to to, do czego dążysz, a umowa to to, co podpisujesz.
Ten poradnik wyjaśnia każde z pojęć na przykładach, pokazuje, ile minut oznaczają poszczególne procenty dostępności, i krok po kroku omawia wybór wskaźników dla strony lub API, ustalenie, co liczy się jako niedostępność, oraz napisanie SLA zrozumiałego dla klientów.
Trzy pojęcia w prostych słowach
SLI: pomiar
Wskaźnik poziomu usług to liczba, którą można wyliczyć z rzeczywistych danych. Niemal zawsze jest to proporcja: dobre zdarzenia podzielone przez wszystkie zdarzenia. Dla strony internetowej może to być odsetek kontroli dostępności, które zwróciły oczekiwaną odpowiedź. Dla API może to być odsetek żądań, na które odpowiedziano statusem innym niż 5xx w czasie poniżej 500 milisekund. SLI nie ma przypisanego celu. Mówi po prostu, co się wydarzyło.
SLO: cel
Cel poziomu usług nakłada na SLI wartość docelową i okno czasowe. „99,9% kontroli procesu zakupowego kończy się sukcesem, mierzone w kroczącym oknie 30 dni” to SLO. To narzędzie wewnętrzne. Mówi zespołowi, kiedy niezawodność jest na tyle dobra, by dalej wypuszczać nowe funkcje, a kiedy pora zwolnić i zająć się poprawkami.
SLA: umowa
Umowa o poziomie usług to zewnętrzna obietnica, zapisana w umowie lub regulaminie. Określa usługę, cel, sposób pomiaru, wyłączenia i to, co dostaje klient, jeśli cel nie zostanie dotrzymany. Nie każda usługa potrzebuje SLA, ale każde SLA potrzebuje stojącego za nim SLO, bo inaczej nie masz wczesnego ostrzeżenia, że zaraz je złamiesz.
Jak SLI, SLO i SLA do siebie pasują
Traktuj je jak warstwy. SLI to surowy sygnał. SLO to bardziej rygorystyczna, wewnętrzna linia wyznaczona na tym sygnale. SLA to luźniejsza, zewnętrzna linia na tym samym sygnale. Typowa konfiguracja dla produktu SaaS wygląda tak (przykładowe wartości):
SLI: odsetek cominutowych kontroli app.lumenanalytics.io, które zwracają status 200 i zawierają tytuł dashboardu.
SLO: 99,95% w miesiącu kalendarzowym.
SLA: 99,9% w miesiącu kalendarzowym, z rekompensatą w razie niedotrzymania.
Różnica między 99,95% a 99,9% to margines bezpieczeństwa. Jeśli zespół w drugim tygodniu widzi, że SLO się osuwa, wciąż ma czas zareagować, zanim zagrożona będzie obietnica z umowy.
Procent dostępności w minutach
Na papierze cele dostępności wyglądają podobnie, ale każda kolejna dziewiątka zmniejsza dopuszczalny czas niedostępności dziesięciokrotnie. Poniższa tabela zakłada przeciętny miesiąc (rok liczący 365,25 dnia podzielony przez 12), tak samo jak kalkulator dostępności; miesiąc 30-dniowy dopuszcza nieco mniej.
Cel dostępnościDopuszczalna niedostępność w miesiącuDopuszczalna niedostępność w roku99%7 h 18 min 18 s3 dni 15 h 39 min 36 s99,5%3 h 39 min 9 s1 dzień 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99%4 min 22 s52 min 35 s99,999 s5 min 15 s
Wynikają z tego dwie praktyczne konsekwencje. Po pierwsze, monitoring musi być w stanie zobaczyć niedostępność, którą obiecujesz. Przy kontrolach co pięć minut nie da się rzetelnie zmierzyć miesięcznego celu 99,99%, bo jedna przeoczona awaria może zużyć cały budżet. Po drugie, każdy cel powyżej 99,9% nie zostawia praktycznie miejsca na ręczną reakcję. Przy 99,99% jeden powolnie obsłużony nocny incydent przekreśla cały miesiąc.
Budżet błędów: jak zamienić SLO w decyzje
Budżet błędów (error budget) to ilość awarii, na którą pozwala SLO. Przy miesięcznym SLO 99,9% budżet wynosi 0,1% miesiąca, czyli około 43 minut i 49 sekund w przeciętnym miesiącu (43 minuty i 12 sekund w miesiącu 30-dniowym). Każdy incydent zużywa jego część.
Budżet sprawia, że niezawodność staje się wspólną decyzją, a nie przedmiotem sporu. Prosta zasada, którą stosuje wiele zespołów:
Zostało więcej niż pół budżetu: wdrażaj normalnie.
Zostało mniej niż pół: przeglądaj ryzykowne wdrożenia, przy zmianach w bazie danych niech patrzy druga para oczu.
Budżet wyczerpany: wstrzymaj wydania nowych funkcji dla tej usługi i pracuj nad przyczynami ostatnich incydentów, dopóki okno się nie zresetuje.
Przykład: harborlabs.dev ma miesięczne SLO 99,9% dla swojego publicznego API. 9. dnia miesiąca nieudane wdrożenie powoduje 18 minut błędów. 20. dnia problem z certyfikatem dokłada kolejne 9. To 27 z 43 minut, a do końca miesiąca zostało dziesięć dni. Zespół wstrzymuje kolejną migrację schematu do nowego miesiąca, bo jeszcze jeden incydent tej samej skali złamałby cel.
Wybór SLI dla strony lub API
Dobre SLI opisują to, czego doświadczają użytkownicy, a nie to, co „czują” Twoje serwery. CPU na 90% to nie SLI. Nieudany proces zakupowy już tak. Zacznij od dwóch lub trzech wskaźników na usługę:
Dostępność: odsetek udanych kontroli lub żądań. Dla strony internetowej „udana” powinna oznaczać właściwy kod statusu i właściwą treść, a nie samą odpowiedź.
Opóźnienie: odsetek żądań obsłużonych szybciej niż ustalony próg, na przykład 95% poniżej 800 ms. Odsetek łatwiej interpretować niż średnią, która ukrywa powolne przypadki odstające.
Poprawność: dla API odsetek odpowiedzi zawierających oczekiwane pola. Odpowiedź 200 z pustą treścią to nie sukces.
Mierz ścieżki, które mają znaczenie. Dla sklepu takiego jak northwind.shop oznacza to proces zakupowy i strony produktów, a nie tylko zbuforowaną stronę główną. Dla API oznacza to endpointy, z którymi integrują się klienci, najlepiej przez endpoint health check, który sprawdza bazę danych i inne zależności. Monitor API, który waliduje treść odpowiedzi, zamienia taki endpoint w SLI, któremu możesz ufać.
Co wlicza się do dostępności
Większość sporów o SLA nie dotyczy samej liczby. Dotyczy tego, co się liczy. Ustal te kwestie, zanim opublikujesz cel:
Planowane prace serwisowe. Wiele SLA wyłącza zaplanowane prace ogłoszone z wyprzedzeniem, na przykład 72 godzin, z limitem czterech godzin w miesiącu. Jeśli je wyłączasz, napisz, jak są ogłaszane, i ustal limit, bo inaczej „prace serwisowe” staną się furtką.
Częściowe awarie. Czy usługa jest niedostępna, jeśli logowanie działa, ale proces zakupowy nie? Określ objęte komponenty i to, czy awaria jednego z nich liczy się jako niedostępność całości.
Obniżona wydajność. Zdecyduj, czy odpowiedzi wolniejsze niż ustalony próg liczą się jako błędy. Jeśli strona ładuje się 30 sekund, użytkownicy uznają ją za niedziałającą.
Przyczyny poza Twoją kontrolą. Problemy z siecią po stronie klienta, nadużycia i siła wyższa są zwykle wyłączone. Twój własny dostawca hostingu zazwyczaj nie; klienci kupili usługę od Ciebie.
Minimalny czas trwania. Niektóre SLA liczą tylko awarie dłuższe niż minuta lub potwierdzone przez więcej niż jedną kontrolę, co odpowiada temu, jak monitoring potwierdza błędy.
Wewnętrznie często warto wliczać planowane prace serwisowe do SLO, nawet jeśli SLA je wyłącza. Użytkownicy i tak nie mogli korzystać z usługi, a SLO ma odzwierciedlać ich doświadczenie.
Jak napisać SLA dla klientów
Dobre SLA jest krótkie i konkretne. Powinno odpowiadać na sześć pytań: jaka usługa, jaki cel, jak mierzony, w jakim okresie, z jakimi wyłączeniami i co się dzieje, jeśli cel nie zostanie dotrzymany. Oto przykładowa klauzula, którą możesz dostosować:
Usługa: aplikacja internetowa Lumen Analytics pod adresem app.lumenanalytics.io
oraz publiczne API pod adresem api.lumenanalytics.io.
Cel: 99,9% dostępności w skali miesiąca.
Pomiar: dostępność jest mierzona zewnętrznymi kontrolami co minutę.
Minuta liczy się jako niedostępna, gdy usługa zwraca błąd (5xx)
lub nie odpowiada, co potwierdza druga kontrola.
Wyłączenia: zaplanowane prace serwisowe ogłoszone co najmniej 72 godziny
wcześniej na naszej stronie statusu (maks. 4 godziny w miesiącu); problemy
spowodowane przez własną sieć lub systemy klienta.
Rekompensaty: poniżej 99,9%: 10% miesięcznej opłaty.
poniżej 99,0%: 25% miesięcznej opłaty.
Klient zgłasza wniosek o rekompensatę w ciągu 30 dni od końca miesiąca.
Ustaw SLA poniżej tego, co faktycznie osiągasz. Jeśli historia monitoringu pokazuje 99,97% w ostatnim roku, obietnica 99,9% jest realistyczna. Obiecywanie 99,99%, bo lepiej brzmi, zamienia każdy incydent w problem umowny.
Niech rekompensaty będą proporcjonalne, a proces ich zgłaszania prosty. Klientom rzadko chodzi o pieniądze. Chcą widzieć, że traktujesz obietnicę poważnie i mierzysz uczciwie.
Pomiar za pomocą monitoringu zewnętrznego
Własne logi nie zmierzą awarii, podczas której Twój serwer nigdy nie otrzymał żądania. Awarie DNS, wygasłe certyfikaty, problemy z siecią i padnięty load balancer nie zostawiają śladu w wewnętrznych metrykach. Dlatego pomiar SLA powinien odbywać się z zewnątrz, tą samą drogą, którą docierają do Ciebie klienci. Jeśli dopiero poznajesz ten temat, zacznij od artykułu o tym, czym jest monitorowanie dostępności i jak działa.
Solidna konfiguracja do raportowania SLA:
Sprawdzaj co minutę. Interwał wyznacza rozdzielczość pomiaru.
Potwierdzaj każdy błąd drugą kontrolą. Dzięki temu pojedyncze zakłócenie w sieci nie trafia do statystyk niedostępności.
Waliduj treść. Sprawdzaj słowo lub pole, które pojawia się tylko wtedy, gdy usługa działa.
Zachowuj historię. Potrzebujesz czasów rozpoczęcia i zakończenia incydentów z każdego miesiąca, za który raportujesz.
Publikuj ją. Strona statusu z historią dostępności pozwala klientom widzieć te same liczby co Ty.
Uptimecheck obsługuje to wszystko: monitorowanie dostępności nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku, raporty SLA dla każdego monitora za bieżący lub poprzedni miesiąc albo ostatnie 7, 30 lub 90 dni w odniesieniu do Twojego celu, eksport CSV do miesięcznego zestawienia SLA oraz cotygodniowe i comiesięczne raporty e-mailem. Strona statusu połączona z tymi samymi monitorami pokazuje klientom historię dostępności, która stoi za Twoją obietnicą.
Dostępność to tylko jedna strona niezawodności. To, jak szybko wykrywasz i naprawiasz incydenty, decyduje, ile budżetu zużywa każdy z nich; o reagowaniu przeczytasz w artykule MTTR, MTTA i MTBF w praktyce.
Lista kontrolna: ustalanie SLI, SLO i SLA
Spisz ścieżki użytkowników, które mają znaczenie: logowanie, proces zakupowy, główne API.
Dla każdej ścieżki zdefiniuj jeden SLI dostępności i, tam gdzie to ważne, jeden SLI opóźnienia.
Mierz przez miesiąc lub dwa, zanim wybierzesz cele.
Ustaw SLO nieco poniżej tego, co osiągasz dziś, i uzgodnij zasady korzystania z budżetu błędów.
Ustaw SLA poniżej SLO, z jasnymi wyłączeniami i proporcjonalnymi rekompensatami.
Mierz z zewnątrz co minutę i co miesiąc przeglądaj wyniki.
Mierz obiecywaną dostępność z perspektywy klientów. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.