Jednak nie wszystkie firmy decydują się na podpisanie umowy SLA przy wdrażaniu systemu informatycznego. Menedżerowie argumentują to m.in. koniecznością ochrony budżetu przed niepotrzebnymi wydatkami. Jednak to właśnie brak SLA generuje nieprzewidziane i często znacznie wyższe koszty związane z utratą ciągłości działania systemu i brakiem procedur rozwiązania.
Nie chodzi tu tylko o straty finansowe, ale także czasami trudne do odrobienia straty, takie jak utrata wiarygodności w oczach klientów.

1. Czym jest SLA
W praktyce biznesowej przedmiotem umowy SLA (Service Level Agreement) jest świadczenie usług mających na celu zapewnienie ciągłości istotnych procesów biznesowych. Procesy te realizowane są głównie przez infrastrukturę IT, na którą składają się aplikacje i urządzenia.

Usługi świadczone w ramach zawartej umowy SLA obejmują:

• Zapewnienie możliwości zgłaszania incydentów (w tym błędów) poprzez system rejestracji zgłoszeń
• Gwarantowana dostępność specjalistów, którzy są gotowi i zdolni do rozwiązania zgłoszonych incydentów w określonym czasie
• Zapewnienie dostępności telefonicznego (hotline) wsparcia technicznego dla aplikacji, udzielanie konsultacji w zakresie obsługi systemu
• Monitorowanie systemu (pomiar dostępności i wydajności, pozwalający na wykrycie spadków wydajności zanim zauważą je użytkownicy)

Parametry SLA określają zazwyczaj wymagane czasy reakcji (maksymalny czas, po którym specjaliści rozpoczynają pracę nad incydentem), czasy rozwiązania incydentu (np. przywrócenie dostępności aplikacji) oraz kary umowne za niedotrzymanie tych parametrów.

2. Korzyści

Utrzymanie ciągłości procesu

W przypadku awarii systemu, tj. wystąpienia incydentu dotyczącego błędu lub problemu z wydajnością systemu, dostawca przywróci ciągłość działania aplikacji w czasie określonym w SLA. W praktyce wyróżnia się dwa czasy:

• Czas reakcji - czas od zgłoszenia błędu do potwierdzenia rejestracji w systemie raportowania
• Czas naprawy - czas od zgłoszenia błędu do przywrócenia ciągłości działania procesu, z wyłączeniem całkowitego czasu zawieszenia spowodowanego np. oczekiwaniem Service Desk na odpowiedź użytkownika na zadane pytanie.

Dostawca utrzymuje bieżącą wiedzę o systemie, aktualizuje dokumentację i tworzy mechanizmy testowe.

Często można usłyszeć opinię, że nie trzeba kupować SLA, ponieważ aplikacja została wdrożona X lat temu i przez ten czas działała niezawodnie. Niektórzy menedżerowie chcą zaoszczędzić na opłatach stałych, a zaoszczędzone w ten sposób pieniądze przeznaczyć na rozwój systemu lub dowolny inny cel.

Decyzja ta może mieć dramatyczne konsekwencje, gdyż czynniki nie związane bezpośrednio z samym kodem aplikacji mogą zakłócić niezawodne działanie systemu i doprowadzić do awarii nawet wtedy, gdy sama aplikacja nie zawiera błędów. Przykładowo, system zamówień działał bez zarzutu przez 2 lata, ale aplikacja stała się niestabilna, gdy liczba jednoczesnych użytkowników systemu znacznie wzrosła np. z powodu rozwoju firmy lub działań marketingowych. Innym przykładem może być awaria systemu spowodowana aktualizacją oprogramowania serwera lub innego elementu infrastruktury, gdy system staje się z nim niekompatybilny. Po wygaśnięciu gwarancji dostawca nie musi już utrzymywać niezbędnej i aktualnej wiedzy o systemie, co wydłuża czas naprawy i zwiększa koszty. W skrajnym przypadku może się okazać, że świadczeniodawca nie posiada już kompetencji w zakresie danej technologii i nie jest w stanie podjąć się jej modyfikacji.

SLA wymusza na dostawcy zachowanie wiedzy na temat wdrażanego systemu, jego struktury i funkcji.

