Kalkulator MTTR i MTBF

Wpisz sumę napraw, liczbę awarii i opcjonalne MTBF. 10 i 5 dają 2.00 h. 4 i 2 dają 2.00 h. 1,5 i 3 dają 0.50 h. Wpisane czasy, nie CMDB.

To średnia ze wpisanych godzin naprawy. Nie raport ITIL i nie live CMDB. Budżet SLO jest na error budget (SRE).

Dane

Opcje dodatkowe (opcjonalnie)

W tym kalkulatorze MTBF jest wartością wejściową (średni czas między awariami), a nie automatycznie wyliczaną z sztywnego okna kalendarzowego.

Wynik

Wprowadź dane i kliknij Oblicz.

Jak to działa?

Kalkulator MTTR i MTBF w tym kalkulatorze dzieli wpisane godziny przez liczbę awarii. 10 h i 5 dają 2.00 h. 4 h i 2 dają 2.00 h. 1,5 h i 3 dają 0.50 h. MTTR = suma napraw / awarie. MTBF jest wpisem, nie wynikiem z kalendarza. To nie raport CMDB.

Pole mttr-repair jest sumą godzin naprawy. Pole mttr-failures jest liczbą. Pole mtbf-hours w przykładach to 500, 720 albo 200, ale wynik zostaje MTTR. 10 / 5 = 2. 4 / 2 = 2. 1,5 / 3 = 0,5.

2.00 h nie schodzi z Jiry. 0.50 h nie jest oknem z PagerDuty. Wpisujesz czasy sam. Kalkulator nie czyta incydentów i nie zna ITIL.

Error budget obok liczy minuty z SLO. Uptime liczy dopuszczalny downtime. Tu 10 i 5 zostają 2.00 h, średnia ze wpisanych czasów.

Wpisz 10 i 5, potem Oblicz. Wynik MTTR to 2.00 h. Przecinek w 1,5 działa. Zero awarii nie dzieli. To nie CMDB.

10 i 5 dają 2.00 h. 4 i 2 dają 2.00 h. 1,5 i 3 dają 0.50 h. Inna suma przy 5 zmienia 2.00 h.

Wzór

MTTR = suma godzin naprawy / liczba awarii. MTBF jest wpisane. Wpisane czasy, nie CMDB.

Jak korzystać

  1. Wpisz sumę napraw 10 i 5 awarii.
  2. Kliknij Oblicz. MTTR to 2.00 h.
  3. 4 i 2 dają 2.00 h. 1,5 i 3 dają 0.50 h.
  4. To wpisane czasy, nie raport CMDB.
  5. Minuty z SLO licz na error budget (SRE).

10 h i 5 awarii = 2.00 h

MTTR = suma napraw / awarie. 10 i 5 dają 2.00 h. Wpisane czasy, nie CMDB.

MTTR
Suma godzin przez awarie. 10 i 5 zostawiają 2.00 h. Nie Jira.
MTBF
Wpis w mtbf-hours. 500, 720 albo 200. Nie wynik z kalendarza.
naprawy
Pole mttr-repair. 1,5 i 3 dają 0.50 h. Wpisane czasy.

Przykłady

Przykład 1

  • 10 h naprawy
  • 5 awarii
  • MTBF 500

2.00 h

Jaki MTTR przy 10 h i 5 awariach? 2.00 h. Wpisane czasy, nie CMDB.

Przykład 2

  • 4 h naprawy
  • 2 awarie
  • MTBF 720

2.00 h

Jaki MTTR przy 4 h i 2 awariach? 2.00 h.

Przykład 3

  • 1,5 h naprawy
  • 3 awarie
  • MTBF 200

0.50 h

Jaki MTTR przy 1,5 h i 3 awariach? 0.50 h.

Powiązane kalkulatory

Error budget (SRE)

Error budget (SRE): SLO, dni okresu i zużyte minuty.

Użyj kalkulatora →

Uptime i dopuszczalny downtime

Uptime i dopuszczalny downtime: procent.

Użyj kalkulatora →

Limity API (rate limit)

Kalkulator limitów API (rate limit): limit, jednostkę i okno.

Użyj kalkulatora →

Koszt na request

Koszt na request: cenę za milion i liczbę requestów.

