en

Wciąż jeszcze nie wszystkie firmy wdrażając system IT, decydują się na podpisanie umowy SLA. Managerowie argumentują to na przykład koniecznością ochrony budżetu przed zbędnymi wydatkami. Tymczasem to właśnie brak umowy SLA generuje nieprzewidziane i często wielokrotnie wyższe koszty związane z utratą ciągłości pracy systemu i brakiem procedur wyjścia z takiej sytuacji. Chodzi tu nie tylko o straty finansowe ale też nierzadko o trudne do odrobienia straty takie jak np. utrata wiarygodności u klientów.

1. Co to jest SLA

W praktyce biznesowej przedmiotem umowy wsparcia typu Service Level Agreement (SLA) jest świadczenie usług, których celem jest zapewnienie ciągłości istotnych procesów biznesowych. Procesy te najczęściej realizowane są poprzez infrastrukturę informatyczną, w której skład wchodzą aplikacje oraz urządzenia.

Usługi wynikające z podpisanej umowy SLA to między innymi:

  • Zapewnienie możliwości zgłaszania incydentów (w tym błędów) poprzez system rejestracji zgłoszeń,
  • Gwarancja dostępności specjalistów gotowych i będących w stanie rozwiązać zgłoszone incydenty w określonym czasie,
  • Zapewnienie dostępności telefonicznej wsparcia technicznego (hotline) dla aplikacji, udzielanie konsultacji z zakresu eksploatacji systemu,
  • Monitorowanie systemu (mierzenie dostępności oraz wydajności, umożliwia to wykrywanie spadków wydajności zanim odczuje to użytkownik).

Parametry umowy SLA zwykle określają wymagane czasy reakcji (po jakim maksymalnie czasie specjaliści rozpoczną pracę nad incydentem), czasy rozwiązania incydentów (np. przywrócenia dostępności aplikacji) oraz wysokość kar umownych za niedotrzymanie tych parametrów.

2. Korzyści

Utrzymanie ciągłości działania procesu

Kiedy przydarzy się awaria systemu, tj. incydent dotyczący błędu lub problem z wydajnością systemu, dostawca przywróci ciągłości działania aplikacji w czasie, który zastrzeżono w SLA. W praktyce rozróżniane są dwa czasy:

  • Czas reakcji – rozumiany jako okres od zgłoszenia błędu do potwierdzenia zarejestrowania w systemie rejestracji zgłoszeń ;
  • Czas naprawy – rozumiany jako okres od zgłoszenia błędu do przywrócenia ciągłości działania procesu, wyłączając łączny czas zawieszeń spowodowanych, np. oczekiwaniem Service Desk na odpowiedź użytkownika na zadane pytanie.

Dostawca utrzymuje aktualną wiedzę na temat systemu, aktualizuje dokumentację, tworzy mechanizmy testujące.

Często można spotkać się z opinią, że skoro aplikacja została wdrożona X lat temu i przez ten czas działała stabilnie, to nie trzeba wykupywać SLA. Dzięki temu niektórzy managerowie chcą zaoszczędzić na opłatach stałych, a zaoszczędzone w ten sposób pieniądze przeznaczyć na rozwój systemu lub inny cel.

Powyższa decyzja może spowodować dramatyczne konsekwencje, ponieważ stabilną pracę systemu informatycznego mogą zakłócić czynniki niezwiązane bezpośrednio z kodem samej aplikacji i doprowadzić do awarii nawet w sytuacji, gdy sama aplikacja nie zawiera błędów. Na przykład, przez 2 lata system orderingowy pracował bez zarzutu, jednak aplikacja przestaje działać stabilnie, kiedy liczba użytkowników korzystających jednocześnie z systemu istotnie wzrosła w związku z np. rozwojem firmy lub prowadzonymi działaniami marketingowymi. Innym przykładem może być awaria systemu spowodowana przez aktualizację oprogramowania serwerowego albo innego elementu infrastruktury, z którym system nie jest kompatybilny. Po wygaśnięciu gwarancji, dostawca nie jest zobowiązany utrzymywać niezbędnej i aktualnej wiedzy na temat systemu, co wpływa na wydłużenie czasu naprawy oraz wzrost kosztów. W skrajnym przypadku może okazać się, że dostawca nie utrzymuje już kompetencji w danej technologii i nie jest w stanie podjąć się modyfikacji.

Umowa SLA wymusza na dostawcy utrzymanie wiedzy o wdrożonym systemie, jego budowie i funkcjach.

Dzięki temu można mieć pewność, że dostawca będzie w stanie sprawnie reagować na różne błędy oraz że przydzielono do projektu zespół wsparcia, a w razie awarii zespół ten będzie miał czas, żeby się zająć naszym problemem i zrobi to w krótkim czasie. W takim przypadku dostawca musi stale aktualizować dokumentację systemu, zapewnić odpowiednie kompetencje w zespole itd. Mając w perspektywie długofalową współpracę, dostawcy często opłaca się też stworzyć dodatkowe mechanizmy testujące i ostrzegające o zagrożeniu stabilności pracy aplikacji. Te aspekty mają znaczenie nie tylko dla prawidłowej realizacji SLA lecz także wpływają na obniżenie kosztów rozwoju systemu oraz na jego jakość.

