SLA w umowie SaaS. Dlaczego 99,9% dostępności może nie chronić klienta?

System nie działa przez 43 minuty. Klient nie może przyjmować zamówień, pracownicy przechodzą na proces ręczny, a support dostawcy odpowiada, że miesięczne SLA nie zostało naruszone.

Klient otwiera umowę. Widzi obietnicę 99,9% dostępności, ale nie znajduje odpowiedzi na kilka prostych pytań:

• od której chwili liczono niedostępność;
• czy awaria jednego modułu oznacza awarię całej usługi;
• dlaczego planowane prace wyłączono z pomiaru;
• czy liczą się dane klienta, czy tylko monitoring dostawcy;
• co właściwie przysługuje po naruszeniu SLA.

SLA w umowie SaaS ma sens dopiero wtedy, gdy procent można przełożyć na pomiar, sposób reakcji i konkretny skutek.

Czego dowiesz się z tego tekstu?

W skrócie

• 99,9% dostępności oznacza około 43 minuty i 12 sekund dopuszczalnej niedostępności w trzydziestodniowym miesiącu.
• Wynik zależy od tego, co umowa uznaje za awarię, skąd bierze dane i czego nie wlicza do pomiaru.
• Działający ekran logowania nie wystarczy, jeżeli użytkownik nie może wykonać podstawowej operacji.
• Service credit może sprawnie rozliczyć zwykły przestój, ale często jest znacznie niższy niż koszt awarii po stronie klienta.
• Przy systemie ważnym dla biznesu potrzebne są też zasady eskalacji, odtwarzania danych i wyjścia z umowy po powtarzających się awariach.

Czym jest SLA w umowie SaaS?

SLA, czyli Service Level Agreement, określa mierzalny poziom usługi oraz skutki jego niedotrzymania. Może być osobnym załącznikiem albo częścią głównej umowy. W SaaS najczęściej obejmuje dostępność, czas reakcji supportu, usuwanie awarii, kopie zapasowe, wydajność i odtwarzanie danych.

Sam procent dostępności jest tylko jednym elementem. W praktyce spotkasz też kilka podobnych skrótów:

• SLO to konkretny cel, na przykład 99,9% dostępności w miesiącu;
• KPI to wskaźnik używany do obserwowania jakości, nie zawsze połączony z odpowiedzialnością dostawcy;
• service credit to obniżka przyszłej opłaty lub kwota do wykorzystania przy kolejnym rozliczeniu;
• kara umowna to z góry ustalona kwota należna po określonym naruszeniu umowy.

Nazwy bywają używane różnie, dlatego nie wystarczy sprawdzić nagłówków. Trzeba zobaczyć, co dokładnie mierzymy i jaki skutek ma konkretny wynik.

99,9% dostępności: ile to minut?

W trzydziestodniowym miesiącu mamy 43 200 minut. Jeżeli dostawca obiecuje dostępność na poziomie 99,9%, dopuszczalna niedostępność wynosi 0,1% tego czasu, czyli 43 minuty i 12 sekund.

Dla porównania:

• 99% pozwala na 7 godzin i 12 minut niedostępności;
• 99,5% pozwala na 3 godziny i 36 minut;
• 99,9% pozwala na 43 minuty i 12 sekund;
• 99,95% pozwala na 21 minut i 36 sekund;
• 99,99% pozwala na 4 minuty i 19 sekund.

Obliczenie wygląda tak:

dostępność = (cały mierzony czas - niedostępność) / cały mierzony czas × 100%

Na papierze to proste. Umowa może jednak zmienić wynik, gdy nie liczy przerw krótszych niż minuta, wyłącza prace serwisowe, mierzy każdy region osobno albo pomija awarie usług zewnętrznych. Dwa SaaS-y oferujące 99,9% mogą więc zapewniać klientowi zupełnie inny poziom ochrony.

Co dokładnie powinno być dostępne?

Dostępność powinna odnosić się do funkcji, którą użytkownik ma wykonać. Sam fakt, że serwer odpowiada, nie oznacza jeszcze, że produkt działa. System może wyświetlać ekran logowania, a jednocześnie nie pozwalać zapisać zamówienia, wysłać dokumentu lub pobrać raportu.

SLA może mierzyć:

• cały produkt;
• panel użytkownika;
• API, czyli sposób komunikacji systemu z innymi aplikacjami;
• funkcje krytyczne wskazane w załączniku;
• poszczególne moduły;
• konkretny region lub środowisko;
• usługę dostępną dla określonej grupy użytkowników.