W ten sposób można mieć pewność, że dostawca będzie w stanie sprawnie reagować na różne błędy oraz że do projektu został przydzielony zespół wsparcia technicznego, który w razie awarii będzie miał czas, aby zająć się problemem i zrobić to w krótkim czasie. W tym przypadku dostawca musi na bieżąco aktualizować dokumentację systemu, zapewnić odpowiednie kompetencje w zespole itp. Mając na uwadze długofalową współpracę, dostawcy często zależy również na stworzeniu dodatkowych mechanizmów testowania i ostrzegania o zagrożeniach dla stabilności aplikacji. Aspekty te są ważne nie tylko dla prawidłowej realizacji umowy SLA, ale również przyczyniają się do obniżenia kosztów rozwoju systemu i jego jakości.

3. Ważne parametry SLA

Poniższe pytania dotyczące parametrów są jednymi z wielu pytań, na które należy odpowiedzieć przed przystąpieniem do negocjowania umów SLA:

• Jakie procesy są kluczowe dla naszej firmy i w jakich momentach musimy zapewnić ciągłość ich działania
• Jakie rodzaje błędów dopuszczamy i jak je opisywać
• Jakie są godziny pracy wsparcia oraz jakiego czasu reakcji i naprawy możemy się spodziewać
• Jak zmierzyć skuteczność usługi?
• Jakie są procedury komunikacyjne i ścieżki eskalacji

W praktyce odpowiedzi na te pytania umieszcza się w tabeli, takiej jak poniższa.
Przykład 1:

Należy pamiętać, aby w parametrach SLA określić, w jakie dni i w jakich godzinach wsparcie jest efektywne. Powinny one odzwierciedlać statystyki wykorzystania systemu i minimalizować potencjalne straty w przypadku niedostępności systemu. Jednocześnie pamiętaj, że im bardziej rygorystyczne wymagania, tym wyższa cena SLA. Dlatego poziom SLA powinieneś wybrać jako kompromis pomiędzy kosztem SLA a poziomem rzeczywistych wymagań biznesowych.

Obejście
Należy zdawać sobie sprawę z różnicy pomiędzy obejściem (workaround) a całkowitym usunięciem przyczyny błędu. W skrócie, obejście przywraca proces biznesowy, jednak nie musi oznaczać całkowitego usunięcia przyczyny błędu. Z punktu widzenia biznesu, działanie systemu jest kluczowe, dlatego należy wynegocjować jak najkrótszy czas, w którym dostawca zapewni przynajmniej obejście problemu. Całkowite usunięcie przyczyny błędu może wiązać się z przygotowaniem, przetestowaniem i wdrożeniem nowej wersji systemu, co wymaga więcej niż kilku godzin, w czasie których możesz zapewnić obejście problemu. W zależności od umowy SLA, czas przewidziany na całkowite usunięcie przyczyny błędu może być krótszy lub dłuższy. Wdrażanie nowych wersji powinno odbywać się na podstawie odrębnych zleceń, których SLA nie obejmuje (w przeciwnym razie koszt SLA będzie nieporównywalnie wyższy).

Pomiar dostępności aplikacji
Bardzo ważnym parametrem jest poziom dostępności aplikacji, wyrażony w procentach i liczony dla konkretnych okresów (najczęściej miesięcy). Korzystnie jest, jeśli dostawca aktywnie monitoruje dostępność aplikacji za pomocą wyspecjalizowanego systemu, np. NAGIOS, i udostępnia te wyniki. W przypadku wykrycia problemów z dostępnością aplikacji, systemy takie jak NAGIOS mogą wysyłać wiadomości tekstowe i e-mailowe do konkretnych osób. Systemy pomiaru dostępności aplikacji przechowują wszystkie informacje związane z dostępnością i umożliwiają generowanie zaplanowanych raportów. Monitorowanie jest możliwe dzięki automatycznym procesom działającym na serwerze, które w określonych odstępach czasu wykonują czynności sprawdzające dostępność aplikacji. Należy zadbać o to, aby monitoring był uruchomiony na serwerze w innym, niezależnym centrum danych, tak aby mieć pewność, że ma on dostęp do Internetu i działa poprawnie. Często sprawdzane są również same mechanizmy monitorujące. Systemy takie jak NAGIOS mogą sprawdzać czasy odpowiedzi na poszczególne zapytania, np. czas, po jakim wyświetlana jest strona z nowym zamówieniem. Więcej o NAGIOS w innym naszym artykule: Pomiar dostępności aplikacji. Monitoring operacji w obiektywny sposób ocenia i mierzy efektywność obsługi SLA.

