SLAService Level Agreement – umowa określająca szczegółowo gwarancję jakości świadczonych usług najczęściej pojawia się w przypadku zawierania umów na szeroko pojęte usługi hostingowe. Niemniej jednak można przyjąć, że ogólnie umowa taka określa warunki dostępności dowolnego systemu, reagowania na sytuacje awaryjne, czy wreszcie określa wysokość odszkodowania za czas, kiedy system jest niedostępny.

Zakres usług świadczonych przez dostawcę w ramach takiej umowy powinien obejmować:

  • udostępnienie procedur i narzędzi do zgłaszania wszelkich nieprawidłowości w działaniu systemu,
  • zapewnienie pomocy technicznej ze strony konsultanta,
  • dostępność administratorów systemu reagujących na zgłoszenia w czasie określonym przez umowę,
  • pełny monitoring systemu i reakcję na wykryte incydenty, mogące wpłynąć na dostępność systemu.

Dostępność systemu

Jednym z parametrów zdefiniowanych w umowie, który pojawia się najczęściej, gdy mówi się o specyfikacji SLA jest procentowe określenie czasu, w którym dostawca zobowiązuje się, że system będzie dostępny. W przypadku np. usług hostingowych pojawiają się tu liczby w zakresie 99% nawet do 99,999%. Definiowane jest również w jakiej jednostce czasu (miesiąc, rok) deklarowana dostępność jest zapewniana. W przypadku dłuższego okresu czasu, np. roku warto brać pod uwagę, że wartość procentowa jest średnią z tego okresu. W poniższej tabeli przedstawione zostało przełożenie wartości procentowych na czas jaki obejmują, dla różnych jednostek czasu.

 przerwa w działaniu  99% 99.9%  99.99% 
 dziennie 14 m 24.0s   1 m 26.4s 8.6s 
 tygodniowo 1h 40 m 48.0s  10 m 4.8s  1 m 0.5s 
 miesięcznie 7h 18 m 17.5s  43 m 49.7s  4 m 23.0s 
 rocznie  3d 15h 39 m 29.5s 8h 45 m 57.0s  52 m 35.7s 

Wynika z tego jednoznacznie, że nawet przy wartościach procentowych powyżej 99% możemy mieć do czynienia z przerwami w działaniu systemu, które nie muszą skutkować podjęciem kroków odszkodowawczych względem dostawcy. Mieszczą się w przedziale „niedostępności” określonym w umowie.

Istotne jest zwrócenie uwagi na zapisy umowy definiujące jakie przerwy w działaniu, nie będą wpływały na zmniejszenie czasu, w którym dostawca deklaruje dostępność systemu. Można tu wymienić kilka takich przykładowych wykluczeń, takich jak:

  • awarie, które wystąpiły w wyniku działania siły wyższej,
  • planowane place konserwacyjne (pod warunkiem powiadomienia odbiorcy usługi z wyprzedzeniem),
  • awarie urządzeń, nie będących częścią sieci dostawcy,
  • ataki DDoS,
  • awarie elementów systemu odbiorcy, które nie zostały dostarczone przez dostawcę systemu,
  • błędy wynikające ze świadomego działania odbiorcy.

Długość powyższej listy i dokładne zapisy mogą być różne. Jednak każdy dostawca zabezpiecza się w podobny sposób przed odpowiedzialnością za wystąpienie awarii, którym nie mógł zapobiec.

Reagowanie na sytuacje krytyczne

Można by przyjąć, że właściwie każde wystąpienie błędów w działaniu systemu jest sytuacją krytyczną. W jednym przypadku efektem jest jedynie generowanie pewnych ostrzeżeń, czy błędów, w innym całkowita niedostępność systemu. Umowa powinna zatem kategoryzować błędy, określać ich charakter – na jakiej podstawie dany błąd jest przypisywany do danej kategorii, oraz czas reakcji na określone kategorie błędów. Często określane są również godziny i czas reakcji w tych godzinach. Poniższa tabela stanowi przykład takiego zapisu w umowie.

kategoria błędu czas reakcji czas naprawy godziny obowiązywania
krytyczny 0,5 h 1 h pn – pt: 7.00-19.00 (dni robocze)
ważny 2 h 4 h pn – pt: 7.00-19.00 (dni robocze)
normalny 8 h 16 h pn – pt: 7.00-19.00 (dni robocze)

Warto zwrócić uwagę na fakt, że w powyższym przykładzie, nie zostały podane czasy reakcji poza wymienionymi godzinami. Firma wykorzystująca swój system do świadczenia usług w skali globalnej, powinna szczególnie zwrócić na to uwagę. Zabezpieczona musi być bowiem sytuacja awaryjna, która wydarzy się poza (przybliżonymi) godzinami pracy np. w Polsce, a w innej części świata jest środek dnia. W przypadku np. sklepów on-line jest to sytuacja łatwa do wyobrażenia.

Zgłaszanie błędów

Dostawca usługi powinien jednocześnie zapewnić odpowiedni sposób zgłaszania wszelkiego rodzaju nieprawidłowości w działaniu systemu. Linia wsparcia powinna być szczegółowo opisana w umowie. Rejestracja zgłoszeń jednej strony powinna zapewnić bezproblemową komunikację, z drugiej stanowić swoisty element monitoringu odpowiedniego wykonania zapisów umowy, odnośnie chociażby czasu reakcji na zgłoszenia.Najczęściej dostawca zapewnia odpowiedni helpdesk online – odpowiednią aplikację służącą do obsługi zgłoszeń. Zgłoszenia są odpowiednio kategoryzowane i realizowane zgodnie z zapisami umowy. Drugim stosowanym rozwiązaniem jest obsługa telefoniczna odbiorcy usługi. Tutaj realizowane jest to różnie: usługa może być dostępna jedynie dla zgłoszeń awarii i błędów krytycznych, zgłoszenia są realizowane poza standardowymi godzinami pracy helpdesku. Wszystkie te kwestie powinny być doprecyzowane w umowie.

Wymieniłem tutaj jedynie kilka elementów mogących stanowić przedmiot umowy określającej gwarancję jakości świadczenia usług SLA. Wybierając dostawcę usługi warto zaznajomić się z jej zapisami i wybrać takiego, który najbardziej nam odpowiada. Znajomość dokładnych zapisów uchroni nas przed niespodziankami w przypadku, gdy dojdzie do sytuacji spornych dotyczących np. postepowania odszkodowaczego. Najczęściej treść umów jest dostosowywana do świadczonych przez dostawcę usług, może się jednak różnić pomiędzy poszczególnymi oferowanymi pakietami. Oczywiście uruchamiając bardzo wymagający system zawsze warto się zastanowić nad negocjowaniem niektórych punktów, może to jednak skutkować odpowiednio wysoką opłatą za utrzymanie usługi.