Co to jest SLO? Budżet błędów i burn rate w praktyce

Co to jest SLO? Cel poziomu usługi (ang. service level objective) to wymagany poziom niezawodności jednego, konkretnego zachowania widocznego dla użytkownika, mierzony w stałym oknie czasowym. „99.9% żądań do koszyka kończy się sukcesem poniżej 800 ms przez 30 dni” to SLO. „Strona ma działać szybko” to życzenie. Liczy się mniej sama liczba niż to, co ona kontroluje: SLO decyduje, kiedy zespół wciąż wypuszcza zmiany, a kiedy przestaje.

Jest 03:12. PagerDuty pisze, że latencja w koszyku jest „podwyższona”. Otwierasz dashboard i widzisz linię p99, która od czterdziestu minut powoli rośnie. Nikt nie potrafi powiedzieć, czy to problem, bo nikt nie zapisał, ile latencji jest za dużo. Spór, który potem toczy się na call-u, z jednym okiem na Slacku, to koszt braku SLO.

SLI, SLO, SLA: trzy słowa, trzech właścicieli

Ludzie używają tych pojęć zamiennie. To nie to samo, a pomylenie ich prowadzi do kontraktu, którego zespół nie jest w stanie dotrzymać.

• SLI (wskaźnik poziomu usługi) to pomiar. Stosunek dobrych zdarzeń do poprawnych: żądania, które zwróciły 2xx w mniej niż 800 ms, podzielone przez wszystkie żądania, które powinny się udać.

• SLO (cel poziomu usługi) to próg dla tego stosunku w danym oknie. 99.9% w ciągu 30 dni.

• SLA (umowa o poziomie usług) to kontrakt z klientem, z pieniędzmi w tle na wypadek niedotrzymania. Zawsze jest luźniejsza od SLO. Jeśli SLA mówi 99.9%, a SLO też 99.9%, nie masz miejsca, żeby zauważyć problem, zanim zaczniesz płacić kredyty.

Rozdział o celach poziomu usługi w książce Google SRE pokazuje tę samą granicę: SLO to wewnętrzny cel, ustawiony ostrzej niż cokolwiek obiecujesz na zewnątrz. Inżynierowie są właścicielami SLI i SLO. Produkt i dział prawny są właścicielami SLA.

Nie dodawaj czwartego pojęcia dla każdej metryki, którą już zbierasz. CPU, pamięć i głębokość kolejki są przydatne przy debugowaniu. Nie są SLI, bo żaden klient ich nie odczuwa bezpośrednio.

Jak wygląda dobry SLI i gdzie go mierzyć

Dobry SLI jest stosunkiem, mierzonym jak najbliżej użytkownika, i ma jasną definicję tego, co jest „dobre”.

W usłudze opartej na żądaniach domyślnie wystarczą dwa SLI: dostępność (odpowiedzi inne niż 5xx do wszystkich poprawnych żądań) i latencja (żądania poniżej progu do wszystkich poprawnych żądań). Używaj progu, nie średniej. Średnia ukrywa ogon, a ogon to miejsce, skąd biorą się zgłoszenia do supportu.

Mierz na load balancerze albo na krawędzi, nie wewnątrz usługi. Usługa, która pada przy starcie, raportuje idealny wskaźnik błędów dla żądań, których nigdy nie dostała. Metryki po stronie serwera są ślepe na tę awarię, a użytkownik widzi ją jako przestój.

Bądź jawny co do wykluczeń. Health checki, syntetyczne testy z twojego własnego monitoringu i odpowiedzi 4xx spowodowane złym wejściem klienta zwykle nie powinny cię obciążać. Zapisz wykluczenia obok SLO. Gdy ktoś podczas przeglądu incydentu kwestionuje liczbę, dyskusja powinna dotyczyć definicji, a nie tego, co akurat pokazuje dashboard.

Nie potrzebujesz dedykowanego produktu SLO, żeby zacząć. Potrzebujesz licznika dobrych zdarzeń, licznika wszystkich zdarzeń i miejsca, gdzie przechowasz je przez 30 dni. Jeśli metryki już leżą w hostowanej platformie, funkcja SLO bywa cienką warstwą nad danymi, za które i tak płacisz.

Datadog ma SLO natywnie, z alertami burn-rate, i to łatwa ścieżka, jeśli trace'y i metryki już tam są. Haczyk to rachunek: metryki niestandardowe i tagi o wysokiej kardynalności mnożą się szybko, więc sprawdź cenę serii SLI, zanim się zdecydujesz.

Jeśli działasz na Prometheusie, Grafana obejmuje ten sam obszar przez recording rules i narzędzia do SLO, za cenę większej konfiguracji i większej ilości twojego czasu.

Uczciwe porównanie to czas do pierwszego użytecznego alertu kontra koszt przy skali. Datadog wygrywa pierwszy, Grafana z Prometheusem zwykle drugi. Wybierz według tego, czego twojemu zespołowi brakuje.

Arytmetyka dziewiątek, zanim wybierzesz cel

