Termin ze słownika

UPTIME

Procent czasu, w którym witryna lub usługa jest dostępna; 99,9% to powszechne minimum dla środowisk produkcyjnych.

Definicja

Uptime to procent czasu, w którym witryna lub usługa jest dostępna i działa poprawnie w danym okresie, i stanowi on kluczowy wskaźnik niezawodności w hostingu. Zwykle wyrażany jest jako „liczba dziewiątek”: 99,9% (trzy dziewiątki) dopuszcza około 8,7 godziny przestoju rocznie, 99,99% (cztery dziewiątki) dopuszcza mniej niż godzinę, a 99,999% (pięć dziewiątek) dopuszcza mniej niż sześć minut. Większość renomowanych dostawców hostingu publikuje gwarancję uptime'u w swoim SLA, zwykle 99,9% w planach współdzielonych i 99,99% w planach zarządzanych lub korporacyjnych, przy czym zwykłym środkiem zaradczym są kredyty serwisowe, a nie zwroty pieniędzy. Ta umowna wartość stanowi dolną granicę, a nie pomiar: niezależne monitory zewnętrzne, takie jak UptimeRobot, StatusCake i Pingdom, odpytują witrynę spoza sieci dostawcy hostingu w regularnych odstępach czasu, co jest bardziej użyteczne niż jakakolwiek wartość podawana przez samego dostawcę. Wyższe dziewiątki kosztują więcej i mają większe znaczenie dla witryn krytycznych dla przychodów niż dla bloga osobistego.

Jak to działa

Uptime mierzony jest poprzez odpytywanie witryny z wielu lokalizacji zewnętrznych w regularnych odstępach czasu (często co minutę) i rejestrowanie procentu udanych odpowiedzi. Przestój może wystąpić w dowolnym miejscu łańcucha: awaria serwera źródłowego, problemy z DNS, awarie CDN, problemy sieciowe, a nawet wygaśnięcie certyfikatu.

Dlaczego to ma znaczenie

Każda minuta przestoju kosztuje przychody, pozycję w wynikach wyszukiwania i zaufanie. SLA dostawcy hostingu stanowi umowną dolną granicę; liczy się rzeczywisty, zmierzony uptime na przestrzeni miesięcy. Dla e-commerce uzasadniony jest cel na poziomie pięciu dziewiątek; dla bloga zwykle wystarczą trzy dziewiątki.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Najczęściej zadawane pytania

Jaki uptime hostingu jest dobry?

99,9% (około 8,7 godziny przestoju rocznie) to powszechne minimum dla środowisk produkcyjnych; 99,99% (mniej niż godzina) to wartość, którą zazwyczaj gwarantują dostawcy hostingu zarządzanego i korporacyjnego.

Jak mierzy się uptime?

Poprzez odpytywanie witryny przez zewnętrzne usługi monitorujące w częstych odstępach czasu i rejestrowanie proporcji udanych odpowiedzi. UptimeRobot, StatusCake i Pingdom to powszechni dostawcy tego typu usług.

Jak zweryfikować deklaracje dostawcy hostingu dotyczące uptime'u przed zakupem?

Nie należy ufać stronie marketingowej. Warto sprawdzić historię publicznej strony statusu dostawcy hostingu lub uruchomić własny monitor zewnętrzny (darmowy plan UptimeRobot) na podobnym planie przez kilka tygodni przed podjęciem decyzji. Niezależne narzędzia do śledzenia uptime'u oraz wątki na forach dotyczące niedawnych awarii są bardziej wiarygodne niż sama wartość z SLA.

Czy kredyt z SLA rekompensuje straty wynikające z przestoju?

Nie. Kredyty SLA to zazwyczaj niewielki procent miesięcznej opłaty za hosting, a nie rekompensata za utracone sprzedaże czy szkody wizerunkowe. Czterogodzinny przestój w witrynie e-commerce może kosztować znacznie więcej w utraconych przychodach niż jakikolwiek zwrot w postaci kredytu. SLA należy traktować jako minimalne zobowiązanie serwisowe, a nie ubezpieczenie.

Jakie są powszechne przyczyny przestojów, nad którymi dostawcy hostingu nie mają kontroli?

Błędna konfiguracja DNS, wygasłe certyfikaty TLS, awarie CDN lub sieci nadrzędnej, ataki DDoS oraz nieudane wdrożenia aplikacji odpowiadają za więcej rzeczywistych przestojów niż awaria samego serwera źródłowego. Monitorowanie wyłącznie serwera, a nie całej ścieżki żądania od przeglądarki do backendu, pomija większość tych awarii.