Backup i SLA w usługach hostingowych

Uptime to czas, w którym usługa jest dostępna zgodnie z definicją dostawcy. Nie zawsze oznacza dostępność każdej aplikacji klienta, bo awaria kodu, błędna konfiguracja aplikacji albo przeciążenie generowane przez skrypt może leżeć poza zakresem SLA infrastruktury.

Dlatego przed zakupem warto sprawdzić, co dokładnie obejmuje SLA: warstwę sieciową, hosta wirtualizacji, storage, panel klienta czy także usługi dodatkowe. Dobre SLA powinno opisywać również prace planowane i wyłączenia odpowiedzialności.

Backup jest mechanizmem odtwarzania danych. Pomaga przy usunięciu plików, błędnej aktualizacji, awarii aplikacji, nadpisaniu konfiguracji albo problemie z bazą danych. Nie gwarantuje jednak braku przerwy, bo przywrócenie wymaga czasu i decyzji, do którego punktu odtworzyć usługę.

Przy projektach krytycznych backup dostawcy warto uzupełnić własną kopią aplikacyjną, eksportem bazy albo replikacją. Szczególnie ważne są sklepy i systemy, w których dane zmieniają się co kilka minut.

SLA działa tylko wtedy, gdy incydent jest mierzalny i prawidłowo zgłoszony. Zgłoszenie powinno zawierać identyfikator usługi, czas wystąpienia problemu, opis objawów, logi lub wyniki testów oraz informację, czy klient wykonywał w tym czasie zmiany konfiguracyjne.

Dobrą praktyką jest oddzielenie awarii infrastruktury od problemów aplikacyjnych. Jeśli serwer odpowiada, ale aplikacja zwraca błąd 500 po wdrożeniu, rozwiązaniem będzie analiza aplikacji albo przywrócenie danych, a nie reklamacja dostępności.

SLA 99.9% jest wystarczające dla wielu stron i aplikacji, ale nie zastępuje architektury wysokiej dostępności. Jeżeli każda minuta przestoju oznacza duże straty, potrzebne są co najmniej replikacja danych, redundantne instancje, automatyczne przełączenie i testy procedur awaryjnych.

VPS lub VDS może być elementem takiej architektury, ale pojedyncza maszyna zawsze pozostaje pojedynczym punktem zależności. Warto to uwzględnić przed pierwszą dużą kampanią sprzedażową, a nie dopiero po incydencie.