1.Definicja dostępności
- Usługa jest dostępna, gdy użytkownik może zalogować się do aplikacji swojej organizacji i wykonać podstawowe operacje (otworzyć listę zamówień, zapisać zmianę), a API odpowiada na żądania uwierzytelnione poprawnym kluczem. Niedostępność to okres, w którym warunek ten nie jest spełniony dla całej organizacji klienta z przyczyn leżących po stronie usługi.
- Dostępność miesięczną liczymy jako: (liczba minut w miesiącu kalendarzowym minus minuty niedostępności niepodlegające wyłączeniu) podzielona przez liczbę minut w miesiącu, w procentach. Pomiar opiera się na naszym monitoringu (testy zdrowia usług co 15 sekund, logi) oraz na zgłoszeniach klienta; w razie rozbieżności rozstrzygają logi serwera.
- Niedostępność liczy się od chwili jej wykrycia przez monitoring albo zgłoszenia przez klienta (wcześniejsza z nich) do chwili przywrócenia usługi.
2.Poziom dostępności
- Referencyjny poziom dostępności w umowie Enterprise: 99,5% w miesiącu kalendarzowym, co odpowiada łącznie około 3 godzinom 40 minutom niedostępności w miesiącu. Wartość jest zachowawcza, bo odzwierciedla architekturę usługi na jednym serwerze; wyższy poziom wymaga redundancji infrastruktury i jest wyceniany osobno.
- Poziom obowiązujący klienta, sposób jego pomiaru i ewentualne odstępstwa od definicji z sekcji 1 są wpisane w umowie Enterprise.
3.Wyłączenia
- Do niedostępności nie wlicza się:
- planowanych prac serwisowych w oknie z sekcji 4, ogłoszonych zgodnie z nią,
- niedostępności lub błędów systemów zewnętrznych (marketplace, przewoźnicy, KSeF, systemy ERP, operatorzy płatności) i wynikającego z nich niedziałania integracji (§ 11 Regulaminu),
- przyczyn leżących po stronie klienta: konfiguracji, automatyzacji, przekroczenia uzgodnionych limitów API, blokad sieciowych, awarii łącza klienta,
- zawieszenia konta zgodnie z Regulaminem (zaległość, naruszenie, bezpieczeństwo),
- siły wyższej (§ 30 Regulaminu), w tym rozległych ataków DDoS i awarii operatora centrum danych niewynikających z naszego zaniedbania,
- niedostępności pojedynczych funkcji lub degradacji wydajności, które nie uniemożliwiają pracy organizacji jako całości (są obsługiwane jako zgłoszenia P2/P3, nie jako niedostępność),
- okresu, w którym klient nie współpracował przy usuwaniu awarii, jeżeli jego udział był niezbędny.
4.Planowane prace serwisowe
- Prace powodujące niedostępność planujemy w oknie serwisowym: dni powszednie 22:00-6:00 czasu polskiego albo weekendy, łącznie nie więcej niż 8 godzin w miesiącu (wartość referencyjna). Ogłaszamy je pocztą elektroniczną do administratorów konta i komunikatem w aplikacji co najmniej 48 godzin wcześniej, podając zakres i przewidywany czas.
- Prace pilne, wymagane przez bezpieczeństwo (np. łatka krytycznej podatności), mogą odbyć się poza oknem i z krótszym wyprzedzeniem; ich czas wlicza się do niedostępności, jeżeli przekroczy 30 minut.
- Zwykłe wdrożenia aplikacji odbywają się bez przerwy w dostępności i nie są ogłaszane.
5.Priorytety zgłoszeń
- Zgłoszenia klasyfikujemy według wpływu na pracę organizacji:
Priorytet Definicja Przykłady P1 - krytyczny Cała organizacja nie może pracować albo istnieje ryzyko utraty lub wycieku danych nie działa logowanie dla wszystkich użytkowników; zamówienia nie są pobierane z żadnego kanału; podejrzenie naruszenia bezpieczeństwa P2 - wysoki Kluczowa funkcja nie działa lub działa błędnie i nie ma obejścia, ale organizacja może częściowo pracować nie da się nadać przesyłek u jednego przewoźnika; faktury nie trafiają do KSeF; jedna integracja przestała synchronizować P3 - normalny Błąd z obejściem, pytanie o działanie funkcji, prośba o zmianę źle wyświetlony raport; pytanie o konfigurację reguły; propozycja usprawnienia - Priorytet nadaje zgłaszający, a my go potwierdzamy albo korygujemy z uzasadnieniem w pierwszej odpowiedzi. Zgłoszenie P1 powinno być wysłane dedykowanym kanałem wskazanym w umowie (np. adres e-mail z automatycznym alarmem), żeby nie czekało w zwykłej kolejce.
6.Czasy reakcji i rozpoczęcia prac
- Wartości referencyjne; czas reakcji to czas do pierwszej merytorycznej odpowiedzi osoby zajmującej się zgłoszeniem, czas rozpoczęcia prac to czas do podjęcia działań naprawczych. Godziny robocze: dni powszednie 9:00-17:00 czasu polskiego.
Priorytet Czas reakcji Rozpoczęcie prac Informowanie o postępie P1 1 godzina w godzinach roboczych; 4 godziny poza nimi (wariant 24/7 wyceniany osobno) niezwłocznie po reakcji, prace ciągłe do przywrócenia usługi co 2 godziny do przywrócenia usługi, następnie raport z przyczyn w 5 dni roboczych P2 4 godziny robocze następny dzień roboczy co dzień roboczy do rozwiązania lub obejścia P3 2 dni robocze według planu prac, z podaniem przewidywanego terminu przy zmianie statusu zgłoszenia - Czas rozwiązania zależy od przyczyny (błąd u nas, u dostawcy zewnętrznego, w konfiguracji klienta) i nie jest gwarantowany; gwarantujemy reakcję, rozpoczęcie prac i informowanie. Dla P1 celem jest przywrócenie usługi (także przez obejście lub cofnięcie wdrożenia) w ciągu 4 godzin od rozpoczęcia prac.
7.Rekompensaty (service credits)
- Jeżeli dostępność w miesiącu kalendarzowym spadnie poniżej poziomu z umowy, klientowi przysługuje rekompensata w postaci obniżki opłaty za kolejny miesiąc. Wartości referencyjne dla poziomu 99,5%:
Dostępność w miesiącu Rekompensata (procent miesięcznej opłaty) poniżej 99,5%, nie mniej niż 99,0% 10% poniżej 99,0%, nie mniej niż 98,0% 25% poniżej 98,0% 50% - Rekompensata jest jedynym roszczeniem klienta z tytułu niedotrzymania poziomu dostępności, z zastrzeżeniem prawa do rozwiązania umowy w razie niedotrzymania SLA w trzech kolejnych miesiącach. Łączna rekompensata za miesiąc nie przekracza 50% miesięcznej opłaty i nie jest wypłacana w gotówce; przy umowie rocznej jest zaliczana na poczet kolejnego okresu.
- Rekompensatę klient zgłasza na kontakt@berlinetta.pl w ciągu 30 dni od końca miesiąca, którego dotyczy, wskazując okresy niedostępności. Odpowiadamy w 14 dni z wyliczeniem na podstawie logów. Niedotrzymanie czasów reakcji z sekcji 6 dla zgłoszeń P1 może być objęte odrębną rekompensatą wpisaną w umowie.
8.Maksymalna odpowiedzialność
- Rekompensaty nie zmieniają ograniczeń odpowiedzialności z § 29 Regulaminu, chyba że umowa Enterprise ustala inny limit (np. wyższą wielokrotność opłat). Umowa Enterprise może też przewidywać odrębny limit dla naruszeń ochrony danych.
9.Informowanie o stanie usługi
- O awariach dotyczących ogółu klientów i o planowanych pracach informujemy pocztą elektroniczną administratorów konta oraz komunikatem w aplikacji. Klient Enterprise może wskazać dodatkowe adresy i kanał (np. Telegram) do alarmów o niedostępności.
- Publiczna strona statusu jest w planie; do czasu jej uruchomienia kanałem informacji są komunikaty opisane wyżej. Nie obiecujemy w SLA narzędzi, których jeszcze nie ma.
10.Uzgodnienie SLA
- Poziom dostępności, czasy reakcji, wariant wsparcia (godziny robocze / rozszerzone / 24/7), rekompensaty i limit odpowiedzialności ustalamy w umowie Enterprise. Kontakt: kontakt@berlinetta.pl. Ramy umowy opisują Warunki Enterprise.
Usługodawca
ZELCODE LABS KRYSTIAN KAKITEK
NIP 6252509025, REGON 545716021
ul. Mielecka 12/18, 41-219 Sosnowiec, Polska
Pytania do tego dokumentu przyjmujemy pod adresem kontakt@berlinetta.pl.