W ofertach hostingowych często pojawiają się wartości:
- uptime 99,9%,
- dostępność 99,95%,
- SLA 99,99%,
- infrastruktura działająca 24/7.
Na pierwszy rzut oka wszystkie wyglądają bardzo dobrze.
Różnica pomiędzy 99,9% a 99,99% wynosi zaledwie 0,09 punktu procentowego. Można więc uznać, że nie ma większego znaczenia.
W praktyce ta niewielka różnica może oznaczać przejście z prawie dziewięciu godzin dopuszczalnego przestoju rocznie do mniej niż jednej godziny.
To jednak dopiero początek.
Samo hasło „SLA 99,9%” nie mówi jeszcze:
- co dokładnie jest objęte gwarancją,
- jak mierzona jest dostępność,
- które awarie są wyłączone,
- czy SLA dotyczy serwera, sieci czy konkretnej strony,
- co otrzyma klient po przekroczeniu limitu,
- kto odpowiada za naprawę aplikacji.
Hosting może formalnie spełniać SLA, a strona klienta nadal może przez wiele godzin nie przyjmować zamówień lub formularzy.
Dlatego procent dostępności trzeba czytać razem z regulaminem, sposobem monitorowania i zakresem opieki technicznej.
Co oznacza skrót SLA?
SLA pochodzi od angielskiego określenia Service Level Agreement.
Jest to deklarowany lub umownie określony poziom świadczenia usługi.
W hostingu SLA może dotyczyć między innymi:
- dostępności sieci,
- działania serwera,
- dostępu do infrastruktury,
- czasu reakcji pomocy technicznej,
- czasu rozpoczęcia usuwania awarii,
- wykonywania kopii zapasowych.
Najczęściej spotykanym parametrem jest dostępność wyrażona procentowo.
Przykład:
**SLA 99,9% dostępności miesięcznie.**
Oznacza to, że zgodnie z przyjętym sposobem obliczania usługa może być niedostępna przez określoną część miesiąca, a mimo to dostawca nadal zachowa deklarowany poziom SLA.
Czym jest uptime?
Uptime oznacza czas, przez który usługa jest dostępna i działa.
Może dotyczyć:
- serwera,
- maszyny wirtualnej,
- sieci,
- strony internetowej,
- aplikacji,
- API,
- bazy danych.
Problem polega na tym, że te elementy nie są tym samym.
Serwer może być uruchomiony, ale strona może nie działać z powodu:
- błędu aplikacji,
- niedziałającej bazy,
- zatrzymanego procesu Node.js,
- awarii PHP-FPM,
- błędnej aktualizacji,
- nieprawidłowej konfiguracji DNS,
- wygasłego certyfikatu SSL.
Dostawca może raportować poprawne działanie infrastruktury, podczas gdy klient widzi błąd 500 albo 502.
Dlatego trzeba ustalić, czy deklarowany uptime dotyczy fizycznego serwera, sieci dostawcy, VPS czy faktycznej dostępności strony dla klienta.
Ile przestoju oznacza uptime 99,9%?
Wartość 99,9% wygląda bardzo blisko 100%.
W skali roku oznacza jednak około:
- **8 godzin i 46 minut niedostępności rocznie,**
- **43 minuty i 48 sekund niedostępności w przeciętnym 30-dniowym miesiącu,**
- **około 10 minut niedostępności tygodniowo.**
To wartości orientacyjne. Dokładny wynik zależy od długości okresu rozliczeniowego oraz sposobu liczenia stosowanego przez dostawcę.
Dla prostej strony firmowej kilka krótkich przerw w ciągu roku może być akceptowalne.
Dla sklepu, systemu rezerwacji lub aplikacji pracującej bez przerwy prawie dziewięć godzin niedostępności może oznaczać realne straty.
Porównanie dostępności hostingu
Orientacyjny dopuszczalny czas niedostępności wygląda następująco:
| Dostępność | Przestój w ciągu roku | Przestój w ciągu 30 dni |
| ---------- | ---------------------------: | --------------------------: |
| 99% | około 3 dni i 15 godzin | około 7 godzin i 12 minut |
| 99,5% | około 43 godziny i 48 minut | około 3 godziny i 36 minut |
| 99,9% | około 8 godzin i 46 minut | około 43 minuty i 48 sekund |
| 99,95% | około 4 godziny i 23 minuty | około 21 minut i 54 sekundy |
| 99,99% | około 52 minuty i 34 sekundy | około 4 minuty i 23 sekundy |
| 99,999% | około 5 minut i 15 sekund | około 26 sekund |
Różnica pomiędzy 99,9% a 99,99% nie jest więc kosmetyczna.
Przy 99,9% możliwe jest prawie dziewięć godzin niedostępności rocznie.
Przy 99,99% limit spada do niecałej godziny.
Uzyskanie wyższej dostępności wymaga jednak bardziej rozbudowanej i kosztownej infrastruktury.
Czy uptime 100% jest możliwy?
W marketingu można spotkać obietnice dostępności 100%.
W praktyce każda infrastruktura może wymagać:
- aktualizacji,
- restartu,
- wymiany sprzętu,
- prac sieciowych,
- reakcji na awarię,
- zmiany konfiguracji.
Pojedynczy serwer bez redundancji zawsze posiada elementy, których awaria może zatrzymać usługę.
Zbliżenie się do rzeczywistej dostępności 100% wymaga między innymi:
- wielu serwerów,
- niezależnych łączy,
- replikacji danych,
- automatycznego przełączania,
- load balancera,
- kilku lokalizacji,
- stałego monitoringu.
Nawet wtedy mogą pojawić się problemy z aplikacją, konfiguracją lub zewnętrznymi usługami.
Dlatego bardziej wiarygodne od ogólnego hasła „100% uptime” jest jasne opisanie architektury, monitoringu i zasad reagowania.
SLA infrastruktury nie jest SLA strony
To najważniejsze rozróżnienie.
Dostawca hostingu może zagwarantować dostępność:
- centrum danych,
- sieci,
- serwera fizycznego,
- platformy VPS.
Nie musi gwarantować działania kodu klienta.
Jeżeli WordPress przestanie działać po aktualizacji wtyczki, infrastruktura może być całkowicie sprawna.
Jeżeli proces Node.js zatrzyma się przez błąd aplikacji, VPS nadal może odpowiadać na poziomie systemu.
Jeżeli formularz przestanie wysyłać wiadomości, serwer nadal będzie wyświetlał stronę główną.
Dlatego hosting bez opieki może formalnie spełniać wszystkie parametry, a biznesowa funkcja strony nadal może być niedostępna.
Problemy aplikacyjne, takie jak [błąd 500 lub 502 na stronie](/blog/blad-500-lub-502-na-stronie-co-oznacza-i-jak-naprawic), wymagają diagnozy wykraczającej poza kontrolę samej infrastruktury.
Co może zostać wyłączone z SLA?
Szczegółowe warunki zależą od umowy konkretnego dostawcy.
Z obliczeń dostępności często wyłączane są między innymi:
- zapowiedziane prace techniczne,
- konserwacja infrastruktury,
- awarie po stronie klienta,
- błędna konfiguracja aplikacji,
- ataki lub zdarzenia zewnętrzne,
- problemy z DNS poza infrastrukturą dostawcy,
- awarie zewnętrznych operatorów,
- niedostępność wynikająca z nieopłacenia usługi,
- siła wyższa,
- migracje zlecone przez klienta.
Może się więc okazać, że strona nie działała przez dwie godziny, ale przerwa nie zostanie wliczona do SLA, ponieważ była zaplanowana albo wynikała z konfiguracji klienta.
Dlatego procent dostępności trzeba czytać razem z listą wyłączeń.
Bez niej sama liczba może być myląca.
Planowane prace techniczne
Operatorzy muszą aktualizować i konserwować infrastrukturę.
Prace mogą obejmować:
- aktualizację systemu,
- wymianę sprzętu,
- modernizację sieci,
- zmianę konfiguracji,
- restart hosta,
- przeniesienie maszyn.
Dostawca może zapowiedzieć przerwę wcześniej i nie uwzględniać jej w obliczaniu SLA.
Z punktu widzenia klienta strona nadal może być niedostępna.
Dlatego warto sprawdzić:
- jak często wykonywane są prace,
- z jakim wyprzedzeniem są ogłaszane,
- w jakich godzinach się odbywają,
- czy wymagają pełnego zatrzymania usługi.
Dobrze zaplanowana konserwacja w godzinach najmniejszego ruchu jest czymś innym niż nagła awaria w czasie kampanii sprzedażowej.
Jak dostawca mierzy uptime?
Sposób pomiaru ma ogromne znaczenie.
Dostępność może być sprawdzana:
- co minutę,
- co pięć minut,
- co piętnaście minut,
- z jednej lokalizacji,
- z kilku punktów,
- na poziomie sieci,
- na poziomie serwera.
Jeżeli test odbywa się co pięć minut, krótka awaria może nie zostać zarejestrowana.
Jeżeli monitoring wykonywany jest z wewnętrznej infrastruktury operatora, może nie wykryć problemu występującego dla użytkowników określonej sieci.
Warto ustalić:
- co dokładnie jest testowane,
- jak często,
- z jakiej lokalizacji,
- jaki czas odpowiedzi jest uznawany za poprawny,
- ile kolejnych błędów potwierdza awarię.
Czy wolna strona jest niedostępna?
To zależy od definicji stosowanej w SLA.
Strona może odpowiadać kodem 200, ale ładować się przez 20 sekund.
Dla technicznego pomiaru może być uznana za dostępną.
Dla klienta może być praktycznie bezużyteczna.
Podobnie aplikacja może odpowiadać, ale:
- nie zapisywać danych,
- nie przyjmować płatności,
- nie wyświetlać panelu,
- przerywać sesję.
Dlatego oprócz uptime warto monitorować:
- czas odpowiedzi,
- działanie formularzy,
- koszyk,
- checkout,
- API,
- bazę danych,
- procesy aplikacji.
W artykule [jak sprawdzić, czy hosting spowalnia stronę](/blog/jak-sprawdzic-czy-hosting-spowalnia-strone) opisaliśmy, jak odróżnić problem infrastruktury od błędów strony lub bazy.
SLA a czas reakcji pomocy technicznej
Dostępność i czas reakcji to dwa różne parametry.
SLA może określać, że dostawca:
- odpowie na zgłoszenie w określonym czasie,
- rozpocznie diagnozę w określonym czasie,
- nada priorytet awarii krytycznej.
Nie zawsze oznacza to, że problem zostanie w tym czasie naprawiony.
Trzeba rozróżnić:
**Czas odpowiedzi** – kiedy klient otrzyma pierwszą reakcję.
**Czas rozpoczęcia prac** – kiedy ktoś faktycznie zacznie analizę.
**Czas przywrócenia** – kiedy usługa wróci do działania.
Informacja „reakcja do godziny” może oznaczać jedynie potwierdzenie przyjęcia zgłoszenia.
Dlatego w krytycznych systemach warto ustalić wszystkie trzy elementy.
Co otrzymuje klient po niedotrzymaniu SLA?
Najczęściej rekompensata nie jest wypłatą pełnej wartości utraconej sprzedaży.
Może mieć formę:
- częściowego zwrotu abonamentu,
- rabatu,
- przedłużenia usługi,
- środków na kolejne rozliczenie.
Wysokość rekompensaty jest zwykle powiązana z ceną hostingu, a nie ze stratami biznesowymi klienta.
Jeżeli sklep straci kilka tysięcy złotych sprzedaży, rekompensata może wynosić jedynie część miesięcznej opłaty za serwer.
SLA jest więc zobowiązaniem usługowym, ale nie zastępuje:
- backupów,
- redundancji,
- monitoringu,
- planu awaryjnego,
- opieki technicznej.
Czy SLA gwarantuje odszkodowanie automatycznie?
Nie zawsze.
Klient może być zobowiązany do:
- zgłoszenia awarii,
- wskazania konkretnego okresu,
- złożenia reklamacji,
- zachowania terminu,
- przedstawienia danych technicznych.
Jeżeli nie zgłosi problemu zgodnie z procedurą, rekompensata może nie zostać przyznana.
Warto wcześniej sprawdzić:
- sposób składania reklamacji,
- termin zgłoszenia,
- sposób obliczania przestoju,
- maksymalną wartość rekompensaty.
W chwili poważnej awarii nie jest dobrym momentem na pierwsze czytanie warunków umowy.
Uptime hostingu a monitoring zewnętrzny
Operator monitoruje własną infrastrukturę.
Firma powinna jednak posiadać również niezależny monitoring swojej strony.
Zewnętrzny system może sprawdzać:
- publiczny adres,
- kod HTTP,
- czas odpowiedzi,
- certyfikat SSL,
- formularz,
- API,
- koszyk,
- proces rezerwacji.
Dzięki temu firma posiada własne dane dotyczące dostępności.
Może również wykryć problemy, których monitoring operatora nie obejmuje.
Zakres właściwej kontroli opisaliśmy w artykule [monitoring strony internetowej 24/7 – co naprawdę powinien sprawdzać](/blog/monitoring-strony-internetowej-24-7-co-powinien-sprawdzac).
Czy jeden test wystarczy?
Nie zawsze.
Pojedynczy punkt monitorujący może mieć własny problem sieciowy.
Dlatego alarm warto potwierdzać:
- kolejnym testem,
- drugim regionem,
- kontrolą źródłowego serwera,
- testem innej podstrony.
Pozwala to ograniczyć liczbę fałszywych alertów.
Dla krytycznych systemów monitoring może działać z kilku lokalizacji.
Jeżeli strona jest niedostępna tylko dla użytkowników jednego operatora, problem może dotyczyć trasy sieciowej, a nie samego serwera.
SLA a hosting współdzielony
W hostingu współdzielonym wielu klientów korzysta ze wspólnej infrastruktury.
Operator odpowiada za:
- serwer,
- sieć,
- system,
- podstawowe usługi.
Klient posiada ograniczoną kontrolę nad:
- zasobami,
- konfiguracją,
- sposobem skalowania,
- działaniem innych kont.
Dla prostej strony firmowej może to być wystarczające rozwiązanie.
Trzeba jednak sprawdzić:
- czy SLA jest formalnie określone,
- jakie obowiązują limity,
- czy monitoring obejmuje stronę,
- jak wygląda reakcja na przeciążenie.
SLA a VPS
VPS daje większą kontrolę nad środowiskiem.
SLA dostawcy może dotyczyć dostępności:
- platformy wirtualizacyjnej,
- sieci,
- hosta fizycznego.
Nie musi obejmować usług uruchomionych przez klienta.
Jeżeli system VPS działa, ale Nginx, baza albo proces aplikacji są zatrzymane, dostawca może uznać infrastrukturę za dostępną.
Dlatego VPS wymaga własnego monitoringu:
- systemu,
- aplikacji,
- bazy,
- backupów,
- zasobów.
Różnice pomiędzy środowiskami opisaliśmy w artykule [VPS czy hosting współdzielony – co wybrać dla firmy](/blog/vps-czy-hosting-wspoldzielony-co-wybrac-dla-firmy).
SLA a aplikacja Next.js i Node.js
Aplikacja może składać się z:
- frontendu,
- backendu,
- bazy,
- Redis,
- kolejki,
- workera,
- zewnętrznego API.
Każdy element może posiadać inną dostępność.
Frontend może działać, ale backend nie odpowiada.
API może działać, ale baza jest niedostępna.
Proces może być aktywny, ale kolejka nie przetwarza zadań.
Dlatego SLA samego VPS nie opisuje pełnej dostępności aplikacji.
Wymagania takiego środowiska przedstawiliśmy w artykule [hosting dla Next.js i Node.js – czego potrzebuje aplikacja firmowa](/blog/hosting-dla-nextjs-nodejs-czego-potrzebuje-aplikacja-firmowa).
SLA a WordPress
Strona WordPress może być niedostępna przez:
- konflikt wtyczek,
- błąd motywu,
- nieudaną aktualizację,
- brak pamięci,
- uszkodzoną bazę,
- infekcję.
Żaden z tych problemów nie musi oznaczać awarii infrastruktury hostingowej.
Dlatego firma potrzebuje nie tylko gwarancji dostępności serwera, ale również:
- aktualizacji,
- backupów,
- monitoringu,
- możliwości przywrócenia,
- osoby odpowiedzialnej za diagnozę.
Zakres takiej usługi opisaliśmy w artykule [hosting WordPress z opieką – co powinien obejmować](/blog/hosting-wordpress-z-opieka-co-powinien-obejmowac).
SLA a sklep WooCommerce
W sklepie dostępność strony głównej nie oznacza, że można dokonać zakupu.
Może nie działać:
- koszyk,
- checkout,
- płatność,
- e-mail transakcyjny,
- integracja magazynowa.
Podstawowy monitoring hostingu może nie wykryć takich problemów.
Dla sklepu warto kontrolować całą ścieżkę zakupową.
Więcej o wymaganiach infrastruktury sprzedażowej opisaliśmy w artykule [hosting WooCommerce – na czym nie warto oszczędzać](/blog/hosting-woocommerce-na-czym-nie-warto-oszczedzac).
SLA a CDN
CDN może poprawić dostępność statycznych zasobów i odciążyć główny serwer.
Nie oznacza jednak, że aplikacja będzie działała podczas każdej awarii źródła.
CDN może nadal pokazywać:
- zapisane obrazy,
- arkusze stylów,
- część treści.
Nie obsłuży jednak bez źródła wielu operacji dynamicznych.
Zasady działania takiej infrastruktury opisaliśmy w artykule [CDN – co to jest i czy przyspiesza stronę internetową](/blog/cdn-co-to-jest-i-czy-przyspiesza-strone-internetowa).
Czy backup zwiększa uptime?
Backup nie zapobiega bezpośrednio awarii.
Pozwala jednak szybciej przywrócić usługę.
Jeżeli firma posiada:
- aktualną kopię,
- przygotowaną procedurę,
- dostęp do nowego środowiska,
- osobę odpowiedzialną za odtworzenie,
czas niedostępności może być znacznie krótszy.
Backup bez testów może natomiast nie pomóc w krytycznym momencie.
Zasady wykonywania kopii opisaliśmy w artykule [kopie zapasowe strony – jak często je wykonywać i gdzie przechowywać](/blog/kopie-zapasowe-strony-jak-czesto-i-gdzie-przechowywac).
Uptime a RTO
RTO określa, jak szybko usługa powinna zostać przywrócona po awarii.
Możliwe jest środowisko o wysokim uptime, ale długim czasie odtwarzania po poważnym incydencie.
Przykładowo serwer może działać stabilnie przez wiele miesięcy, ale po awarii dysku odtworzenie systemu może potrwać wiele godzin.
Dlatego warto określić:
- dopuszczalny czas niedostępności,
- maksymalny czas przywrócenia,
- kto uruchamia procedurę,
- skąd zostaną odtworzone dane.
Uptime a RPO
RPO określa, jak dużo danych firma może stracić.
SLA może gwarantować dostępność serwera na poziomie 99,9%, ale nie mówić nic o aktualności kopii.
Jeżeli baza jest kopiowana raz dziennie, poważna awaria może oznaczać utratę zmian z ostatnich 24 godzin.
Dla strony informacyjnej może być to akceptowalne.
Dla sklepu lub systemu rezerwacji niekoniecznie.
Dlatego dostępność trzeba analizować razem z częstotliwością backupów.
Redundancja
Redundancja oznacza posiadanie zapasowego elementu, który może przejąć pracę po awarii.
Może dotyczyć:
- serwera,
- dysku,
- zasilania,
- sieci,
- bazy danych,
- lokalizacji.
Przykładowo dwa serwery aplikacji mogą działać za load balancerem.
Jeżeli jeden przestanie odpowiadać, ruch zostanie przekazany do drugiego.
Redundancja zwiększa dostępność, ale również:
- koszt,
- złożoność,
- wymagania monitoringu,
- liczbę możliwych błędów konfiguracji.
Nie każda strona firmowa potrzebuje rozbudowanego klastra.
Infrastruktura powinna być dopasowana do wartości chronionej usługi.
Wysoka dostępność bazy danych
Baza jest często najważniejszym elementem sklepu lub aplikacji.
Można stosować:
- replikację,
- zapasową instancję,
- automatyczne przełączenie,
- regularne snapshoty,
- częste backupy.
Sama replikacja nie jest jednak kopią zapasową.
Jeżeli aplikacja błędnie usunie dane, zmiana może zostać powielona na serwerze zapasowym.
Dlatego wysoka dostępność i backup rozwiązują różne problemy.
Czy mała firma potrzebuje SLA 99,99%?
Nie zawsze.
Dla lokalnej strony informacyjnej ważniejsze mogą być:
- regularne kopie,
- poprawne aktualizacje,
- szybka pomoc,
- monitoring formularza.
Koszt infrastruktury zapewniającej bardzo wysoką dostępność może być nieproporcjonalny do wartości strony.
Z drugiej strony sklep, system rezerwacji lub aplikacja SaaS mogą wymagać bardziej rygorystycznego poziomu.
Decyzja powinna zależeć od:
- wartości sprzedaży,
- liczby użytkowników,
- kosztu awarii,
- godzin działania,
- możliwości pracy zastępczej.
Jak policzyć koszt godziny awarii?
Firma powinna oszacować:
- średnią sprzedaż na godzinę,
- liczbę zapytań,
- koszt kampanii reklamowych,
- czas pracowników,
- wpływ na klientów,
- koszt naprawy.
Przykład:
Sklep generuje średnio 1000 zł sprzedaży dziennie.
Nie oznacza to automatycznie, że każda godzina awarii kosztuje dokładnie 41,67 zł. Sprzedaż może być skoncentrowana w określonych godzinach, a część klientów wróci później.
Obliczenie daje jednak punkt odniesienia.
Jeżeli potencjalna strata jest wysoka, inwestycja w monitoring, redundancję i szybszą reakcję staje się łatwiejsza do uzasadnienia.
Czy rekompensata SLA pokrywa straty?
Najczęściej nie.
Koszt hostingu może wynosić kilkadziesiąt albo kilkaset złotych miesięcznie.
Straty firmy podczas awarii mogą być znacznie wyższe.
SLA ogranicza odpowiedzialność usługodawcy i określa poziom usługi, ale nie zastępuje biznesowego planu ciągłości działania.
Firma powinna posiadać własne zabezpieczenia odpowiednie do ryzyka.
Jak zwiększyć rzeczywistą dostępność strony?
W zależności od projektu można zastosować:
- sprawdzony hosting,
- VPS zarządzany,
- monitoring zewnętrzny,
- alerty,
- automatyczny restart procesów,
- kopie poza serwerem,
- testy odtwarzania,
- CDN,
- redundancję,
- środowisko testowe,
- kontrolowane wdrożenia.
Ważne jest również ograniczanie błędów operacyjnych.
Wiele awarii nie wynika z uszkodzenia sprzętu, ale z:
- nieudanej aktualizacji,
- błędnej konfiguracji,
- przypadkowego usunięcia,
- wdrożenia bez testów.
SLA a bezpieczeństwo
Atak może spowodować niedostępność strony, ale nie każda umowa zaliczy taki problem do awarii objętej SLA.
Dlatego oprócz deklarowanego uptime potrzebne są:
- firewall,
- aktualizacje,
- ochrona dostępów,
- monitoring,
- kopie,
- procedura reagowania.
Zasady ochrony środowiska opisaliśmy w artykule [bezpieczny hosting dla firmy – jak chronić stronę przed atakami](/blog/bezpieczny-hosting-dla-firmy-jak-chronic-strone-przed-atakami).
SLA a poczta firmowa
Strona i poczta mogą działać na tym samym hostingu.
Awaria wspólnego środowiska może wtedy unieruchomić oba kanały.
Jeżeli usługi są rozdzielone, firma może nadal komunikować się podczas problemów ze stroną.
Nie oznacza to, że rozdzielenie jest zawsze konieczne.
Model trzeba dopasować do znaczenia poczty i kosztu niedostępności.
Różnice opisaliśmy w artykule [hosting strony i poczty firmowej – razem czy osobno](/blog/hosting-strony-i-poczty-firmowej-razem-czy-osobno).
Co sprawdzić w ofercie hostingu?
Przed zakupem warto znaleźć odpowiedzi na pytania:
1. Jaki poziom SLA jest deklarowany?
2. Czy SLA znajduje się w umowie lub regulaminie?
3. Czego dokładnie dotyczy?
4. Jaki jest okres rozliczeniowy?
5. Jak mierzona jest dostępność?
6. Jak często wykonywane są pomiary?
7. Jakie zdarzenia są wyłączone?
8. Czy prace techniczne wliczają się do przestoju?
9. Jak zgłasza się naruszenie SLA?
10. Jak wygląda rekompensata?
11. Czy monitoring obejmuje konkretną stronę?
12. Czy pomoc diagnozuje aplikację?
13. Jak często wykonywane są kopie?
14. Jak wygląda przywracanie?
15. Jaki jest czas reakcji na awarię?
SLA hostingu z opieką HeatLogic
W HeatLogic nie traktujemy dostępności wyłącznie jako informacji, że serwer jest włączony.
Dla strony biznesowej ważne jest również, czy działa:
- formularz,
- sklep,
- API,
- system rezerwacji,
- certyfikat SSL,
- baza danych,
- proces aplikacji.
Zakres usługi może obejmować:
- hosting lub VPS,
- monitoring strony,
- monitoring procesów,
- alerty,
- kopie bezpieczeństwa,
- kontrolowane aktualizacje,
- analizę błędów,
- reakcję na awarie.
Usługa może zostać połączona z [hostingiem i opieką techniczną HeatLogic](/hosting-i-opieka).
Nie każdej stronie potrzebna jest infrastruktura klasy wysokiej dostępności.
Najpierw sprawdzamy, jakie skutki dla firmy spowoduje awaria i które elementy projektu są naprawdę krytyczne.
Lista kontrolna SLA i uptime
Sprawdź:
1. Czy oferta zawiera formalne SLA?
2. Czy SLA dotyczy serwera, sieci czy strony?
3. Jaki okres jest podstawą obliczeń?
4. Ile przestoju oznacza deklarowany procent?
5. Jak często wykonywany jest pomiar?
6. Z jakich lokalizacji odbywa się monitoring?
7. Jakie awarie są wyłączone?
8. Czy prace planowane wliczają się do SLA?
9. Czy wolna odpowiedź jest uznawana za awarię?
10. Czy SLA obejmuje bazę danych?
11. Czy obejmuje proces aplikacji?
12. Czy obejmuje pocztę?
13. Jaki jest czas odpowiedzi wsparcia?
14. Jaki jest czas rozpoczęcia prac?
15. Czy określono czas przywrócenia?
16. Jak wygląda rekompensata?
17. Czy klient musi sam złożyć reklamację?
18. Czy działa niezależny monitoring?
19. Czy dostępne są kopie poza serwerem?
20. Czy istnieje plan awaryjny?
Podsumowanie
SLA hostingu 99,9% nie oznacza, że strona nigdy nie przestanie działać.
W skali roku taki poziom dostępności pozwala na około osiem godzin i 46 minut niedostępności.
Trzeba również sprawdzić:
- co dokładnie obejmuje SLA,
- które przerwy są wyłączone,
- jak wykonywany jest pomiar,
- jak wygląda rekompensata,
- czy gwarancja dotyczy infrastruktury, czy konkretnej aplikacji.
Dla firmy najważniejszy nie jest sam procent w ofercie.
Liczy się cały system:
- monitoring,
- backup,
- czas reakcji,
- możliwość odtworzenia,
- osoba odpowiedzialna za naprawę.
Hosting może spełniać swoje SLA, a strona nadal może nie działać z powodu błędu aplikacji.
Dlatego dla stron generujących sprzedaż, zapytania albo rezerwacje warto połączyć stabilną infrastrukturę ze stałą opieką techniczną.
Nie wiesz, czy obecna gwarancja hostingu rzeczywiście zabezpiecza Twój biznes?
Skontaktuj się z HeatLogic. Sprawdzimy środowisko, monitoring, backupy i ryzyka oraz wskażemy, które elementy wymagają dodatkowego zabezpieczenia.
Najczęściej zadawane pytania
Co oznacza SLA 99,9%?
Oznacza deklarowaną dostępność na poziomie 99,9% w określonym okresie. W ciągu roku odpowiada to około ośmiu godzinom i 46 minutom możliwej niedostępności.
Ile przestoju oznacza 99,99%?
Około 52 minut i 34 sekund rocznie albo około czterech minut i 23 sekund w 30-dniowym miesiącu.
Czy SLA dotyczy działania strony internetowej?
Nie zawsze. Może dotyczyć wyłącznie sieci, serwera lub platformy VPS. Błąd WordPressa albo aplikacji może nie być objęty gwarancją.
Czy planowane prace techniczne są wliczane do SLA?
Zależy to od warunków dostawcy. Często zapowiedziane prace techniczne są wyłączone z obliczania dostępności.
Co otrzymam, gdy dostawca nie dotrzyma SLA?
Najczęściej rabat, przedłużenie usługi albo częściowy zwrot abonamentu. Rekompensata zwykle nie pokrywa pełnych strat biznesowych.
Czy uptime 100% jest realny?
Bardzo trudno zagwarantować całkowity brak przerw. Wysoka dostępność wymaga redundancji, kilku usług, monitoringu i procedur awaryjnych.
Czy monitoring operatora wystarczy?
Nie zawsze. Operator może sprawdzać infrastrukturę, ale nie formularz, koszyk, API lub bazę konkretnej strony. Warto posiadać niezależny monitoring aplikacji.