Jak obliczyć uptime
Wzór na uptime to (Czas całkowity - Czas przestoju) / Czas całkowity x 100 = Uptime%. Strona z 43 minutami przestoju w 30-dniowym miesiącu (łącznie 43 200 minut) ma uptime na poziomie 99,9%. Sama arytmetyka jest prosta. Trudność polega na tym, żeby wiedzieć, ile minut kosztuje Cię każdy punkt procentowy, i mierzyć przestój na tyle dokładnie, żeby ten wzór cokolwiek znaczył.
Wzór na uptime
Dla serwera lub zasobu o znanym całkowitym czasie działania:
(Overall Lifetime - Overall Downtime) / Overall Lifetime x 100% = UptimeDla strony, którą aktywnie monitorujesz - a to znacznie częstszy przypadek, bo rzadko znasz rzeczywisty czas życia zasobu - uptime liczysz względem okresu monitoringu:
(Monitored Time - Monitored Downtime) / Monitored Time x 100% = UptimeWybierz okno czasowe (dzień, miesiąc, rok), zsumuj każdą minutę, w której strona była potwierdzona jako niedostępna w tym oknie, i podziel. Wynik jest tylko tak dokładny, jak Twoje śledzenie przestojów - i to jest właściwy argument za automatycznym monitoringiem zamiast ręcznego szacowania w stylu "czy ktoś zauważył awarię".
Jak obliczyć czas przestoju
Przestój to każdy ciągły odcinek czasu, w którym strona była niedostępna z zewnątrz, liczony z dokładnością do sekundy tam, gdzie to możliwe, a nie zaokrąglany do wygodnej liczby. Krótkie awarie się sumują: pięć dwuminutowych przerw w miesiącu to 10 minut przestoju, i łatwo to niedoszacować, jeśli opierasz się na zgłoszeniach użytkowników zamiast monitora, który loguje każdą zmianę stanu ze znacznikiem czasu.
Dziewiątki: co oznacza każdy poziom uptime
Uptime 99,9% i 99,999% brzmią podobnie. W praktyce dzieli je przepaść. Oto, ile przestoju pozwala każdy poziom, zanim przekroczysz cel, w skali roku i doby:
| Dostępność | Maks. roczny przestój | Maks. dobowy przestój | Praktyczne znaczenie |
|---|---|---|---|
| 99,9% ("trzy dziewiątki") | ~8,77 godziny | ~86,4 sekundy | Poziom, który większość wyszukiwarek i platform reklamowych uznaje za akceptowalny. Wystarcza dla większości stron, ale to nie jest poważne zobowiązanie SLA. |
| 99,95% | ~4,38 godziny | ~43,2 sekundy | Typowy SLA dla usług SaaS średniej klasy i rozsądny cel komercyjny. |
| 99,99% ("cztery dziewiątki") | ~52,6 minuty | ~8,64 sekundy | Przez większość platform traktowane jako praktycznie zawsze dostępne. Realistyczny sufit dla dobrze prowadzonej, aktywnie monitorowanej strony. |
| 99,999% ("pięć dziewiątek") | ~5,26 minuty | ~0,864 sekundy | Standard klasy telekomunikacyjnej. Osiągalny przy redundantnej infrastrukturze i niemal bezbłędnej dyscyplinie utrzymania, ale dla większości firm to zbyt duży nakład inżynieryjny, żeby się opłacał. |
100% uptime nie jest realistycznym celem dla nikogo: okna serwisowe, restarty i sporadyczne awarie u dostawców sprawiają, że jest strukturalnie nieosiągalny w dłuższym okresie. Cztery dziewiątki to praktyczny sufit, do którego powinna dążyć większość zespołów. Pięć dziewiątek to świadome i kosztowne zobowiązanie inżynieryjne, a nie domyślny cel.
Najczęstsze wzory na uptime w jednym miejscu
- Dostępność w chmurze/SLA: (Gwarantowany Uptime - Przestój) / Gwarantowany Uptime - wzór, na którym oparta jest większość SLA dostawców chmury.
- MTBF (średni czas między awariami): Całkowity czas działania / Liczba awarii - mówi, jak często zdarzają się incydenty, niezależnie od tego, jak długo trwa każdy z nich.
- Roczny budżet przestoju przy pięciu dziewiątkach: 86 400 sekund/dzień x 365 x 0,00001, czyli około 315 sekund, czyli 5,25 minuty rocznie.
- Roczny budżet przestoju przy trzech dziewiątkach: 1 440 minut/dzień x 365 x 0,001, czyli około 526 minut, czyli 8,77 godziny rocznie.
Jak osiągnąć wyższy wskaźnik uptime
Wzór pokazuje, gdzie stoisz. Oto dźwignie, którymi możesz poruszyć tę liczbę:
- Wybieraj hosting z realną historią działania i sam sprawdzaj deklarowany uptime dostawcy, zamiast wierzyć stronie marketingowej na słowo.
- Monitoruj nieprzerwanie spoza własnej infrastruktury. Monitor działający z kilku niezależnych lokalizacji wykrywa awarie, których Twoje własne logowanie po stronie serwera strukturalnie nie widzi, bo serwer, który nie może połączyć się ze światem zewnętrznym, nie potrafi zalogować, że jest nieosiągalny.
- Skracaj okna serwisowe. Każda sekunda zaplanowanego restartu liczy się do przestoju tak samo jak nieplanowany, więc grupuj i automatyzuj te prace.
- Utrzymuj redundantną infrastrukturę. Zapasowy serwer albo drugi region pozwala przenieść ruch na czas konserwacji lub częściowej awarii, zamiast wyłączać całą stronę.
Mierzenie zamiast szacowania
Cała powyższa matematyka jest tylko tak dobra, jak dane o przestojach, które ją zasilają - dlatego ręczne szacowanie ("chyba mieliśmy jedno gorsze popołudnie w zeszłym miesiącu") rzadko przetrwa konfrontację z prawdziwym raportem uptime. Monitoring uptime HostTracker sprawdza stronę z ponad 300 punktów kontrolnych w 158 miastach z ustawionym przez Ciebie interwałem, loguje każdą zmianę stanu z dokładnością do sekundy i wylicza procent uptime bez arkusza kalkulacyjnego. Przewodnik po sprawdzeniu HTTP opisuje kontrolę, która generuje większość tych zmian stanu, a reszta sekcji o pojęciach monitoringu obejmuje terminy związane z tym tematem.
FAQ
Jaki wzór określa procent dostępności u dostawcy chmury? (Gwarantowany Uptime - Przestój) / Gwarantowany Uptime, wyrażony w procentach. To standardowy wzór SLA w chmurze.
Co mierzy średni czas między awariami? MTBF (Mean Time Between Failures) = Całkowity czas działania / Liczba awarii.
Ile przestoju rocznie dopuszcza dostępność pięciu dziewiątek? Mniej niż 6 minut: 86 400 sekund/dzień x 365 dni x 0,001% to około 315 sekund.
Jaki jest dobowy budżet przestoju przy dostępności 99,9%? Około 86 sekund dziennie, z wyliczenia 1 440 minut/dzień x 0,1%.