Budżet błędów (error budget) to ilość zawodności, na jaką Twoje SLO pozwala w danym okresie: 100% minus cel. SLO na poziomie 99,9% w okresie 30 dni daje budżet błędów 43 minut 12 sekund przestoju albo jednego nieudanego żądania na każde tysiąc. Dopóki budżet się nie wyczerpał, zespół może wdrażać i podejmować ryzyko. Gdy się skończy, pierwszeństwo ma praca nad niezawodnością, dopóki okno się nie odnowi.
Ta jedna zasada zamienia cel niezawodności w konkretne decyzje. Z tego poradnika dowiesz się, jak obliczyć budżet błędów, co powinno, a co nie powinno go zużywać, jak sprawdzić, w jakim tempie go wydajesz, i jak napisać politykę na moment, gdy się wyczerpie.
Jak obliczyć budżet błędów
Potrzebujesz dwóch rzeczy: SLO, czyli celu niezawodności, który sam sobie wyznaczasz, oraz okna, czyli okresu, w którym go mierzysz. Budżet błędów to to, co zostaje między celem a ideałem.
Error budget = (100% − SLO) × window
Dla SLO 99,9% w okresie 30 dni (43 200 minut): 0,1% × 43 200 = 43,2 minuty, czyli 43 minuty 12 sekund. Tabela pokazuje ten sam rachunek dla typowych celów, zaokrąglony w dół do pełnej sekundy.
SLOBudżet na 30 dniBudżet na 90 dni99%7 h 12 min21 h 36 min99,5%3 h 36 min10 h 48 min99,9 min 12 s2 h 9 min 36 s99,95 min 36 s1 h 4 min 48 s99,99%4 min 19 s12 min 57 s
Kalkulator SLA i dostępności robi to dla dowolnego celu i okresu. Korzysta ze średniego miesiąca (rok podzielony przez 12), więc dla 99,9% pokazuje 43 minuty 49 sekund, a nie wartość 30-dniową z tabeli powyżej.
Na podstawie czasu czy żądań
Budżet błędów można liczyć w dwóch jednostkach, zależnie od SLI, na którym opiera się Twoje SLO:
Na podstawie czasu: minuty przestoju mierzone sprawdzeniami z zewnątrz. To proste, łatwe do wyjaśnienia i zgodne z tym, jak pisze się większość umów SLA z klientami. Miesięczne SLO 99,9% pozwala na około 43 minuty.
Na podstawie żądań: odsetek nieudanych żądań liczony z logów load balancera lub aplikacji. Przy 2 milionach żądań miesięcznie i 99,9% budżet wynosi 2000 nieudanych żądań. Godziny szczytu ważą tu więcej niż spokojne, co lepiej oddaje odczucia użytkowników, ale wymaga logów, którym ufasz.
Wiele zespołów korzysta z obu: budżetu opartego na czasie, liczonego ze sprawdzeń zewnętrznych dla całej usługi, oraz budżetów opartych na żądaniach dla najważniejszych endpointów, takich jak checkout czy API.
Po co w ogóle budżet błędów
Bez budżetu niezawodność jest przedmiotem sporu. Dział produktu chce wdrażać, inżynierowie chcą zwolnić tempo, a wygrywa ten, kto mówi ostatni. Budżet zastępuje spór liczbą, na którą obie strony zgodziły się z góry.
Pokazuje, że 100% to zły cel. Cel 100% nie zostawia żadnego budżetu, więc każde wdrożenie jest ryzykiem, którego nikt nie może podjąć. Użytkownicy i tak nie odróżnią 99,99% od 100% przez własne Wi-Fi i sieci komórkowe.
Pozwala wydawać ryzyko. Dużą migrację, nowy region czy ryzykowne wydanie można zaplanować tak, by zmieściły się w budżecie, który został w tym miesiącu.
Ustala priorytety za Ciebie. Gdy budżet się skończy, polityka mówi, co dalej, więc nikt nie musi wygrywać spotkania, żeby praca nad niezawodnością trafiła na roadmapę.
Co zużywa budżet
Budżet zużywa wszystko, co Twoje SLI liczy jako złe. Zdecyduj o tym, pisząc SLO, a nie w trakcie incydentu.
Potwierdzone awarie: usługa nie odpowiedziała, odpowiedziała błędem albo zwróciła niewłaściwą treść.
Wolne odpowiedzi, jeśli Twoje SLI mówi, że żądanie wolniejsze od pewnego limitu liczy się jako nieudane. Strona, która ładuje się 30 sekund, działa, ale nie da się z niej korzystać.
Nieudane wdrożenia i wycofania – za te minuty, w których użytkownicy widzieli błędy.
Awarie u Twoich dostawców. Jeśli padnie operator płatności albo hosting DNS, Twoi użytkownicy i tak nie dokończą zakupu. Zużywa to Twój budżet, choć naprawa nie zależy od Ciebie – to dobry powód, by obserwować usługi, od których zależysz.
Planowane prace serwisowe – tylko jeśli tak stanowi SLO. Wiele zespołów wyłącza zapowiedziane okna serwisowe, z limitem na miesiąc.
Czego nie powinno się do niego liczyć: fałszywych alarmów. Pojedyncze nieudane sprawdzenie z powodu chwilowego zakłócenia sieci to nie przestój. Potwierdź awarię drugim sprawdzeniem, zanim ją policzysz, inaczej budżet będzie topniał przez problemy, których użytkownicy nigdy nie zauważyli.
Burn rate: jak szybko wydajesz budżet
Budżet mówi, na ile awarii możesz sobie pozwolić. Burn rate mówi, jak szybko go zużywasz. Workbook Google SRE definiuje go jako tempo, w jakim usługa zużywa budżet błędów względem SLO (Alerting on SLOs).
Burn rate 1 zużywa cały budżet dokładnie z końcem okna.
Burn rate 2 zużywa go w połowie okna: w 15 dni 30-dniowego miesiąca.
Pełna awaria przy SLO 99,9% oznacza burn rate 1000, bo każda minuta przestoju to tysiąc razy więcej niż dozwolone tempo. Dwadzieścia minut takiej awarii zużywa 46% budżetu na 30 dni.
Zalecany przez workbook punkt wyjścia dla SLO 99,9% to powiadomienie dyżurnego, gdy w ciągu godziny spłonie 2% budżetu na 30 dni (burn rate 14,4) lub 5% w ciągu sześciu godzin (burn rate 6), oraz zgłoszenie (ticket), gdy w ciągu trzech dni spłonie 10% (burn rate 1). Każdy alert sprawdza też krótkie okno, więc przestaje się uruchamiać wkrótce po ustaniu problemu.
Przy twardej awarii alert oparty na burn rate i zwykły alert „strona nie działa” uruchamiają się mniej więcej w tym samym momencie. Burn rate pokazuje swoją wartość przy częściowych awariach: 3% żądań kończy się błędem przez wiele godzin, strona nigdy nie pada, ale po cichu wyczerpuje miesięczny budżet już do środy.
Napisz politykę budżetu błędów
Budżet bez polityki to tylko liczba na dashboardzie. Polityka określa z góry, co zespół robi przy każdym poziomie zużycia. Uzgodnijcie ją wspólnie – produkt i inżynieria – i zapiszcie tam, gdzie obie strony ją znajdą. Google publikuje przykładową politykę budżetu błędów, którą warto przeczytać, zanim napiszesz własną.
Prosta polityka na początek
Budżet jest dostępny: wdrażacie jak zwykle. Zaplanowane ryzykowne prace idą zgodnie z planem.
Połowa zużyta przed połową okna: lider dyżurów przegląda dotychczasowe incydenty i wskazuje największą przyczynę.
Budżet wyczerpany: do czasu odnowienia okna wdrażane są tylko poprawki błędów i prace nad niezawodnością. Ryzykowne migracje czekają.
Pojedynczy incydent zużył ponad jedną piątą budżetu: dostaje pisemny postmortem z co najmniej jednym zadaniem do wykonania.
O wyjątkach decydują wskazane osoby, na przykład szef inżynierii i szef produktu wspólnie, a decyzja jest zapisywana.
Progi to przykłady, nie reguły. Wybierz takie, których Twój zespół naprawdę będzie przestrzegać. Polityka zignorowana przy pierwszej okazji, gdy zaczyna uwierać, jest gorsza niż jej brak, bo uczy wszystkich, że SLO nie ma znaczenia.
Typowe błędy
SLO równe SLA. Wtedy budżet kończy się w tej samej chwili, w której jesteś winien klientom rekompensaty (service credits). Ustaw SLO ostrzej niż SLA, żeby wewnętrzny alarm zadzwonił pierwszy. Jak te trzy pojęcia się łączą, wyjaśnia artykuł SLA, SLO i SLI.
Za krótkie okno. Tygodniowy budżet zeruje się, zanim zły tydzień zdąży cokolwiek zmienić. Zwykle wybiera się 30 dni – kroczące albo w miesiącu kalendarzowym.
Zapominanie, jak odnawia się okno. Miesiąc kalendarzowy zaczyna się od zera pierwszego dnia, więc o złym ostatnim tygodniu zapomina się po kilku dniach. Kroczące okno 30 dni pamięta go przez miesiąc – jest surowsze i bardziej sprawiedliwe.
Patrzenie tylko na sumę. Jedna 40-minutowa awaria i czterdzieści 1-minutowych zużywają ten sam budżet, ale te drugie codziennie przerywają pracę użytkowników. Obok budżetu śledź liczbę incydentów i MTTR.
Pomiar tylko od środka. Logi serwera nie zarejestrują żądań, które nigdy nie dotarły. Wygasły certyfikat czy zepsuty rekord DNS zużywają budżet, który widzi tylko sprawdzenie z zewnątrz.
Śledzenie budżetu błędów opartego na czasie w Uptimecheck
Uptimecheck dostarcza liczb, których potrzebuje budżet oparty na czasie. Monitorowanie dostępności sprawdza nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku i potwierdza każde nieudane sprawdzenie z drugiej lokalizacji, więc pojedyncze zakłócenie nie zużywa budżetu. Okna serwisowe i czas wstrzymania nie obniżają dostępności.
Raporty pokazują dostępność, przestoje i incydenty dla każdego monitora w bieżącym miesiącu, poprzednim miesiącu lub w ostatnich 7, 30 albo 90 dniach, względem celu SLA 99%, 99,5%, 99,9%, 99,95% lub 99,99%, z możliwością pobrania CSV. Pozostały budżet to dozwolony przestój minus przestój z raportu. Zobacz, jak tworzyć raporty względem celu SLA.
Incydenty przechowują dowody i oś czasu każdego sprawdzenia, alertu i notatki – dokładnie to, czego potrzebuje postmortem. Zobacz zarządzanie incydentami.
Okna serwisowe wyłączają planowane prace z wyników. Zobacz, jak planować okna serwisowe.
Aby wycenić zużywany budżet, skorzystaj z kalkulatora kosztów przestoju. Co oznacza każdy cel, przeczytasz w artykule co oznacza dostępność 99,9%.
Wiedz, ile budżetu Ci zostało, zanim skończy się miesiąc. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.