Nie każdy moduł musi mieć ten sam poziom. Logowanie, zapis zamówienia i dostęp do danych mogą wymagać najwyższej dostępności. Raportowanie lub eksport mogą mieć niższy poziom, a funkcja testowa może w ogóle nie być objęta SLA. Klient powinien jednak wiedzieć, do której grupy należy proces, od którego zależy jego sprzedaż lub praca zespołu.

SLA powinno mierzyć działanie procesu ważnego dla klienta, a nie najłatwiejszy do monitorowania fragment infrastruktury.

Kiedy zaczyna się niedostępność?

Początek awarii można liczyć od wykrycia przez monitoring, pierwszego zgłoszenia klienta albo chwili, którą później potwierdzają logi. Oparcie wyniku wyłącznie na zgłoszeniu do supportu jest ryzykowne, bo ticket może powstać długo po rozpoczęciu problemu.

Umowa powinna ustalić:

• źródła danych i częstotliwość pomiaru;
• minimalny czas awarii;
• sposób liczenia krótkich, powtarzających się przerw;
• strefę czasową i okres rozliczeniowy;
• moment zakończenia awarii;
• zasady rozwiązywania różnic między danymi klienta i dostawcy.

Dobrym rozwiązaniem jest połączenie automatycznego monitoringu dostawcy z możliwością wykazania przez klienta, że problem zaczął się wcześniej. Inaczej strona, która sama odpowiada za pomiar, sama rozstrzyga również spór o jego wynik.

Warunki dostawców infrastruktury dobrze pokazują, jak duże znaczenie ma definicja. AWS Compute SLA inaczej traktuje pojedynczą instancję, a inaczej usługę uruchomioną w kilku strefach dostępności. Google Compute Engine SLA również różnicuje poziomy dla jednej instancji, wielu stref i równoważenia ruchu. Klient SaaS kupuje jednak działanie aplikacji, nie samą łączność serwera. Nie ma sensu kopiować tych definicji bez przełożenia ich na produkt.

Czy wolny system nadal jest dostępny?

Usługa może odpowiadać, ale działać tak wolno, że użytkownik nie jest w stanie dokończyć zadania. Jeżeli wydajność ma znaczenie dla biznesu, warto mierzyć ją osobno. Można ustalić czas odpowiedzi API, czas wygenerowania raportu, dopuszczalny odsetek błędów albo czas synchronizacji danych.

Techniczne SLA często posługuje się oznaczeniami p95 lub p99. p95 oznacza, że 95% mierzonych odpowiedzi ma zmieścić się w ustalonym czasie. Pozostałe 5% może trwać dłużej. Taki wskaźnik jest zwykle bardziej użyteczny niż średnia, którą kilka bardzo szybkich odpowiedzi potrafi sztucznie poprawić.

W umowie trzeba jednak zapisać ten mechanizm zwykłym językiem. Osoba odpowiedzialna za biznes powinna umieć sprawdzić wynik bez zgadywania, co autor miał na myśli.

Jak traktować planowane prace serwisowe?

Planowane maintenance, czyli prace potrzebne do utrzymania i aktualizacji usługi, może być wyłączone z pomiaru. Taki wyjątek jest rozsądny, jeżeli klient zna zasady, dostaje wcześniejsze powiadomienie, a prace odbywają się w ustalonym oknie.

Klauzula powinna określać:

• maksymalną częstotliwość i długość prac;
• godziny, w których mogą się odbywać;
• termin i sposób powiadomienia;
• limit łącznego czasu wyłączonego z pomiaru;
• zasady pilnych prac bezpieczeństwa;
• obowiązek ograniczenia wpływu na klienta.

Nieograniczone wyłączenie wszystkich zapowiedzianych prac pozwala dostawcy obniżyć rzeczywistą dostępność bez naruszenia SLA. Z drugiej strony krytyczna poprawka bezpieczeństwa może wymagać działania bez standardowego wyprzedzenia. Umowa powinna uwzględniać oba scenariusze.

Które wyłączenia SLA są rozsądne?

Wyłączenia powinny dotyczyć zdarzeń, których dostawca rzeczywiście nie kontroluje, albo problemów wywołanych przez klienta. Katalog nie może być tak szeroki, żeby każda poważna awaria wypadała poza SLA.

Najczęściej wyłącza się:

• działanie klienta niezgodne z dokumentacją;
• infrastrukturę kontrolowaną wyłącznie przez klienta;
• wcześniej zapowiedziane prace serwisowe;
• siłę wyższą;
• zgodne z umową zawieszenie usługi;
• funkcje testowe;
• przekroczenie uzgodnionych limitów;
• awarię Internetu poza punktem, za który odpowiada dostawca.