3. Istotne parametry umowy SLA

Wśród wielu pytań, na które trzeba sobie odpowiedzieć przed przystąpieniem do negocjacji umowy SLA znajdują się poniższe dotyczące parametrów:

  • Jakie procesy są kluczowe dla naszego przedsiębiorstwa i w jakich godzinach musi zostać zapewniona ciągłość ich działania,
  • Jakie kategorie błędów dopuszczamy i jak je opisać,
  • Jakich godzin obowiązywania wsparcia oraz czasów reakcji i naprawy będziemy oczekiwać,
  • Jak mierzyć efektywność usługi,
  • Jakie są procedury dotyczące komunikacji oraz ścieżki eskalacji.

W praktyce odpowiedź na ww. pytania przybiera formę tabeli, takiej jak poniższa.

Przykład 1:

Kategoria błędu

Czas reakcji

Czas naprawy

Godziny obowiązywania

Błąd krytyczny

(doprecyzowanie co oznacza bład krytyczny: np. serwis niedostępny, nie można złożyć zamówiienia)

0,5 h

1 h

godz. 9-17, 365 dni w roku

Błąd niekrytyczny

(określenie obszaru funkcjonalności)

2 h

4 h

Pn - pt w godz. 9-17 w dni robocze


Przykład 2:

Kategoria błędu

Czas reakcji

Czas naprawy

Godziny obowiązywania

Błąd krytyczny

0,5 h

1 h

Pn - pt w godz. 9-17 w dni robocze

Błąd ważny

2 h

4 h

Pn - pt w godz. 9-17 w dni robocze

Błąd normalny

8 h

16 h

Pn - pt w godz. 9-17 w dni robocze


Należy pamiętać, aby w parametrach umowy SLA określić w jakie dni i w jakich godzinach obowiązuje wsparcie. Powinny one odzwierciedlać statystyki wykorzystywania systemu przez użytkowników i minimalizować potencjalne straty w przypadku niedostępności systemu. Jednocześnie należy zdawać sobie sprawę z tego, że im bardziej rygorystyczne wymagania, tym wyższa cena SLA. Warto więc dobrać poziom usługi SLA wyznaczając kompromis pomiędzy kosztami SLA a poziomem rzeczywistych wymagań biznesu.

Tymczasowe rozwiązanie (workaround)

Warto zdawać sobie sprawę z różnicy pomiędzy tymczasowym rozwiązaniem (workaround), a całkowitym wyeliminowanie przyczyny błędu. W skrócie workaround oznacza przywrócenie działania procesu biznesowego, jednak nie musi oznaczać całkowitego wyeliminowania przyczyny błędu. Z perspektywy biznesu najistotniejsze jest, aby można było pracować w systemie, dlatego trzeba negocjować jak najkrótszy czas, w jakim dostawca zobowiązuje się dostarczyć przynajmniej tymczasowe rozwiązanie problemu. Całkowite wyeliminowanie przyczyny błędu może się wiązać z koniecznością przygotowania, przetestowania i wdrożenia nowej wersji systemu na co potrzeba więcej czasu niż kilka godzin, podczas których można dostarczyć workaround. W zależności od umowy zapisane w SLA, czasy dla workaroundów mogą być krótsze i dłuższe dla całkowitego wyeliminowania przyczyny błędu. Wdrażanie nowych wersji powinno odbywać się na zasadach osobnych zleceń, których umowa SLA nie pokrywa (w przeciwnym wypadku koszt umowy SLA będzie nieporównanie wyższy).

Pomiar dostępności aplikacji

Bardzo ważnym parametrem jest poziom dostępności aplikacji wyrażony w procentach liczony w określonych okresach (zwykle miesiącach). Dobrze jest, gdy dostawca aktywnie monitoruje dostępność aplikacji przy użyciu specjalizowanego systemu, np. NAGIOS i udostępnia takie wyniki. W przypadku wykrycia problemów z dostępnością aplikacji, systemy, takie jak NAGIOS potrafią wysyłać SMSy oraz emaile do wskazanych osób. Systemy do pomiaru dostępności aplikacji zapisują wszystkie informacje dotyczące dostępności i umożliwiają generowanie raportów cyklicznych. Monitorowanie jest możliwe dzięki uruchomionym na serwerze automatycznym procesom, które wykonują regularnie w określonych odstępach czasu akcje sprawdzające dostępność aplikacji. Należy upewnić się, że monitorowanie jest uruchomione na serwerze w innym, niezależnym data center, tak aby była pewność, że ma on dostęp do sieci Internet i funkcjonuje prawidłowo. Często mechanizmy monitorujące same też są sprawdzane. Takie systemy, jak NAGIOS mogą badać również czasy odpowiedzi na poszczególne żądania, np. czas po jakim jest wyświetlana strona nowego zamówienia. Więcej na temat NAGIOS piszemy w innym naszym artykule: Pomiar dostępności aplikacji. Monitorowanie działania pozwala na obiektywną ocenę i zmierzenie efektywności usługi SLA.


