MTTR

MTTR (Mean Time To Repair/Recover/Restore) - popularny wskaźnik niezawodności i utrzymania usług, używany w IT, DevOps, administracji systemami, produkcji oraz serwisie technicznym. MTTR opisuje średni czas potrzebny na przywrócenie sprawności po awarii lub incydencie - od momentu wykrycia problemu do pełnego odzyskania działania. W zależności od kontekstu MTTR bywa interpretowany jako "Mean Time To Repair" (średni czas naprawy), "Mean Time To Recover" (średni czas odzyskania) albo "Mean Time To Restore" (średni czas przywrócenia). Celem pracy z MTTR jest skracanie przestojów, poprawa jakości obsługi incydentów oraz wzrost dostępności usług.

Definicja i znaczenie MTTR

MTTR to miara pokazująca, jak szybko organizacja potrafi wrócić do normalnego działania po awarii. W praktyce odpowiada na pytanie: "Ile średnio zajmuje nam opanowanie incydentu i przywrócenie usługi do stanu użytecznego dla użytkowników?". Im niższy MTTR, tym krótszy jest czas niedostępności, mniejsze straty biznesowe i większe zaufanie klientów.

Wskaźnik MTTR ma znaczenie szczególnie tam, gdzie przestoje są kosztowne lub ryzykowne, np. w systemach e-commerce, bankowości, usługach online, produkcji, telekomunikacji czy infrastrukturze krytycznej. MTTR bywa też jednym z kluczowych KPI dla zespołów utrzymania, SRE (Site Reliability Engineering) oraz działów serwisowych.

Co dokładnie mierzy MTTR?

Najczęściej MTTR liczy się jako średnią arytmetyczną czasu od "startu incydentu" do "przywrócenia działania". Problem w tym, że organizacje różnie definiują te punkty, dlatego w praktyce warto jawnie ustalić, co wchodzi w skład MTTR.

Najczęstsze interpretacje MTTR

Mean Time To Repair (średni czas naprawy) - koncentruje się na technicznej naprawie komponentu. Często używane w serwisie i inżynierii sprzętowej.
Mean Time To Recover (średni czas odzyskania) - akcentuje przywrócenie usługi dla użytkownika, nawet jeśli docelowa naprawa nastąpi później (np. rollback, failover).
Mean Time To Restore (średni czas przywrócenia) - zwykle oznacza moment, w którym usługa wraca do poziomu akceptowalnego (np. spełnia SLO), a incydent jest opanowany.

Wskazówka: w artykułach i raportach MTTR często występuje bez doprecyzowania znaczenia. Dobra praktyka to dopisanie wprost, co rozumiesz przez MTTR i jakie zdarzenia wchodzą do obliczeń.

Jak oblicza się MTTR?

Klasyczny wzór jest prosty:

MTTR = (suma czasów przywrócenia dla wszystkich incydentów) / (liczba incydentów)

Przykład: jeśli w miesiącu były 4 incydenty, a czasy ich przywrócenia wyniosły 20, 35, 15 i 50 minut, to MTTR = (20 + 35 + 15 + 50) / 4 = 30 minut.

Co wliczać do czasu incydentu

Żeby MTTR był porównywalny, warto ustalić definicje:

Start - wykrycie incydentu (alert) albo faktyczny początek degradacji (jeśli znamy go z metryk).
Koniec - przywrócenie usługi do działania (np. potwierdzone metrykami), zakończenie wpływu na użytkownika, spełnienie SLO.
Wliczane elementy - diagnoza, eskalacja, komunikacja, wdrożenie fixu/rollbacku, walidacja po naprawie.

Uwaga: jeśli liczymy czas od wykrycia, to MTTR jest też pochodną jakości monitoringu. Słabe alertowanie może sztucznie "poprawić" MTTR (bo incydent wykrywamy później), ale biznesowo sytuacja jest gorsza.

MTTR a inne wskaźniki: MTBF, MTTF, dostępność

MTBF (Mean Time Between Failures) - średni czas między awariami. Mówi, jak często coś się psuje.
MTTF (Mean Time To Failure) - średni czas do awarii (często dla elementów nienaprawialnych lub jako miara niezawodności).
Dostępność (availability) - uproszczony związek często opisuje wzór: availability ≈ MTBF / (MTBF + MTTR).

W praktyce: nawet jeśli awarie zdarzają się rzadko (wysoki MTBF), to bardzo długi MTTR potrafi mocno obniżyć dostępność usługi. Z kolei częste, ale szybko opanowywane incydenty mogą mieć mniejszy wpływ na biznes niż rzadkie, lecz wielogodzinne awarie.

Dlaczego MTTR bywa mylący?