Więcej uwagi wymaga awaria podwykonawcy. Dostawca SaaS może nie kontrolować chmury, ale zwykle sam wybrał architekturę i usługodawcę. Wyłączenie wszystkich problemów podmiotów zewnętrznych przerzuca na klienta ryzyko całego łańcucha, także wtedy, gdy przyczyną był brak rozsądnego zabezpieczenia po stronie SaaS-u.

W praktyce trzeba oddzielić awarię zupełnie niezależną od dostawcy od problemu, którego skutki mógł ograniczyć przez zapasową strefę, kopię danych lub plan odtworzenia.

Czym są service credits?

Service credit to obniżka przyszłej opłaty lub kredyt przyznawany po niespełnieniu uzgodnionego poziomu usługi. Ułatwia rozliczenie typowej niedostępności, bo klient nie musi za każdym razem wykazywać dokładnej wysokości szkody.

Przykładowy mechanizm może przewidywać:

• od 99,9% dostępności: brak kredytu;
• od 99,0% do mniej niż 99,9%: 10% miesięcznej opłaty;
• od 95,0% do mniej niż 99,0%: 25% miesięcznej opłaty;
• poniżej 95,0%: 50% miesięcznej opłaty.

Trzeba jeszcze wskazać, od jakiej opłaty liczymy procent. Kredyt od ceny jednego niedziałającego modułu może być wielokrotnie niższy niż ten sam procent liczony od całej miesięcznej subskrypcji.

Oficjalne warunki AWS i Google pokazują, że kredyt nie zawsze nalicza się sam. Google wymaga zgłoszenia w ciągu 60 dni i przekazania logów potwierdzających przestój. Kredyt jest rozliczany przy przyszłym korzystaniu z usługi i nie może przekroczyć opłaty za usługę objętą problemem. W indywidualnie negocjowanej umowie SaaS można przyjąć prostszy model, zwłaszcza gdy to dostawca ma pełny monitoring i pierwszy wie o naruszeniu SLA.

Czy service credit wystarczy klientowi?

Przy zwykłym, krótkim przestoju kredyt może być rozsądnym i szybkim sposobem rozliczenia. Nie powinien jednak automatycznie zamykać wszystkich roszczeń związanych z utratą danych, naruszeniem poufności, poważnym zaniedbaniem albo wielokrotnymi awariami.

Umowa może przewidywać:

• kredyt jako jedyny skutek zwykłej niedostępności;
• zaliczenie kredytu na poczet późniejszego odszkodowania;
• wybór między kredytem a dochodzeniem roszczeń;
• osobne kary za przekroczenie czasu reakcji;
• prawo wypowiedzenia po kilku poważnych awariach;
• wyjątki dla utraty danych, naruszenia bezpieczeństwa lub poufności.

Dla klienta najważniejsze bywa prawo do zakończenia współpracy, gdy dostawca regularnie nie spełnia SLA. Kolejny rabat nie naprawi systemu, któremu biznes przestał ufać.

SLA nie zastępuje supportu i planu awaryjnego

Dostępność mówi, jak długo usługa działała. Support i procedura incydentowa opisują, co strony zrobią podczas awarii: kto przyjmie zgłoszenie, kiedy rozpocznie pracę, jak często poda aktualizację i kto podejmie decyzję o eskalacji.

W umowie warto ustalić:

• klasy ważności zgłoszeń;
• czas pierwszej reakcji i rozpoczęcia prac;
• częstotliwość informacji o postępie;
• kanał eskalacji i wsparcie poza godzinami pracy;
• raport o przyczynie awarii;
• plan działań naprawczych;
• komunikację z użytkownikami.

Osobne znaczenie mają RTO i RPO. RTO określa, w jakim czasie system lub proces ma zostać odtworzony. RPO wskazuje, jak dużo najnowszych danych może zostać utraconych, na przykład z ostatnich 15 minut. Dostępność 99,9% nie odpowiada na pytanie, czy po awarii klient odzyska dane sprzed pięciu minut, czy sprzed doby.

Ten temat łączy się z Cyber Resilience Act i aktualizacjami bezpieczeństwa oraz z procesem reagowania na podatności publikowane jako CVE. Sam dobry wynik dostępności nie zastąpi aktualizacji ani obsługi incydentu.

Dlaczego SLA chmury nie przechodzi automatycznie na SaaS?

Dostawca SaaS nie powinien obiecywać klientowi poziomu wynikającego wyłącznie z liczby podanej przez dostawcę infrastruktury. Na dostępność całego produktu wpływają baza danych, sieć, własny kod, zewnętrzne API, system logowania i sposób wdrożenia.

