MTTR (mean time to recovery lub repair, średni czas przywrócenia lub naprawy) to średni czas od początku incydentu do chwili, gdy usługa znów działa. MTTA (mean time to acknowledge, średni czas potwierdzenia) to średni czas od alertu do momentu, gdy ktoś potwierdzi, że zajmuje się problemem. MTBF (mean time between failures, średni czas między awariami) to średni czas normalnej pracy usługi między incydentami. Razem opisują niezawodność: MTBF mówi, jak często coś się psuje, MTTA – jak szybko reagujesz, a MTTR – jak długo odczuwają to klienci.
Ten poradnik omawia definicje, wzory, przykład z liczbami, znaczniki czasu, które warto zbierać, oraz praktyczne zmiany poprawiające każdy wskaźnik.
Wskaźniki i co mierzą
MTTR: cztery znaczenia, jeden skrót
MTTR to najczęściej przywoływany wskaźnik incydentów i zarazem najbardziej mylący, bo litera R oznacza co innego w zależności od tego, kto go używa:
Mean time to repair (średni czas naprawy): od rozpoczęcia prac naprawczych do wdrożenia poprawki. Typowy dla sprzętu i utrzymania ruchu.
Mean time to recovery lub restore (średni czas przywrócenia): od początku awarii do chwili, gdy usługa znów działa dla użytkowników. Najbardziej przydatna wersja dla stron i API.
Mean time to respond (średni czas reakcji): od alertu do momentu, gdy zespół zaczyna działać. Bliski MTTA.
Mean time to resolve (średni czas rozwiązania): do pełnego zamknięcia incydentu, łącznie z działaniami, które zapobiegają jego powtórce.
Żadne z nich nie jest błędne. Ważne, żeby wybrać jedno, spisać definicję i stosować ją konsekwentnie. Porównanie Twojego czasu „przywrócenia” z czyimś czasem „naprawy” nic nie mówi. W tym artykule MTTR oznacza średni czas przywrócenia: od awarii usługi do chwili, gdy znów zadziałała.
MTTD i MTTA: reakcja przed naprawą
MTTD (mean time to detect, średni czas wykrycia) to czas od początku incydentu do chwili, gdy monitoring wyśle alert. MTTA to czas od tego alertu do jego potwierdzenia przez człowieka. Oba mieszczą się w MTTR i dlatego są tak ważne: nikt nie naprawi problemu, o którym nie wie.
MTBF: jak często coś się psuje
MTBF to średni czas działania między incydentami. Im wyższy, tym lepiej. Pokrewny MTTF (mean time to failure, średni czas do awarii) stosuje się do elementów, które się wymienia, a nie naprawia, np. dysków. Dla usług online potrzebujesz MTBF.
Wzory
MTTD = total time from incident start to alert / number of incidents
MTTA = total time from alert to acknowledgement / number of incidents
MTTR = total time from incident start to recovery / number of incidents
MTBF = total operating time without incidents / number of incidents
Availability = MTBF / (MTBF + MTTR)
Ostatnia linia pokazuje, dlaczego liczą się obie strony. Dostępność poprawisz, mając mniej incydentów (wyższy MTBF) albo skracając je (niższy MTTR). Skracanie jest często dużo tańsze.
Przykład z liczbami
Oto przykładowy miesiąc sklepu internetowego z czterema incydentami. Liczby są zmyślone na potrzeby przykładu, ale znaczniki czasu są takie, jakie daje każde narzędzie do monitoringu.
IncydentPoczątekAlertPotwierdzeniePrzywrócenieWykryciePotwierdzeniePrzywrócenieKoszyk zwraca 50303:1203:1303:1603:191 min3 min7 minPrzekroczenia czasu API10:0510:0610:0810:411 min2 min36 minBłędy logowania14:3014:3114:4515:021 min14 min32 minWyszukiwarka nie działa22:5022:5122:5623:151 min5 min25 min
Teraz zastosuj wzory:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minuta.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minut.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minut.
MTBF: 30-dniowy miesiąc ma 43 200 minut. Po odjęciu 100 minut przestoju zostaje 43 100. Po podzieleniu przez 4 incydenty MTBF wynosi 10 775 minut, czyli około 7,5 dnia.
Dostępność = 10 775 / (10 775 + 25) = 99,77%.
Rzucają się w oczy dwie rzeczy. 14-minutowe potwierdzenie przy incydencie z logowaniem podnosi MTTA z około 3 do 6 minut, więc warto zapytać, dlaczego nikt nie odebrał tego alertu. A przy 99,77% sklep jest daleko od celu 99,9%, który pozwala na zaledwie 43 minuty przestoju w miesiącu. Jeśli wyznaczasz takie cele, przeczytaj SLA, SLO i SLI, żeby zobaczyć, jak do siebie pasują.
Wyobraź sobie teraz ten sam miesiąc z testami co pięć minut i bez etapu potwierdzenia. Wykrycie mogłoby trwać do pięciu minut zamiast jednej, co dokłada nawet cztery minuty do każdego incydentu. MTTR rośnie z 25 do nawet 29 minut, zanim ktokolwiek zrobi cokolwiek inaczej.
Jakie znaczniki czasu zbierać
Na każdy incydent potrzebujesz czterech znaczników czasu. Większość pochodzi wprost z monitoringu:
Początek: pierwszy nieudany test. Zewnętrzny monitoring zapisze go nawet wtedy, gdy Twoje serwery niczego nie zalogują.
Alert: moment potwierdzenia awarii i wysłania powiadomienia.
Potwierdzenie: chwila, w której ktoś napisał „zajmuję się tym”. Jeśli nie masz narzędzia do dyżurów, wystarczy odpowiedź na kanale incydentowym – zanotuj godzinę. W Uptimecheck potwierdzasz incydent w aplikacji albo, z aplikacją Slack, przyciskiem w Slacku, a czas zapisuje się automatycznie.
Przywrócenie: pierwszy udany test po incydencie, czyli zarazem moment wysłania powiadomienia o przywróceniu.
W Uptimecheck każdy incydent ma oś czasu: kiedy się zaczął, kto i kiedy dostał alert, potwierdzenia (także przyciskiem w Slacku, gdy używasz aplikacji Slack), notatki i przywrócenie. MTTA i MTTR liczą się same, a eksport raportu do CSV podaje dla każdego monitora liczbę incydentów, czas przestoju i najdłuższy incydent – gotowe do arkusza kalkulacyjnego. Wnioski zapisz w postmortemie.
Praktyczna przestroga: średnie ukrywają wartości odstające. Jeden sześciogodzinny incydent i dziewięć jednominutowych przerw dają średnio około 37 minut, co nie opisuje żadnego z nich. Patrz na medianę i najdłuższy incydent obok średniej, a najwolniejsze incydenty analizuj po kolei.
Jak skrócić czas wykrycia
Sprawdzaj co minutę
Interwał testów to górna granica czasu wykrycia. Testy co minutę dla wszystkiego, co zarabia albo obsługuje klientów, to najtańsza pojedyncza poprawa MTTR. Używaj 1-minutowego monitorowania dostępności dla każdej krytycznej strony i endpointu.
Sprawdzaj, co się psuje, a nie tylko, co się ładuje
Incydenty, których monitoring nie widzi, wykrywają klienci, często po wielu godzinach. Weryfikuj treść ważnych stron, monitoruj endpointy API, z których korzystają aplikacje, i dodaj heartbeaty do zaplanowanych zadań. Każdy incydent, który pierwszy zgłosił klient, to luka w monitoringu.
Jak skrócić czas potwierdzenia
Wysyłaj tylko potwierdzone alerty
Powolne potwierdzanie to zwykle problem zaufania. Jeśli połowa alertów jest fałszywa, ludzie uczą się czekać i patrzeć. Potwierdzaj każdą awarię drugim testem przed wysłaniem alertu i usuń monitory, które alarmują, choć nikt nie musi nic robić. Szczegóły znajdziesz w poradniku o ograniczaniu fałszywych alertów.
Kieruj alerty do właściwego kanału
E-mail o 03:12 zostanie przeczytany o 07:30. Krytyczne monitory kieruj do kanału, który dociera na telefon osoby dyżurnej, i na czat zespołu dla pozostałych, a mniej pilne zostaw na e-mailu. Uptimecheck pozwala wybrać kanały alertów dla każdego monitora: e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooki i powiadomienia push na telefonie, w każdym planie. Eskalacja może wstrzymać kanał na 5 do 60 minut i wysłać alert tylko wtedy, gdy awaria wciąż trwa, a nikt jej nie potwierdził.
Jasno określ odpowiedzialność
Alert wysłany do pięciu osób często nie zostaje potwierdzony przez nikogo. Wyznacz jednego właściciela każdej usługi i jedną osobę dyżurną na zmianę. Pozostali dostają informację, a nie odpowiedzialność. Dzięki grafikom dyżurów w Uptimecheck ludzie zmieniają się na dyżurach, z zastępstwami na wypadek choroby czy zamiany, a alerty push trafiają do osoby, która ma dyżur w danej chwili.
Jak skrócić czas naprawy
Spisz runbooki dla znanych awarii
Większość incydentów się powtarza. Zapełnia się dysk, wyczerpuje się pula workerów, nie udaje się odnowić certyfikatu. Krótki runbook dla każdego monitora zamienia zaspane śledztwo w listę kontrolną:
Runbook: checkout returns 503
1. Check the server dashboard: CPU, memory, disk on web-01 and web-02.
2. Check PHP-FPM status: sudo systemctl status php8.3-fpm
3. If workers are exhausted: sudo systemctl restart php8.3-fpm
4. Check for long-running jobs: ps aux –sort=-%cpu | head
5. Still failing after 10 minutes? Escalate to the lead developer.
Trzymaj link do runbooka tam, gdzie trafia alert, np. przypięty na kanale incydentowym, żeby był na jedno stuknięcie.
Zestaw przyczynę z objawem
Gdy test strony zawodzi, pierwsze pytanie zwykle brzmi: czy serwerowi zabrakło pamięci, CPU albo miejsca na dysku? Metryki serwera obok testów dostępności skracają ten krok z sesji SSH do jednego spojrzenia.
Niech wycofanie zmian będzie proste
Wiele incydentów zaczyna się od wdrożenia. Jeśli wycofanie to jedno polecenie, przywrócenie zajmuje minuty. Jeśli wymaga spotkania, zajmuje godzinę.
Aktualizuj stronę statusu od razu
Strona statusu nie skraca samej awarii, ale skraca to, co klienci odczuwają najgorzej: niewiedzę. Chroni też support przed zalewem zgłoszeń, gdy zespół usuwa problem. Strona statusu połączona z monitorami pokazuje dotknięty komponent, gdy tylko incydent się otworzy. Dodaj krótką notkę o tym, co robisz i kiedy podasz kolejną aktualizację.
Jak poprawić MTBF
Mniej incydentów bierze się z wyciągania wniosków z tych, które już były. Po każdym poważnym incydencie napisz postmortem bez szukania winnych, ustal jedno lub dwa działania i pilnuj ich do skutku. Po kilku miesiącach te same awarie przestają wracać, a MTBF rośnie.
Zacznij mierzyć na prawdziwych znacznikach czasu. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.