Każda dodatkowa dziewiątka zmniejsza dozwolony czas niedostępności dziesięciokrotnie. Ta tabela powinna być w dokumencie.

• 99% w ciągu 30 dni: 1% budżetu błędów, 7.2 godziny pełnej niedostępności.

• 99.9%: 0.1% budżetu, 43.2 minuty.

• 99.95%: 0.05% budżetu, 21.6 minuty.

• 99.99%: 0.01% budżetu, 4.32 minuty.

Przeczytaj ostatnią linię jeszcze raz. Przy 99.99% jeden zły deploy, którego wykrycie i wycofanie zajmuje pięć minut, już zjadł miesiąc. Człowiek nie zareaguje na pager, nie otworzy laptopa i nie cofnie zmiany w mniej niż cztery minuty, więc taki cel jest osiągalny tylko z automatyzacją: bramką, która zatrzymuje rollout, zanim budżet się skończy.

Wybierz liczbę, której usługa naprawdę potrzebuje. Większość wewnętrznych API żyje spokojnie na 99.9%. Ścieżka płatności może uzasadniać więcej. Nocny batch może wystarczyć na 99%. Wybór 99.99%, bo brzmi poważnie, to sposób na zapisanie się do dyżurów, których zespół nie jest w stanie obsadzić.

Budżet błędów jest sednem, nie SLO

SLO na poziomie 99.9% oznacza, że wolno ci zawodzić przez 0.1% czasu. Ten 0.1% to twój budżet błędów i to najbardziej użyteczna idea w całej dziedzinie.

Budżet zamienia kłótnię w liczbę. Produkt chce wypuścić ryzykowną migrację. SRE mówi, że to ryzykowne. Bez budżetu to opinia kontra opinia i wygrywa staż. Z budżetem pytanie brzmi: ile zostało i ile ta zmiana realnie może zjeść?

Dwie zasady sprawiają, że to działa.

1. Budżet pozostał: wypuszczaj. Wolno ci brać ryzyko, więc je bierz. Zespół, który nigdy nie wydaje budżetu, przeinwestowuje w niezawodność, o którą użytkownicy nie prosili.

2. Budżet wyczerpany: zamrażaj. Praca nad funkcjami się wstrzymuje, aż prace nad niezawodnością przywrócą SLI powyżej celu. To działa tylko wtedy, gdy kierownictwo zgodziło się na to przed pierwszym incydentem, a nie w jego trakcie.

Jeśli druga zasada nie jest uzgodniona z góry, nie masz SLO. Masz dashboard z zieloną i czerwoną strefą.

Alertuj na burn rate, nie na sam SLI

Tu większość pierwszych prób się wywala. Ktoś ustawia alert, gdy dostępność spada poniżej 99.9%. Alert odpala, gdy szkoda już jest zrobiona, albo mruga przy każdym drobnym zakłóceniu, albo jedno i drugie.

Lepszym sygnałem jest burn rate: jak szybko zjadasz budżet w stosunku do tempa, które wyczerpałoby go dokładnie na końcu okna. Burn rate 1 oznacza, że miesiąc skończysz z zerowym budżetem. Burn rate 14.4 oznacza, że na tym tempie cały miesięczny budżet przepadnie w około dwa dni.

Google SRE Workbook o alertowaniu na SLO zaleca parę długiego i krótkiego okna, żeby alert był jednocześnie istotny i wciąż aktywny. Przy 30-dniowym SLO dobrym punktem wyjścia są dwie strony:

• Burn rate 14.4 w ciągu 1 godziny, potwierdzony w ciągu 5 minut: zjada 2% miesięcznego budżetu. Obudź kogoś.

• Burn rate 6 w ciągu 6 godzin, potwierdzony w ciągu 30 minut: zjada 5% miesięcznego budżetu. Obudź kogoś.

Rachunek jest prosty. Okno 30 dni to 720 godzin. Spalanie z szybkością 14.4x przez godzinę zjada 14.4 / 720 = 2% budżetu. Krótkie okno pilnuje, żeby alert nie odpalił godzinę po tym, jak problem już się skończył.

Pierwsza reguła jako alert Prometheusa, przy założeniu, że nagrywasz wskaźnik błędów dla każdego okna:

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Checkout zjada 2% 30-dniowego budżetu błędów na godzinę"

Stała 0.001 to dozwolony odsetek błędów dla SLO 99.9%. Zmienisz cel, a ta stała przesunie się razem z nim. Trzymaj ją w jednym miejscu, bo inaczej alert i SLO rozjadą się, a nikt tego nie zauważy.

Wolniejsze spalanie nie wymaga pagera. Burn rate 1 utrzymywany przez trzy dni należy do ticketu na następny roboczy poranek. Budzenie kogoś z powodu powolnego wycieku uczy zespoły dyżurowe ignorować pager.

SLO podpięte pod rollout: część, którą większość pomija

SLO, które tylko produkuje raport, jest w połowie wykorzystane. Krok, który zmienia zachowanie, to podpięcie budżetu do ścieżki deployu, tak żeby wydanie zatrzymywało się samo.