Jeżeli proces zależy od kilku elementów, awaria każdego z nich może go zatrzymać. Dlatego przed wpisaniem procentu do umowy trzeba sprawdzić:

• pojedyncze punkty awarii;
• zapasowe instancje i strefy;
• kopie danych i proces odtwarzania;
• zewnętrzne API oraz system logowania;
• dostawcę płatności;
• monitoring;
• możliwość działania w trybie ograniczonym.

Umowy z podwykonawcami powinny dawać SaaS-owi dane i narzędzia potrzebne do wykonania zobowiązań wobec klienta. Nie zawsze uda się uzyskać identyczne SLA na każdym poziomie, ale różnica nie powinna być zaskoczeniem odkrytym dopiero po awarii.

Kazus modelowy: 99,9%, magazyn i 800 zł kredytu

Przyjmijmy realistyczny przykład, który nie opisuje konkretnego klienta. SaaS obsługuje zamówienia i pracę magazynu. Miesięczna opłata wynosi 8 000 zł. Umowa przewiduje:

• dostępność 99,9% w miesiącu;
• wyłączenie prac serwisowych i awarii dostawców zewnętrznych;
• pomiar wyłącznie przez monitoring SaaS-u;
• kredyt 10% miesięcznej opłaty po naruszeniu SLA;
• konieczność złożenia wniosku w ciągu siedmiu dni;
• service credit jako jedyny środek klienta.

Dochodzi do awarii bazy danych. System nie działa przez trzy godziny. Monitoring dostawcy odnotowuje dwie godziny i czterdzieści minut, bo przez pierwsze dwadzieścia minut serwer wyświetlał ekran logowania. Użytkownicy nie mogli jednak otworzyć żadnego zamówienia.

Dostawca chmury uznaje zdarzenie za własną awarię, więc SaaS powołuje się na wyłączenie dotyczące podmiotu zewnętrznego. Klient składa wniosek po dziewięciu dniach. Dostawca odmawia kredytu z powodu przekroczenia terminu.

Nawet gdyby kredyt został przyznany, wyniósłby 800 zł. Koszt pracy ręcznej, opóźnień i dodatkowych wysyłek może być znacznie wyższy.

Lepszy mechanizm obejmowałby:

• dostępność kluczowego procesu, nie tylko ekranu logowania;
• możliwość przedstawienia logów klienta;
• ograniczone wyłączenie awarii podwykonawców;
• automatyczne naliczenie kredytu;
• raport o przyczynie i plan naprawczy;
• prawo wypowiedzenia po kilku poważnych awariach;
• osobne zasady dla utraty danych i poważnych zaniedbań;
• awaryjny sposób pracy magazynu.

Checklista SLA w umowie SaaS

Przed podpisaniem sprawdźcie:

• jaka usługa i które funkcje są objęte SLA;
• jaki poziom dostępności i okres rozliczeniowy obowiązują;
• co oznacza niedostępność;
• czy obniżona wydajność jest mierzona osobno;
• kto prowadzi monitoring i czy klient może przedstawić własne dane;
• kiedy zaczyna się i kończy awaria;
• czy krótkie przerwy są sumowane;
• które prace serwisowe są wyłączone i jak trzeba je zapowiedzieć;
• jak traktowane są awarie podwykonawców;
• jaki service credit przysługuje i od jakiej opłaty jest liczony;
• czy kredyt nalicza się automatycznie;
• czy jest jedynym środkiem ochrony;
• kiedy klient może wypowiedzieć umowę;
• jak SLA łączy się z supportem, RTO i RPO;
• czy zobowiązania odpowiadają rzeczywistej architekturze produktu.

Procent musi dać się przełożyć na działanie

99,9% wygląda konkretnie, dopóki strony nie próbują ustalić, co właściwie mierzą. Dobre SLA pozwala odtworzyć przebieg awarii, policzyć wynik i zastosować znany wcześniej skutek.

Kredyt usługowy może sprawnie rozliczyć typową niedostępność. Przy systemie ważnym dla biznesu potrzebne są również rozsądna architektura, komunikacja podczas awarii i możliwość wyjścia z usługi, która regularnie zawodzi.

Jeżeli przygotowujesz albo negocjujesz SLA, umowę maintenance lub kontrakt na ważny system, zobacz wsparcie prawne dla produktów SaaS i pomoc przy umowach IT. Lis.Legal wspiera firmy technologiczne ze Szczecina i zdalnie w całej Polsce.

Umów 30-minutową konsultację