Error budget (SRE)
Przelicz SLO dostępności na budżet błędów: ile minut niedostępności wolno „wydać” w roku lub w wybranym okresie — i ile zostało przed decyzją o freeze wdrożeń.
Wynik
Wprowadź dane i kliknij Oblicz.
Co to jest error budget
Error budget (budżet błędów) to koncepcja z "Site Reliability Engineering" (książka Google) — to dopuszczalna ilość niedostępności wynikająca z ustalonego SLO. Jeśli SLO to 99,9% dostępności, budżet błędów to pozostałe 0,1% czasu, w którym system może być niedostępny bez naruszenia obietnicy danej użytkownikom.
Wzór
Budżet = łączna liczba minut w okresie × (100 − SLO%) / 100. Dla roku (525 600 minut) to 525600 × (100 − SLO) / 100. Kalkulator liczy to samodzielnie dla roku, a jeśli podasz dowolny okres w dniach — również dla niego, oraz odejmuje wykorzystany downtime, jeśli go podasz.
SLO i dopuszczalny downtime
| SLO | Downtime / rok | Downtime / miesiąc (30 dni) |
|---|---|---|
| 99% | ~3,65 dnia | ~7,2 godziny |
| 99,9% | ~8,76 godziny | ~43,2 minuty |
| 99,95% | ~4,38 godziny | ~21,6 minuty |
| 99,99% | ~52,6 minuty | ~4,32 minuty |
| 99,999% | ~5,26 minuty | ~0,43 minuty |
MTTR i MTBF pomagają interpretować te minuty downtime przez rytm i czas napraw — zobacz kalkulator MTTR i MTBF.
Jak zespoły "wydają" budżet błędów
- Budżet błędów to nie tylko liczba do raportowania — to sygnał, ile ryzyka można podjąć. Zespół z dużym pozostałym budżetem może wdrażać szybciej i eksperymentować, np. testować nowe funkcje na produkcji.
- Gdy budżet się kończy, standardowa praktyka SRE to "freeze" wdrożeń nowych funkcji i skierowanie wysiłku na stabilność, dopóki budżet się nie odbuduje w kolejnym oknie.
- To narzędzie do rozmowy między zespołami produktowymi (chcą szybciej wdrażać) i operacyjnymi (chcą stabilności) — konkretna liczba minut zamiast subiektywnej dyskusji "czy jest wystarczająco stabilnie".
Okno rolling vs kalendarzowe
Budżet można liczyć w oknie kalendarzowym (miesiąc, kwartał) albo w oknie przesuwnym (rolling window, np. ostatnie 30 dni licząc od dziś). Okno przesuwne lepiej odzwierciedla aktualny stan usługi — nie "resetuje się" sztucznie pierwszego dnia miesiąca — ale wymaga trochę bardziej złożonego monitoringu. Ten kalkulator liczy budżet dla podanej liczby dni; wybór, czy to okno kalendarzowe czy przesuwne, zależy od tego, jak mierzysz wykorzystany downtime.
Przykłady
- SLO 99,9% → roczny budżet ok. 525,6 minuty (~8,76 godziny) dozwolonej niedostępności.
- SLO 99,9%, okres 30 dni, wykorzystane 10 minut → budżet okresu ok. 43,2 minuty, pozostało ok. 33,2 minuty.
- SLO 99,99%, okres 30 dni → budżet okresu ok. 4,32 minuty — bardzo mała tolerancja na niedostępność.
FAQ — error budget
- Czym różni się error budget od SLA?
- SLA (Service Level Agreement) to zewnętrzna, często kontraktowa obietnica z konsekwencjami finansowymi. Error budget to wewnętrzne narzędzie operacyjne oparte na SLO, używane do podejmowania decyzji o tempie wdrożeń.
- Co się dzieje, gdy budżet błędów się skończy?
- Typowa praktyka to tymczasowe wstrzymanie wdrożeń nowych funkcji i skierowanie zasobów na poprawę stabilności, aż budżet odbuduje się w kolejnym okresie.
- Czy budżet liczy się dla jednego SLI, czy dla wielu naraz?
- Zwykle dla jednego kluczowego wskaźnika (np. dostępność HTTP 200) na raz. Systemy z wieloma SLO (dostępność, latencja, poprawność danych) zwykle śledzą osobne budżety dla każdego.
- Czy SLO 100% jest realistyczne?
- Praktycznie nigdy — 100% oznacza zerowy budżet błędów, co eliminuje możliwość jakichkolwiek wdrożeń, konserwacji czy nawet drobnych przestojów sieciowych. Google SRE rekomenduje SLO niższe niż to, co technicznie możliwe.
- Jak w praktyce mierzy się "wykorzystany downtime"?
- Najczęściej z systemu monitoringu (uptime checks, error rate w metrykach) albo z rejestru incydentów — czas trwania każdego incydentu wpływającego na SLI sumuje się w danym okresie.
- Czy krótkie SLO (np. tygodniowe) mają sens?
- Tak — krótsze okna dają szybszą informację zwrotną, ale są bardziej "nerwowe" (jeden incydent może wyczerpać cały budżet). Dłuższe okna (kwartał) są stabilniejsze, ale wolniej sygnalizują problem.
- Kto wymyślił koncepcję error budget?
- Pochodzi z książki "Site Reliability Engineering" wydanej przez Google w 2016 r., opisującej praktyki zespołu SRE Google.
- Czy budżet błędów zastępuje monitoring i alerting?
- Nie — to metryka decyzyjna (np. wstrzymaj ryzykowne deploys przy wyczerpanym budżecie), nie zamiennik monitoringu. Alerty nadal wykrywają incydenty w czasie rzeczywistym.