Linie komunikacyjne i pomocnicze
Opis komunikacji pomiędzy dostawcą usług a klientem jest kluczowym elementem każdej umowy SLA. Określ, kto i w jaki sposób może zgłaszać problemy. Zazwyczaj wyróżnia się dwie linie wsparcia, według których:

• Pierwsza linia wsparcia - dotyczy rozwiązywania problemów bezpośrednich użytkowników systemu. Są to najczęściej drobne problemy, które nadają się do rozwiązania przez helpdesk. Najczęstszą formą komunikacji jest telefon, chat, e-mail.
• Druga linia wsparcia - dotyczy rozwiązywania problemów i incydentów, w przypadku których pierwsza linia wsparcia nie jest w stanie ich rozwiązać. W takiej sytuacji pracownicy I linii wsparcia przekazują problem do II linii w określonym obszarze (np. do dostawcy oprogramowania).

W obu przypadkach zaleca się korzystanie z systemu raportowania w celu pomiaru wskaźników rzeczywistego poziomu SLA. W przypadku, gdy wsparcie jest świadczone przez firmę zewnętrzną, system śledzenia raportów będzie niezbędny do zabezpieczenia interesów obu stron.

Eskalacja
W umowach SLA, eskalacja jest najczęściej procedurą komunikacyjną w przypadku problemów w trakcie obsługi incydentu (np. spodziewane lub występujące opóźnienia w dostarczeniu rozwiązania lub zarządzaniu incydentami krytycznymi). Procedury eskalacji często zakładają włączenie do komunikacji pracownika wyższego szczebla w celu rozwiązania zaistniałego problemu.

Najczęstsze problemy przy negocjowaniu umów SLA

• Przedsiębiorstwa oczekują poziomów dostępności i wsparcia systemowego nieadekwatnych do rzeczywistych potrzeb. Zdarza się, że wymagania biznesowe podczas negocjacji SLA dla niekrytycznych systemów IT określają poziom dostępności systemu na 99,999% miesięcznie oraz pełne wsparcie 24 godziny/365 dni w roku z czasem naprawy błędów w ciągu 1 godziny. Rzeczywiście, istnieją systemy, które wymagają najwyższych poziomów dostępu i czasu pracy (np. główny system bankowy czy usługi telefonii komórkowej). Jednak wiele rozwiązań biznesowych działa w określonych godzinach w ciągu dnia, a poza nimi ich wykorzystanie jest minimalne. Stąd brak dostępności w tych godzinach nie oznacza znaczących strat. Trudno w takich sytuacjach uzasadnić najwyższe poziomy całodobowego wsparcia.
• Przedsiębiorcy oczekują wycen umów wsparcia SLA bez podania parametrów wsparcia. Wycena usługi wsparcia SLA zależy bezpośrednio od tych parametrów, dlatego właściciel biznesowy systemu musi określić przynajmniej przybliżone oczekiwania co do poziomu wsparcia. Jeśli stanowi to problem, można poprosić dostawcę o wycenę dla kilku wariantów poziomu wsparcia.

4. Wnioski
Planując budżet projektu należy przewidzieć środki na usługę wsparcia systemu, gdyż jest to właściwie jedyny skuteczny sposób na zapewnienie dostępności systemu na wymaganym poziomie. Oszczędności tego typu są pozorne, a w najgorszym przypadku mogą skutkować utratą zysków i zaufania klientów. Warto również wspomnieć, że istnieje wiele usystematyzowanych zbiorów najlepszych praktyk związanych z usługami wsparcia, takich jak ITIL. Powinny być one znane i wykorzystywane zarówno przez dostawcę, jak i odbiorcę.