Czym jest budżet błędów i dlaczego jest on istotny?

Każdy zespół programistyczny, IT i zajmujący się eksploatacją wie, że incydenty czasem się zdarzają. 

Nawet największe firmy z najbardziej błyskotliwymi talentami i reputacją dostawcy zapewniającego dostępność na poziomie zbliżonym do 100% czasami obserwują z frustracją, jak ich systemy przestają działać. Wystarczy spojrzeć na takie firmy, jak Apple, Delta czy Facebook, które w ciągu ostatnich pięciu lat straciły dziesiątki milionów z powodu incydentów. 

Te realia oznaczają, że umowy o gwarantowanym poziomie świadczenia usług (SLA) nigdy nie powinny zawierać deklaracji dostępności na poziomie 100%. Byłoby to zobowiązanie, którego żadna firma nie jest w stanie dotrzymać. 

Oznacza to również, że jeśli Twojej firmie bardzo dobrze udaje się unikać incydentów lub je rozwiązywać, możesz konsekwentnie podnosić poprzeczkę, jeśli chodzi o zapewnianą dostępność. Być może zobowiązujesz się zapewnić dostępność na poziomie 99%, ale w rzeczywistości osiągasz wskaźnik bliższy 99,5%. A może deklarujesz dostępność na poziomie 99,5%, a w rzeczywistości w typowym miesiącu osiągasz poziom 99,99%.

W takich sytuacjach eksperci branżowi zalecają, aby zamiast nadmiernego zwiększania oczekiwań użytkowników przez ciągłe przekraczanie deklarowanych wartości, potraktować dodatkowe 0,99% jako budżet błędów, czyli czas, który Twój zespół może wykorzystać na podjęcie ryzyka.

Czym jest budżet błędów?

Budżet błędów jest to maksymalny czas, przez który system techniczny może się znajdować w stanie awarii bez ponoszenia przez dostawcę konsekwencji umownych. 

Jeśli na przykład w umowie o gwarantowanym poziomie świadczenia usług (SLA) zadeklaruje się, że systemy będą zachowywać sprawność przez 99,99% czasu, a w przypadku niedotrzymania tego zobowiązania klientom będzie przysługiwać zadośćuczynienie z tytułu awarii, oznacza to, że roczny budżet błędów (lub czas, przez który systemy mogą nie działać bez konsekwencji) wynosi 52 minuty i 35 sekund w skali roku.

W przypadku umowy SLA z gwarancją dostępności na poziomie 99,95% budżet błędów wynosi 4 godziny, 22 minuty i 48 sekund. A w przypadku umowy SLA z gwarancją dostępności na poziomie 99,9% — 8 godzin, 46 minut i 12 sekund.

Dlaczego zespoły technologiczne potrzebują budżetów błędów?

Na pierwszy rzut oka budżety błędów nie wydają się takie ważne. To tylko kolejny wskaźnik potrzebny zespołom IT i DevOps do monitorowania, czy wszystko przebiega sprawnie, prawda?

Na szczęście odpowiedź brzmi: nie. Budżety błędów nie są jedynie wygodnym sposobem dbania o dotrzymywanie zobowiązań umownych. Są one również dla zespołów programistycznych okazją do wdrażania innowacji i podejmowania ryzyka. 

Jak wyjaśniamy w naszym artykule na temat SRE: 

„Zespół programistyczny może wykorzystać ten budżet błędów w dowolny sposób. Jeśli produkt działa obecnie bez zarzutu, a liczba błędów jest niewielka lub nie ma ich wcale, mogą wdrożyć, co tylko zechcą i kiedy zechcą. I odwrotnie, jeśli wyczerpali lub przekroczyli budżet błędów i funkcjonują na granicy lub poniżej granicy zdefiniowanych wskaźników SLA, wszystkie wdrożenia zostają wstrzymane do czasu zmniejszenia liczby błędów do poziomu umożliwiającego dalsze wdrażanie”.

Zaletą tego podejścia jest fakt, że zachęca zespoły do minimalizowania rzeczywistych incydentów, a jednocześnie do maksymalizacji innowacji przez podejmowanie ryzyka w dopuszczalnych granicach. Stanowi również płaszczyznę porozumienia między zespołami programistycznymi, którym zależy na innowacyjności i zwinności, a zespołami operacyjnymi, które starają się zapewnić stabilność i bezpieczeństwo. Dopóki przestoje utrzymują się na niskim poziomie, programiści mogą pracować zwinnie i wypychać zmiany bez utrudnień ze strony zespołu ds. eksploatacji.

Jak wykorzystać budżet błędów?

Najpierw musisz przyjrzeć się swoim umowom SLA i poziomom SLO. Jakie wartości docelowe ustawiono już dla dostępności lub skutecznie zrealizowanych wniosków dotyczących systemu? Jakie zobowiązania firma podjęła wobec klientów? Na tej podstawie będzie można wyznaczyć budżet błędów.

Budżety błędów oparte na czasie dostępności

Większość zespołów monitoruje dostępność w okresach miesięcznych. Jeśli zespół uzyska wynik lepszy, niż przewidziano w parametrach SLA/SLO, może wydać nowe funkcje i podjąć ryzyko. Jeśli uzyskano niższy wskaźnik, wydania zostają wstrzymane do czasu przywrócenia odpowiedniego poziomu. 

Aby skutecznie korzystać z tej metody, musisz przełożyć swój docelowy poziom SLO (zazwyczaj wyrażony w procentach) na wartości liczbowe, które programiści będą mogli wykorzystać. To oznacza przeliczenie dopuszczalnego czasu przestoju wynoszącego 1%, 0,5% czy 0,1% na konkretną liczbę godzin i minut. Często stosowane wartości docelowe:

Budżety błędów oparte na liczbie skutecznie zrealizowanych wniosków

Poziomy SLO nie cieszą się aż tak złą sławą, jak umowy SLA, jednak mogą stwarzać równie wiele problemów, jeśli zostaną sformułowane w sposób niejasny, zbyt skomplikowany lub uniemożliwiający dokonanie pomiarów. Kluczem do ustalenia poziomów SLO, które nie będą przyprawiać inżynierów o zawrót głowy, są prostota i przejrzystość. Status poziomu SLO powinien być zarezerwowany dla najważniejszych wskaźników, cele powinny być sformułowane w sposób przejrzysty i, podobnie jak w przypadku umów SLA, zawsze powinny uwzględniać takie kwestie, jak zwłoka po stronie klienta.

Bądź na bieżąco z umowami SLA, aby zamykać wnioski w oparciu o priorytety, i korzystaj z automatycznych reguł przekierowywania, aby powiadamiać odpowiednich członków zespołu i zapobiegać naruszeniom umów SLA, dzięki Jira Service Management.