Rollout progresywny z bramką SLO działa tak: wypuszczasz na 1% ruchu za flagą. Obserwujesz SLI dla tej kohorty względem bazy. Jeśli burn rate kohorty kanarkowej przekroczy próg, cofasz automatycznie. Jeśli się utrzymuje, przechodzisz na 5%, potem 25%, potem 100%.

To coś innego niż dashboard, który ktoś ma pilnować o 03:12. O 03:12 nie chcesz myśleć. Chcesz przycisku, a najlepiej w ogóle żadnego przycisku.

Tu flagi zarabiają na swoje miejsce, bo flaga zamienia cofnięcie w zmianę konfiguracji, która trwa sekundy, a nie w redeploy, który trwa dziesięć minut.

LaunchDarkly i podobne platformy dają procentowy rollout i kill switch. Większość zostawia tobie decyzję: który SLI czytać, jaki próg uznać za zły i kto może nadpisać. To luka, którą automatyczny pilot z auto-rollbackiem na SLO ma zamykać, i to jest kąt, który bierzemy w upstreamapi. LaunchDarkly wygrywa szerokością SDK i funkcjami enterprise, i mówimy to otwarcie.

Oto kształt bramki w TypeScript. Logika decyzji to część, którą warto napisać samemu, niezależnie od systemu flag:

type Kohorta = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDZET = 1 - SLO_TARGET; // 0.001
const PROG_PAGE_BURN_RATE = 14.4;

function burnRate(k: Kohorta): number {
  if (k.total === 0) return 0;
  const wskaznikBledow = 1 - k.good / k.total;
  return wskaznikBledow / BUDZET;
}

export function decyzjaRollout(kanarek: Kohorta): "advance" | "hold" | "revert" {
  if (kanarek.total < 500) return "hold"; // za mało ruchu, żeby ocenić
  return burnRate(kanarek) > PROG_PAGE_BURN_RATE ? "revert" : "advance";
}

Zwróć uwagę na gałąź hold. Kanarek na 1% cichej usługi może zobaczyć czterdzieści żądań w ciągu dziesięciu minut, a jeden błąd na czterdzieści to 2.5% wskaźnika błędów. Bez minimalnej próbki bramka cofa na szum i zespół uczy się jej nie ufać.

Błędy, które widzimy w zespołach po 80 inżynierach

Te same kilka porażek pojawia się w wielu zespołach i prawie żadna z nich nie jest techniczna.

• Za dużo SLO. Dwadzieścia celów na usługę znaczy, że nikt nie pamięta żadnego. Wystarczą dwa, trzy na ścieżkę użytkownika.

• SLO, na które nikt się nie zgodził. Inżynier pisze je sam w weekend. Produkt nigdy ich nie widział, więc polityka budżetu sypie się przy pierwszym „nie” dla launchu.

• SLO ustawione na obecną wydajność. Jeśli usługa działa dziś na 99.97%, ustawienie celu na 99.97% nie zostawia budżetu i gwarantuje chybienie. Ustaw go tam, gdzie użytkownicy zaczynają być niezadowoleni, a to prawie zawsze jest niżej.

• Traktowanie SLO jak czegoś stałego. Przeglądaj liczbę co kwartał. Jeśli nigdy nie wydajesz budżetu, zaostrz cel albo wypuszczaj szybciej. Jeśli co miesiąc go przepalasz, napraw system albo przyznaj, że cel był fantazją.

• Liczenie tego, co łatwe, zamiast tego, co odczuwalne. Odpowiedź 200 z pustym koszykiem to sukces w logach i porażka dla klienta. Definiuj „dobre” z perspektywy użytkownika.

Kto napisze pierwsze SLO w tym tygodniu

Nie potrzebujesz programu. Wybierz jedną ścieżkę, której awaria sprawiłaby, że CEO dzwoni do kogoś. Zdefiniuj dla niej jeden SLI dostępności i jeden SLI latencji. Ustaw cel na 99.9% na pierwszy kwartał, spisz politykę zamrożenia w dwóch zdaniach i poproś produkt o pisemne „zgadzam się”.

Potem dodaj alert burn-rate i miejsce, gdzie cały zespół zobaczy pozostały budżet.

Jeśli potrzebujesz lekkiego startu przed pełną platformą, Better Stack obsługuje monitoring dostępności i pager incydentów przy dużo mniejszej konfiguracji, choć rachunku budżetu nie policzy za ciebie.

Pierwsza wersja będzie błędna. To akceptowalne. Liczy się, że następny przegląd incydentu zacznie się od liczby zapisanej wcześniej, a nie od odczucia.

Weź ostatni incydent w swoim zespole. Czy była wtedy zapisana liczba, która mówiła, czy to ma znaczenie? Jeśli szczerze odpowiadasz „nie”, to jest twoje pierwsze SLO, a post-mortem już powiedział, co mierzyć. Jak wygląda twoje 03:12 teraz?