Niniejszy dokument opisuje zasady dostępności usług FlexCloud, sposób rozumienia uptime, procedurę zgłaszania incydentów, wyjątki od odpowiedzialności oraz model rekompensat. SLA ma zastosowanie do usług VPS, VDS i Hostingu WWW, o ile opis konkretnego planu lub indywidualna umowa nie przewiduje innych parametrów.

SLA dotyczy dostępności infrastruktury pozostającej pod kontrolą FlexCloud, w szczególności hostów wirtualizacji, wybranych elementów sieci, storage, podstawowych usług platformy i panelu klienta w zakresie wymaganym do obsługi usług. SLA nie jest gwarancją działania aplikacji klienta, kodu, wtyczek, motywów, baz danych skonfigurowanych przez klienta ani zewnętrznych integracji.

Celem FlexCloud jest zapewnienie stabilnego środowiska dla stron internetowych, aplikacji, sklepów i usług serwerowych. Jednocześnie każda infrastruktura wymaga prac utrzymaniowych, aktualizacji bezpieczeństwa i reagowania na zdarzenia niezależne od dostawcy. Z tego powodu SLA określa zarówno cel dostępności, jak i sytuacje, które nie są liczone jako naruszenie.

Uptime oznacza procentowy czas dostępności usługi w danym okresie rozliczeniowym, mierzony jako stosunek czasu, w którym infrastruktura FlexCloud umożliwia korzystanie z usługi, do całkowitego czasu w tym okresie. Standardowym celem dostępności dla usług produkcyjnych jest 99.9%, chyba że opis planu wskazuje inny poziom.

Za niedostępność na potrzeby SLA uznaje się sytuację, w której usługa nie odpowiada z powodu awarii infrastruktury FlexCloud, a klient nie ma technicznej możliwości korzystania z usługi zgodnie z jej przeznaczeniem. Przykładem może być awaria hosta wirtualizacji, awaria warstwy storage albo problem sieciowy po stronie FlexCloud powodujący brak osiągalności usługi.

Do niedostępności nie zalicza się błędów aplikacji klienta, błędnej konfiguracji DNS, wygaśnięcia domeny, przekroczenia limitów wynikającego z działania aplikacji, braku płatności, zawieszenia za nadużycie, ataku na aplikację klienta, niepoprawnej konfiguracji firewalla, utraty hasła, błędów wdrożenia albo działań wykonanych przez klienta w panelu lub systemie operacyjnym.

Dostępność jest oceniana na podstawie monitoringu FlexCloud, logów infrastruktury, danych z systemów sieciowych, statusu hostów, zgłoszeń klienta oraz informacji diagnostycznych zebranych podczas incydentu. Pomiar może różnić się od zewnętrznych narzędzi monitorujących klienta, ponieważ narzędzia te mogą działać z określonych lokalizacji, używać własnych progów i być podatne na problemy po stronie operatorów tranzytowych.

Klient może przedstawić własne dane monitoringowe jako materiał pomocniczy, ale podstawą rozpatrzenia zgłoszenia SLA są dane pozwalające potwierdzić przyczynę po stronie infrastruktury FlexCloud. Zgłoszenie powinno zawierać dokładny czas problemu, identyfikator usługi, adres IP lub domenę, opis objawów, wyniki testów i informację o ostatnich zmianach wykonanych przez klienta.

Czas niedostępności liczony jest od momentu potwierdzenia awarii objętej SLA przez FlexCloud albo od momentu wystąpienia awarii potwierdzonego w logach infrastruktury, jeśli nastąpił wcześniej. Czas kończy się w momencie przywrócenia działania infrastruktury, a nie w momencie naprawy aplikacji klienta, jeśli aplikacja wymaga osobnej interwencji.

