Kalkulator Uptime
Oblicz procent uptime i dopuszczalny downtime dla SLA
Dopuszczalny Downtime
8.77h
Na Rok
43.8m
Na Miesiąc
10.1m
Na Tydzień
1.4m
Na Dzień
Porównanie SLA
| Dostępność | Downtime/Rok | Downtime/Miesiąc | Downtime/Tydzień |
|---|---|---|---|
| 90% | 36.53d | 3.04d | 16.8h |
| 95% | 18.26d | 1.52d | 8.4h |
| 99% | 3.65d | 7.31h | 1.68h |
| 99.5% | 1.83d | 3.65h | 50.4m |
| 99.9% | 8.77h | 43.83m | 10.08m |
| 99.95% | 4.38h | 21.92m | 5.04m |
| 99.99% | 52.60m | 4.38m | 1.01m |
| 99.999% | 5.26m | 26.30s | 6.05s |
Rozumienie Uptime
- 99.9% = 8.76 godzin downtime rocznie (typowe dla większości usług)
- 99.95% = 4.38 godzin downtime rocznie (dobre dla aplikacji biznesowych)
- 99.99% = 52.56 minut downtime rocznie (klasa enterprise)
- 99.999% = 5.26 minut downtime rocznie (pięć dziewiątek, krytyczne)
Przewodnik po Uptime i SLA
Co to jest SLA?
Service Level Agreement (SLA) to umowa między dostawcą usług a klientem. Definiuje oczekiwany poziom usługi, w tym gwarancje uptime.
Standardy Branżowe
- 99.9% (Trzy Dziewiątki): Standard dla większości usług webowych
- 99.95%: Usługi o wysokiej dostępności
- 99.99% (Cztery Dziewiątki): Usługi klasy enterprise
- 99.999% (Pięć Dziewiątek): Systemy o krytycznym znaczeniu
Osiąganie Wysokiego Uptime
- Redundantna infrastruktura w wielu centrach danych
- Równoważenie obciążenia i mechanizmy failover
- Proaktywny monitoring i alerty
- Regularna konserwacja i aktualizacje
- Planowanie odzyskiwania po awarii
Koszt vs. Uptime
Każda dodatkowa "dziewiątka" mniej więcej podwaja koszt. 99.9% jest osiągalne przy dobrych praktykach. 99.99% wymaga znacznej inwestycji w redundancję. 99.999% wymaga infrastruktury enterprise.
Najczęściej Zadawane Pytania
Jaki jest dobry procent uptime?
99,9% (trzy dziewiątki) to standard dla większości produkcyjnych serwisów internetowych — pozwala to na maksymalnie 43,8 minut przestoju miesięcznie. Platformy SaaS i sklepy e-commerce często celują w 99,99% (cztery dziewiątki, ~4,4 minuty/miesiąc). Pięć dziewiątek (99,999%) wymaga znaczących inwestycji infrastrukturalnych i jest typowe dla systemów finansowych i infrastruktury krytycznej. Dla porównania: 99% uptime pozwala na 7,3 godziny przestoju miesięcznie, co jest generalnie zbyt niskie dla zastosowań biznesowych.
Co liczy się jako downtime?
Downtime to każdy okres, w którym serwis jest niedostępny lub nie działa zgodnie z oczekiwaniami. Obejmuje to: całkowite awarie (strona nie odpowiada), odpowiedzi z błędami HTTP (kody statusu 5xx), czasy odpowiedzi przekraczające zdefiniowane progi (np. timeout po 30 sekundach) oraz częściowe awarie (checkout nie działa, ale strona główna ładuje się). Większość SLA definiuje downtime na podstawie nieudanych health-checków zewnętrznego serwisu monitoringu.
Czy planowana konserwacja się liczy?
To zależy od definicji SLA. Wiele SLA jawnie wyklucza planowaną konserwację z obliczeń uptime, pod warunkiem że klienci są powiadamiani z wyprzedzeniem (zazwyczaj 48–72 godziny). Jednak niektóre restrykcyjne SLA liczą każdy przestój niezależnie od przyczyny. Zawsze jasno definiuj wyłączenia konserwacji w SLA przed wystąpieniem incydentów. Używaj publicznych stron statusu, aby transparentnie ogłaszać okna konserwacji klientom.
Jak mogę poprawić uptime?
Kluczowe strategie: wdróż redundancję (wiele serwerów, repliki bazy danych, load balancery) aby wyeliminować pojedyncze punkty awarii; rozmieść w wielu strefach dostępności lub regionach; wdróż automatyczny failover i health-checki; użyj CDN do obsługi skoków ruchu; zoptymalizuj zapytania do bazy danych i cache'owanie; skonfiguruj monitoring uptime z natychmiastowymi alertami w celu redukcji MTTR; i ćwicz reagowanie na incydenty z runbookami, aby Twój zespół mógł szybko przywracać serwis.
Jak obliczać kredyty SLA za przestój?
Obliczenia kredytów SLA różnią się w zależności od dostawcy. Powszechna formuła: procent kredytu = (rzeczywisty przestój / próg kontraktowego uptime) × mnożnik kredytu. Na przykład jeśli Twoje SLA gwarantuje 99,9% i doświadczasz 2 godzin przestoju w miesiącu (próg: 43,8 min), przekraczasz SLA i są należne kredyty. Wielu dostawców chmury (AWS, Azure, GCP) publikuje konkretne tabele kredytów: np. dostępność 99,0–99,9% = 10% kredytu, poniżej 99% = 25–30% kredytu.
Co to jest MTBF (Mean Time Between Failures)?
MTBF (Średni Czas Między Awariami) to średni czas między zakończeniem jednej awarii a rozpoczęciem następnej. Wysokie MTBF oznacza, że Twój serwis rzadko zawodzi. Oblicza się je jako: MTBF = Całkowity czas operacyjny / Liczba awarii. MTBF uzupełnia procent uptime — serwis może mieć 99,9% uptime, ale z częstymi krótkimi awariami (niskie MTBF) lub rzadkimi długimi (wysokie MTBF, niskie MTTR). Obie metryki są ważne.
Jaka jest różnica między uptime a niezawodnością?
Uptime mierzy procent czasu, w którym serwis jest dostępny. Niezawodność to prawdopodobieństwo, że serwis wykonuje swoją zamierzoną funkcję poprawnie, gdy jest dostępny. Serwis może mieć 99,9% uptime (rzadko niedostępny), ale niską niezawodność (częste błędy, złe dane, obniżona wydajność gdy działa). Prawdziwa jakość serwisu wymaga zarówno wysokiego uptime JAK I wysokiej niezawodności. Kompleksowy monitoring powinien śledzić obie wymiary.
Jak częstotliwość monitoringu wpływa na obliczenia uptime?
Częstotliwość monitoringu określa minimalny wykrywalny czas przestoju i dokładność obliczeń uptime. Przy sprawdzeniach co 5 minut, 3-minutowa awaria może nie zostać wykryta wcale — raport uptime pokazałby 100%, podczas gdy użytkownicy doświadczali przestoju. Przy sprawdzeniach co 1 minutę ta sama awaria jest wykrywana i rejestrowana. Dla dokładnych raportów zgodności SLA używaj monitoringu w interwale 1 minuty. Nasz kalkulator uptime oblicza dozwolony przestój na podstawie Twojego docelowego procentu SLA.
Chcesz Automatyczny Monitoring?
Uzyskaj monitoring 24/7 z natychmiastowymi alertami, gdy zostaną wykryte problemy.
Zacznij 14-dniowy okres próbny