Rraport dostępności usługi w ciągu roku.

Komunikacja oraz linie wsparcia

Kluczowym elementem każdej umowy SLA jest opis sposobu komunikacji pomiędzy dostawcą usługi a klientem. Należy określić kto może zgłaszać problemy oraz w jaki sposób. Najczęściej wyróżnia się 2 linie wsparcia przy czym:

  • pierwsza linia wsparcia - dotyczy rozwiązywania problemów bezpośrednich użytkowników systemu. Są to najczęściej drobne problemy z zakresu helpdesku. Formą komunikacji najczęściej jest telefon, chat, mail.
  • druga linia wsparcia - dotyczy rozwiązywania problemów incydentów, których pierwsza linia wsparcia nie jest w stanie rozwiązać. W takiej sytuacji pracownicy supportu w 1 linii przekazują zagadnienie do 2 linii w określonym obszarze (np. do dostawcy oprogrowania).

W obu przypadkach użycie systemu do śledzenia zgłoszeń jest wysoce wskazane w celu pomiaru wskaźników określających rzeczywisty poziom realizowanego SLA. W przypadku realizacji wsparcia przez zewnętrzną firmę system do sledzenia zgłoszeń będzie wręcz konieczny aby zabezpieczyć interesy obu stron umowy.

Eskalacja

W umowach SLA eskalacja jest najczęściej rozumiana jako procedura komunikacyjna na wypadek problemów w przebiegu obsługi incydentu (np. oczekiwanych lub zaistniałych opóźnieniach w dostarczeniu rozwiązania lub zarządzaniu incydentami o charakterze krytycznym). Procedury eskalacji często zakładają włączenie w komunikację pracowników wyższego szczebla celem rozwiązania istniejącego problemu.

Najczęstsze problemy podczas negocjowania umów SLA

  • Biznes oczekuje nieadekwatnych do rzeczywistych potrzeb poziomów dostępności i wsparcia systemu. Zdarza się, że wymagania biznesowe podczas rozmów o umowie SLA dla niekluczowego systemu IT określają poziom dostępności systemu na poziomie 99,999% w skali miesiąca i obowiązywania pełnego wsparcia 24h/365 dni w roku z 1 godzinnym czasem naprawy wszelkich błędów. Rzeczywiście istnieją systemy, które wymagają najwyższych poziomów dostępu i bezawaryjności (np. systemy core-bankingowe czy obsługi telefonii komórkowej). Jednak wiele rozwiązań biznesowych funkcjonuje w określonych godzinach i poza nimi ich wykorzystanie jest minimalne. Co za tym idzie brak dostępności w tych godzinach nie oznacza istotnych strat. W takich sytuacjach trudno uzasadniać wymagania najwyższych 24 godzinnych poziomów wsparcia.
  • Biznes oczekuje wyceny umowy wsparcia SLA nie określając parametrów wsparcia. Wycena usługi wsparcia SLA bezpośrednio zależy od tych parametrów, zatem właściciel biznesowy systemu powinien określić przynajmniej przybliżone oczekiwania względem poziomu wsparcia. Jeżeli jest z tym problem wówczas można poprosić dostawcę o wycenę dla kilku wariantów poziomu wsparcia.

4. Podsumowanie

Planując budżet projektu warto zarezerwować środki na usługę wsparcia systemu, gdyż w praktyce jest to jedyny skuteczny sposób, żeby zagwarantować dostępność systemu na wymaganym poziomie. Oszczędności tego typu są pozorne i w najgorszym scenariuszu mogą spowodować utratę zysków i zaufanie klientów. Warto też wspomnieć, że istnieje wiele usystematyzowanych zbiorów dobrych praktyk związanych z realizacją usług wsparcia takich jak ITIL. Warto aby były one znane i stosowane zarówno przez dostawcę jak i odbiorcę.

 

Więcej: Pomiar dostępności aplikacjiRozproszone testy wydajnościowe, Pomiar jakości kodu

Autor:  3e Software House

RODO

Wyrażam zgodę, aby 3e sp. jawna zbierała, katalogowała, analizowała i podejmowała automatyczne decyzje o adresach internetowych połaczonych z urządzeniem, którego używam a także informacji o samym urządzeniu, w tym jego typie, wersji zainstalowanego oprogramowania w celu obserwacji moich aktywności w internecie (stworzenia profilu użytkownika). Automatyczne podejmowanie decyzji nie dotyczy danych wrażliwych. Zgoda pozostaje w mocy tak długo, jak długo istotne pozostają dane, dla których została wyrażona, lub do czasu, gdy któraś ze Stron zgodę wycofa. Cofnięcie zgody będzie skutkować usunięciem danych.