Użyj kalkulatora →

Konwerter stref czasowych

Konwerter stref czasowych: datę, godzinę i strefy.

Użyj kalkulatora →

Wszystkie kalkulatory IT

Najczęstsze pytania

Jaki MTTR przy 10 h i 5 awariach?

2.00 h. 10 / 5. Wpisane czasy, nie CMDB.

Ile przy 4 h i 2 awariach?

2.00 h. 4 / 2.

Ile przy 1,5 h i 3 awariach?

0.50 h. 1,5 / 3.

Czy to raport CMDB albo ITIL?

Nie. Kalkulator dzieli dwie wpisane liczby. Nie czyta incydentów.

Czy MTBF jest liczone?

Nie. Pole mtbf-hours jest wpisem. Wynik zostaje MTTR.

Czy przecinek w 1,5 działa?

Tak. 1,5 i 3 dają 0.50 h.

Co przy zerze awarii?

Nie ma MTTR, bo nie dzielimy przez zero.

Gdzie liczysz error budget?

Na error budget (SRE). Tu zostaje 2.00 h z 10 i 5.

Czy 2.00 h to SLO?

Nie. To średnia napraw. SLO jest na sąsiedniej karcie.

Źródła wiedzy

Kalkulator liczy bity, bajty albo przepustowość z Twoich liczb. Poniżej definicje bitu i SI (GUM).

Strona zaktualizowana w 2026.

MTTR, MTBF, MTTA i MTTD

MTTR (Mean Time To Repair) to średni czas potrzebny na przywrócenie usługi po awarii. MTBF (Mean Time Between Failures) to średni czas działania między awariami — tu podajesz go jako wejście (np. z historii lub szacunku), a nie wynik z automatycznego okna kalendarzowego. W praktyce SRE często rozbija się też incydent na MTTD (czas do wykrycia) i MTTA (czas do reakcji) — MTTR liczony przez ten kalkulator obejmuje cały czas naprawy, niezależnie od tego, jak go zmierzono.

Wzory

MTTR = suma czasów naprawy ÷ liczba awarii. Gdy podasz MTBF, kalkulator liczy też szacowaną dostępność: Dostępność = MTBF ÷ (MTBF + MTTR) — to standardowy model dostępności stacjonarnej (steady-state availability) używany w analizie niezawodności.

Cele dostępności a rytm awarii

Szacowana dostępność z MTBF/(MTBF+MTTR) warto zestawić z typowymi „dziewiątkami”. Skrócona tabela poniżej — pełniejszy rozkład downtime pod SLO znajdziesz w kalkulatorze Error budget.

Cel dostępnościDowntime / rok (orientacyjnie)
99%~3,65 dnia
99,9%~8,76 godziny
99,99%~52,6 minuty

Jak skracać MTTR

  • Runbooki i automatyzacja typowych działań naprawczych (restart, rollback, failover) skracają czas naprawy bardziej niż samo szybsze wykrywanie.
  • Dobre dashboardy i alerty z konkretnym kontekstem (nie tylko "coś jest nie tak") skracają czas diagnozy — największą część MTTR często pochłania właśnie zrozumienie, co się zepsuło.
  • Post-mortemy bez obwiniania (blameless) i śledzenie akcji naprawczych zapobiegają powtarzającym się długim naprawom tego samego problemu.

MTTR vs MTBF — co poprawiać najpierw

Dostępność zależy od obu wartości, ale ich poprawa ma różny koszt. Wydłużenie MTBF (rzadsze awarie) często wymaga zmian architektonicznych (redundancja, lepsze testy) i jest kosztowne. Skrócenie MTTR (szybsza naprawa) zwykle jest tańsze i szybsze do wdrożenia — dlatego wiele zespołów SRE inwestuje najpierw w automatyzację reakcji na incydenty, a dopiero potem w fundamentalną niezawodność.

Przykłady

  • 10 godzin łącznego czasu naprawy przy 5 awariach → MTTR = 2 godziny.
  • MTTR = 2h, MTBF = 100h → dostępność ≈ 98,04%.
  • Ten sam MTBF = 100h, ale MTTR skrócone do 0,5h → dostępność ≈ 99,50% — widać, jak duży wpływ ma skrócenie samego czasu naprawy.