MTTR jest prosty, ale potrafi wprowadzać w błąd, jeśli patrzy się na samą średnią:

Średnia ukrywa ogon - kilka bardzo długich incydentów może nie być widoczne, jeśli większość jest krótka (albo odwrotnie).
Różne wagi incydentów - 5 minut niedostępności w krytycznym systemie może być bardziej bolesne niż 2 godziny w systemie wewnętrznym.
Zmiany definicji - jeśli raz liczysz od alertu, a innym razem od zgłoszenia użytkownika, wyniki nie są porównywalne.
Sezonowość - okresy wdrożeń, szczyty ruchu i zmiany organizacyjne mogą wpływać na MTTR.

Dobra praktyka: raportuj MTTR razem z medianą, percentylami (np. P90) oraz liczbą incydentów. To daje pełniejszy obraz niż sama średnia.

Przykład obliczenia MTTR i interpretacja

Incydent 1: 12 minut - szybki rollback po błędnym wdrożeniu.
Incydent 2: 25 minut - restart usługi i korekta konfiguracji.
Incydent 3: 90 minut - problem z bazą danych, konieczna interwencja kilku zespołów.

MTTR = (12 + 25 + 90) / 3 = 42,33 minuty. Sama wartość 42 minuty nie mówi jednak, że większość incydentów jest krótsza, a jeden był bardzo długi. Wnioski będą inne, jeśli skupisz się na typowych incydentach (12-25 min) i osobno przeanalizujesz przyczyny "długiego ogona" (90 min).

Co wpływa na MTTR?

Monitoring i alertowanie - szybkie wykrycie i dobre sygnały diagnostyczne skracają czas reakcji.
On-call i eskalacje - jasne dyżury, progi eskalacji i odpowiedzialności ograniczają opóźnienia.
Runbooki i procedury - gotowe instrukcje postępowania minimalizują chaos podczas awarii.
Automatyzacja - automatyczne rollbacki, restart, failover, skrypty naprawcze.
Observability - logi, metryki i trace'y ułatwiają diagnozę przyczyn.
Architektura systemu - redundancja, podział na komponenty, odporność na awarie.
Proces wdrożeń - testy, canary releases, feature flags zmniejszają skalę i czas incydentów.
Kompetencje i współpraca - doświadczenie zespołu i sprawna komunikacja skracają czas działań.

Jak realnie obniżać MTTR?

Obniżanie MTTR nie polega wyłącznie na "szybszym gaszeniu pożarów". Najlepsze efekty daje połączenie praktyk operacyjnych, narzędzi oraz pracy nad przyczynami źródłowymi.

Ustal definicję MTTR i standardy pomiaru - aby mieć porównywalność w czasie.
Popraw detekcję - alerty oparte o SLO, wykrywanie degradacji zanim zauważy ją klient.
Skróć time-to-triage - jasne role, pierwszy kontakt, checklisty.
Stosuj bezpieczne mechanizmy przywracania - rollback, failover, replikacja, backupy z testami odtwarzania.
Wzmacniaj runbooki - po każdym incydencie uzupełnij instrukcje o to, czego brakowało.
Ćwicz scenariusze - symulacje awarii (np. chaos engineering w odpowiedniej skali) uczą reakcji.
Rób postmortemy bez obwiniania - analiza przyczyn i konkretne działania korygujące zmniejszają czas kolejnych incydentów.
Ograniczaj złożoność - im prostsze zależności i lepsza dokumentacja, tym szybciej diagnozujesz problem.

MTTR w praktyce biznesowej: SLO, SLA i priorytety

MTTR często łączy się z podejściem opartym o SLO (Service Level Objective) i SLA (Service Level Agreement). Wysoki priorytet incydentu (np. P1) może wymagać natychmiastowego przywrócenia działania - nawet kosztem tymczasowego obejścia problemu. W takim podejściu "Recover/Restore" ma większe znaczenie niż idealna naprawa od razu.

Wskazówka: warto mierzyć osobno czas "do przywrócenia usługi" oraz czas "do pełnej naprawy przyczyny". To pozwala nie mieszać szybkich obejść z długoterminową stabilizacją.

MTTR to jeden z najbardziej praktycznych wskaźników operacyjnych: łączy perspektywę techniczną (sprawność naprawy) z biznesową (czas niedostępności). Dobrze zdefiniowany i raportowany wraz z dodatkowymi miarami (np. medianą i percentylami) pomaga realnie poprawiać niezawodność. Największą wartość daje wtedy, gdy prowadzi do konkretnych usprawnień: lepszego monitoringu, automatyzacji, runbooków i konsekwentnej analizy incydentów.