Planowane prace techniczne obejmują działania utrzymaniowe konieczne do zapewnienia bezpieczeństwa, stabilności, aktualności i rozwoju infrastruktury. Mogą dotyczyć aktualizacji hostów wirtualizacji, firmware, systemów storage, urządzeń sieciowych, panelu klienta, systemów backupu, warstwy billingowej oraz mechanizmów ochrony DDoS.

FlexCloud stara się informować o planowanych pracach z odpowiednim wyprzedzeniem, wskazując przewidywany termin, zakres, możliwy wpływ na usługi i orientacyjny czas trwania. W przypadku prac pilnych, wynikających z podatności bezpieczeństwa, ryzyka utraty danych, awarii częściowej albo wymogów operatorów infrastruktury, termin powiadomienia może być krótszy.

Czas planowanych prac, o ile został prawidłowo zakomunikowany albo wynika z pilnej potrzeby bezpieczeństwa, nie jest traktowany jako naruszenie SLA. FlexCloud powinien jednak wykonywać prace w sposób ograniczający wpływ na klientów, a po zakończeniu monitorować usługi objęte zmianą.

SLA nie obejmuje zdarzeń wynikających z działania lub zaniechania klienta, w tym błędnej konfiguracji systemu, aplikacji, DNS, firewalli, certyfikatów SSL, kont pocztowych, skryptów, baz danych, zadań cron, integracji zewnętrznych, ustawień cache, limitów PHP, wtyczek WordPress albo reguł bezpieczeństwa tworzonych przez klienta.

SLA nie obejmuje braku dostępności spowodowanego brakiem płatności, zakończeniem okresu abonamentu, zawieszeniem usługi za naruszenie regulaminu, działaniami abuse, zgłoszeniem organu uprawnionego, próbą obejścia limitów, generowaniem szkodliwego ruchu, naruszeniem prawa albo odmową usunięcia nadużycia przez klienta.

Wyłączeniu podlegają także zdarzenia siły wyższej, awarie operatorów zewnętrznych, przerwy w globalnym routingu, awarie rejestrów domen, awarie operatorów płatności, niedostępność usług firm trzecich, ataki DDoS przekraczające rozsądne możliwości ochrony danego planu, a także działania konieczne do ochrony bezpieczeństwa infrastruktury i pozostałych klientów.

Zgłoszenie SLA należy złożyć przez panel klienta w kategorii technicznej lub reklamacyjnej. Jeżeli panel jest niedostępny z powodu awarii, klient powinien użyć alternatywnego kanału wskazanego na stronie kontaktowej. Zgłoszenie powinno być złożone możliwie szybko po zauważeniu problemu, ponieważ opóźnienie może utrudnić analizę logów i potwierdzenie incydentu.

Prawidłowe zgłoszenie powinno zawierać identyfikator usługi, adres IP lub domenę, datę i godzinę rozpoczęcia problemu, opis objawów, wyniki testów, komunikaty błędów, lokalizację testu, informację o ostatnich zmianach oraz oczekiwany sposób obsługi. Dla usług VPS i VDS warto dołączyć informację, czy serwer odpowiada na ping, czy działa SSH/RDP, czy konsola jest dostępna i czy problem dotyczy jednej aplikacji czy całej maszyny.

FlexCloud może poprosić o dodatkowe informacje, wykonanie testów albo zgodę na działania diagnostyczne. Brak współpracy klienta, brak danych identyfikujących usługę albo zgłoszenie ogólne bez czasu i objawów może wydłużyć obsługę i utrudnić zakwalifikowanie sprawy jako incydentu SLA.

Po otrzymaniu zgłoszenia FlexCloud klasyfikuje problem, sprawdza status infrastruktury, analizuje monitoring i ustala, czy problem leży po stronie usługodawcy, klienta czy podmiotu zewnętrznego. Priorytet otrzymują zgłoszenia dotyczące braku dostępności usług produkcyjnych, problemów sieciowych, awarii hostów oraz incydentów bezpieczeństwa.

Czas odpowiedzi supportu nie jest tym samym co czas naprawy. Czas naprawy zależy od rodzaju awarii, konieczności wymiany komponentów, migracji usługi, przywrócenia backupu, działań operatorów zewnętrznych albo dodatkowych informacji od klienta. W trakcie większych incydentów FlexCloud może publikować komunikaty zbiorcze zamiast odpowiadać indywidualnie na każde zgłoszenie w tej samej sprawie.

Jeżeli problem dotyczy aplikacji klienta, support może wskazać prawdopodobną przyczynę, logi lub rekomendacje, ale naprawa kodu, wtyczek, motywów, zapytań SQL, konfiguracji aplikacji i systemu pozostaje po stronie klienta, chyba że klient korzysta z odrębnej usługi administracyjnej.

Jeżeli w danym okresie rozliczeniowym dostępność usługi objętej SLA spadnie poniżej gwarantowanego poziomu z przyczyn leżących po stronie FlexCloud, klient może złożyć wniosek o rekompensatę. Rekompensata ma formę kredytu usługowego, rabatu na kolejny okres rozliczeniowy albo innej formy wskazanej przez FlexCloud, o ile przepisy prawa lub indywidualna umowa nie stanowią inaczej.

Przykładowy model rekompensat może przewidywać kredyt odpowiadający części miesięcznej opłaty za usługę: przy dostępności poniżej 99.9% do 99.0% - 5% miesięcznej opłaty, poniżej 99.0% do 98.0% - 10% miesięcznej opłaty, poniżej 98.0% - 20% miesięcznej opłaty. Rekompensata dotyczy wyłącznie usługi dotkniętej awarią i nie obejmuje usług dodatkowych, domen, płatności operatorów zewnętrznych ani utraconych korzyści.

Wniosek o rekompensatę powinien zostać złożony w terminie 14 dni od zakończenia okresu rozliczeniowego, którego dotyczy incydent, chyba że przepisy prawa wymagają dłuższego terminu. Wniosek powinien wskazywać usługę, daty, opis awarii i numer zgłoszenia. Brak zgłoszenia incydentu w czasie jego trwania może utrudnić przyznanie rekompensaty, jeśli brak jest danych potwierdzających niedostępność.

Backup i SLA są różnymi mechanizmami. SLA odnosi się do dostępności infrastruktury, a backup do możliwości odtworzenia danych. Restore backupu może być potrzebny po błędzie aplikacji, usunięciu plików, awarii logicznej albo nieudanej aktualizacji, ale sam czas restore nie zawsze oznacza naruszenie SLA, jeśli infrastruktura działa prawidłowo.

Kopie zapasowe wykonywane przez FlexCloud są realizowane zgodnie z opisem planu i regulaminem. Klient powinien utrzymywać własne kopie danych, jeśli prowadzi sklep internetowy, system rezerwacji, aplikację biznesową, system księgowy albo inne rozwiązanie, w którym utrata danych z ostatnich godzin może być istotna. Dla krytycznych zastosowań rekomendowana jest dodatkowa replikacja i testy odtwarzania.

SLA może być aktualizowane w przypadku zmian oferty, architektury infrastruktury, procedur bezpieczeństwa, wymagań operatorów zewnętrznych albo zmian prawnych. Aktualna wersja dokumentu jest publikowana na stronie FlexCloud. Dla usług zamówionych w ramach indywidualnej umowy zastosowanie mogą mieć warunki szczególne wskazane w tej umowie.

SLA nie ogranicza praw klienta wynikających z bezwzględnie obowiązujących przepisów prawa. W zakresie nieuregulowanym dokumentem zastosowanie ma regulamin świadczenia usług, polityka prywatności oraz opis konkretnego planu. Jeżeli klient potrzebuje wyższego poziomu dostępności niż standardowe SLA, powinien skontaktować się z FlexCloud przed zakupem w celu omówienia architektury wysokiej dostępności.