W ofertach firm informatycznych parametry SLA wyglądają podobnie: czas reakcji, dostępność usługi, priorytety zgłoszeń, wsparcie w godzinach pracy. Brzmi konkretnie, więc rzadko ktoś dopytuje. Problem pojawia się przy pierwszej poważnej awarii, kiedy okazuje się, że „reakcja w 4 godziny” znaczyła coś innego, niż wydawało się przy podpisywaniu. Ten artykuł rozkłada typową umowę SLA na części i pokazuje, o co warto zapytać, zanim będzie za późno.

Czym w ogóle jest SLA

SLA, czyli Service Level Agreement, to część umowy lub osobny załącznik określający mierzalne parametry świadczonej usługi. Sam zakres prac może być opisany w innym miejscu umowy, natomiast SLA wskazuje między innymi czasy reakcji, godziny wsparcia, poziomy dostępności oraz zasady eskalacji.

Dobre SLA działa na korzyść obu stron: klient wie, czego może oczekiwać, dostawca wie, kiedy dotrzymał zobowiązania. Kluczowa różnica, od której wszystko się zaczyna, brzmi tak: czas reakcji nie jest tym samym co czas rozwiązania. Dobre SLA powinno jasno określać, który z tych parametrów dostawca gwarantuje, a nie pozostawiać tego domysłom.

Czas reakcji to nie czas naprawy

W praktyce w umowach spotyka się trzy różne parametry czasowe. W ofertach handlowych eksponowany jest zwykle tylko pierwszy, bo brzmi najlepiej.

Czas reakcji to okres od prawidłowego zarejestrowania zgłoszenia do wykonania czynności, którą umowa uznaje za reakcję. I tu jest sedno sprawy: tą czynnością może być kontakt technika, rozpoczęcie diagnostyki albo jedynie automatyczne potwierdzenie przyjęcia sprawy. Sama liczba godzin niewiele mówi bez dokładnej definicji punktu końcowego. „Reakcja w 4 godziny” w jednej umowie oznacza, że po czterech godzinach ktoś realnie zaczyna pracować nad problemem, a w innej, że system wysłał maila z numerem zgłoszenia.

Czas przywrócenia usługi to okres, po którym użytkownicy mogą ponownie pracować, nawet w ograniczonym zakresie. Może to oznaczać uruchomienie zapasowego łącza, przełączenie na inny serwer albo udostępnienie tymczasowego stanowiska. Dla ciągłości pracy jest to parametr najważniejszy, a jednocześnie najrzadziej obecny w ofertach.

Czas pełnego rozwiązania to moment usunięcia właściwej przyczyny problemu. Bywa znacznie odległy od przywrócenia działania i zależy od czynników poza kontrolą dostawcy: dostępności części zamiennych, reakcji producenta oprogramowania, terminu naprawy u operatora łącza.

To, że dostawca nie gwarantuje czasu pełnego rozwiązania, nie jest samo w sobie sygnałem ostrzegawczym. Gwarancja usunięcia dowolnej awarii w cztery godziny byłaby po prostu niewiarygodna. Warto natomiast zapytać o gwarantowany czas przywrócenia usługi lub zastosowania obejścia, bo system może zacząć działać w trybie zastępczym znacznie wcześniej, niż zostanie usunięta właściwa przyczyna.

Priorytety zgłoszeń decydują o wszystkim

Deklarowany czas reakcji prawie nigdy nie dotyczy wszystkich zgłoszeń. Dotyczy zgłoszeń o określonym priorytecie, więc sposób nadawania priorytetów jest w praktyce najważniejszym mechanizmem w całej umowie i najrzadziej czytanym.

Typowy podział wygląda następująco:

• Krytyczny – awaria zatrzymująca pracę całej firmy albo kluczowego procesu, na przykład niedostępny serwer, awaria łącza, zaszyfrowanie danych.
• Wysoki – awaria blokująca pracę działu lub pojedynczej ważnej funkcji, na przykład niedziałająca drukarka fiskalna albo brak dostępu do systemu księgowego.
• Normalny – problem utrudniający pracę jednej osoby, gdy istnieje obejście.
• Niski – pytania, drobne zmiany, sprawy bez wpływu na bieżącą pracę.

W dojrzałej umowie priorytet nie jest kwestią uznania. Wynika z opisanej wcześniej macierzy łączącej dwa wymiary: wpływ, czyli ilu użytkowników i procesów dotyczy problem, oraz pilność, czyli jak szybko sytuacja powoduje poważne konsekwencje. Priorytet może być wskazany przez klienta i następnie zweryfikowany przez dostawcę, ale zasady tej weryfikacji powinny wynikać z macierzy, a nie z rozmowy. Jeśli dostawca może dowolnie obniżyć priorytet bez uzasadnienia, gwarantowany czas reakcji traci praktyczne znaczenie. Wystarczy przeklasyfikować zgłoszenie na normalne.

Warto też sprawdzić, czy opisano procedurę eskalacji, czyli co się dzieje, gdy sprawa stoi w miejscu. Funkcja osoby odpowiedzialnej za kolejne poziomy eskalacji oraz sposób kontaktu są w umowie wartościowsze niż kolejna deklaracja procentowa. Wskazywanie konkretnego nazwiska ma sens tylko wtedy, gdy umowa przewiduje aktualizację tej informacji, bo ludzie zmieniają stanowiska.

Kiedy zegar SLA przestaje biec

Równie ważne jak moment rozpoczęcia pomiaru są zasady jego zatrzymywania. To najczęściej pomijany element całej umowy, a potrafi zmienić znaczenie wszystkich pozostałych zapisów.

Umowa może przewidywać, że czas SLA nie biegnie, gdy dostawca:

• oczekuje na odpowiedź klienta lub decyzję osoby upoważnionej,
• nie ma dostępu do urządzenia, pomieszczenia albo systemu,
• czeka na część zamienną,
• przekazał sprawę do producenta oprogramowania lub operatora łącza,
• zaproponował obejście, którego klient nie zaakceptował.

Takie wyłączenia bywają w pełni uzasadnione, bo dostawca nie powinien odpowiadać za czas, na który nie ma wpływu. Powinny być jednak jednoznacznie opisane i widoczne w historii zgłoszenia. W przeciwnym razie trudno sprawdzić, ile czasu dostawca rzeczywiście poświęcił na rozwiązanie problemu, a formalne wykonanie SLA przestaje mówić cokolwiek o realnej jakości obsługi.

Godziny świadczenia usługi zmieniają sens wszystkich liczb

Ten parametr potrafi zmienić znaczenie umowy bardziej niż sam czas reakcji, a rzadko trafia na pierwszą stronę oferty.

Wsparcie w modelu 8×5 obejmuje 40 godzin tygodniowo. Model 24×7 daje 168 godzin, czyli ponad czterokrotnie szersze okno obsługi. Różnica dotyczy przede wszystkim wieczorów, weekendów i dni wolnych, więc widać ją dopiero na konkretnym przykładzie.

Jeśli zgłoszenie krytyczne trafia do dostawcy w piątek o 17:30, a wsparcie działa od 8:00 do 16:00 w dni robocze, to czterogodzinny czas reakcji zaczyna biec w poniedziałek o 8:00 i upływa o 12:00. Formalnie umowa została dotrzymana, mimo że firma pozostawała bez pomocy przez cały weekend i poniedziałkowy poranek.

Sposób liczenia musi przy tym wynikać wprost z umowy. Bywa, że zgłoszenie jest rejestrowane natychmiast, ale zegar pozostaje zatrzymany poza godzinami wsparcia. Bywa też, że dla zgłoszeń krytycznych obowiązuje osobny tryb całodobowy. Warto ustalić trzy rzeczy: w jakich godzinach liczony jest czas reakcji, czy dla awarii krytycznych istnieje tryb poza tymi godzinami, oraz czy taki tryb jest wliczony w abonament, czy rozliczany dodatkowo.

Incydent czy wniosek o usługę – to dwa różne terminy

Rozróżnienie, o które prawie nikt nie pyta, a które generuje najwięcej codziennej frustracji.

Awaria, czyli incydent, to sytuacja, w której coś przestało działać. Utworzenie konta dla nowego pracownika, instalacja programu, przygotowanie stanowiska albo zmiana uprawnień to natomiast wnioski o usługę. Formalnie należą do innej kategorii i zwykle podlegają innym terminom, często planowanym z wyprzedzeniem, a nie mierzonym w godzinach.

Warto sprawdzić, jak umowa traktuje te dwie grupy. Jeśli SLA obejmuje wyłącznie incydenty, to przygotowanie stanowiska dla nowej osoby może teoretycznie czekać dowolnie długo. Dobrze skonstruowana umowa opisuje osobne, realistyczne terminy dla wniosków o usługę, na przykład zobowiązanie do przygotowania stanowiska w ciągu określonej liczby dni roboczych od zgłoszenia.

Dostępność wyrażona w procentach, czyli ile to jest w minutach

Zanim przejdziemy do liczb, jedno rozróżnienie. Czas reakcji dotyczy sposobu obsługi zgłoszeń. Dostępność dotyczy działania konkretnej usługi lub infrastruktury. Te parametry nie powinny być utożsamiane, a dostawca może gwarantować dostępność tylko tych elementów, za które rzeczywiście odpowiada.

Deklaracje dostępności brzmią imponująco, dopóki nie przeliczy się ich na czas. Poniżej dopuszczalny przestój przy różnych poziomach, dla miesiąca liczonego jako 30 dni oraz dla roku.

Dostępność	Dopuszczalny przestój / miesiąc	Dopuszczalny przestój / rok
99%	7 godzin 12 minut	3 dni 15 godzin 36 minut
99,5%	3 godziny 36 minut	1 dzień 19 godzin 48 minut
99,9%	43 minuty	8 godzin 46 minut
99,95%	22 minuty	4 godziny 23 minuty

 

Widać tu dwie rzeczy. Po pierwsze, różnica między 99% a 99,9% to nie drobny niuans, ale dziesięciokrotność dopuszczalnego przestoju. Po drugie, okres rozliczeniowy ma ogromne znaczenie. Dostępność 99,9% rozliczana rocznie pozwala na jedną awarię trwającą prawie pełny dzień pracy, bo przez pozostałe miesiące bilans się wyrówna. Ta sama liczba rozliczana miesięcznie daje 43 minuty.

Sam procent to jednak dopiero połowa informacji. Trzeba również sprawdzić sposób pomiaru. Dostępność obserwowana z systemu dostawcy może różnić się od dostępności widzianej przez użytkowników w biurze. Umowa powinna określać źródło danych, punkt pomiarowy oraz sposób traktowania częściowych awarii i planowanych prac serwisowych. Spowolnienie systemu do granicy używalności formalnie nie jest niedostępnością, a dla pracowników jest nią w praktyce.

Osobna kwestia to zależność od podmiotów trzecich. Jeśli działanie usługi opiera się na jednym operatorze albo jednym dostawcy chmurowym, gwarancja powinna uwzględniać warunki otrzymywane od tego podmiotu. Wyższy poziom dostępności jest oczywiście możliwy, ale zwykle wymaga redundancji, dodatkowej architektury lub odrębnego zobowiązania dostawcy, który przyjmuje część ryzyka na siebie. Warto zapytać, który z tych scenariuszy obowiązuje.

Kanały zgłoszeń i raportowanie

Umowa może gwarantować cztery godziny reakcji, ale jeśli zgłoszenie nigdy nie zostanie zarejestrowane, parametr nie ma zastosowania. Dlatego warto sprawdzić, jak wygląda droga zgłoszenia od pracownika do systemu.

Najczęstszy problem w mniejszych firmach polega na tym, że sprawy załatwia się wiadomością na komunikatorze albo telefonem do znanego technika. Działa to szybko, dopóki działa, ale nie zostawia śladu. Nikt nie wie, ile zgłoszeń wpłynęło, które czekają i czy termin został dotrzymany.

Dobrze zorganizowane wsparcie użytkowników przyjmuje zgłoszenia w kilku kanałach jednocześnie, telefonicznie, mailowo i przez portal, ale kieruje je wszystkie do jednego systemu. Dopiero wtedy da się w ogóle rozmawiać o dotrzymywaniu SLA, bo istnieje wspólna, sprawdzalna historia zdarzeń.

Comiesięczne zestawienie liczby zgłoszeń, czasów reakcji, zatrzymań zegara i przekroczeń jest podstawą do egzekwowania SLA. Bez wiarygodnych danych nawet dobrze zapisane konsekwencje mogą okazać się trudne do zastosowania. Same konsekwencje przybierają w umowach IT różne formy: kary umowne, rabaty lub kredyty serwisowe, obowiązek przygotowania planu naprawczego, podwyższenie poziomu eskalacji albo prawo do wypowiedzenia umowy po powtarzających się naruszeniach. Warto wiedzieć, który z tych mechanizmów przewiduje Twoja umowa i jak wygląda procedura jego uruchomienia.

Czego SLA zwykle nie obejmuje

Ta część umowy bywa najkrótsza i najważniejsza. Typowe wyłączenia obejmują:

• skutki działania siły wyższej,
• przerwy u operatorów łączy i dostawców usług chmurowych,
• skutki zmian wprowadzonych przez klienta lub podmioty trzecie bez wiedzy dostawcy,
• sprzęt poza wsparciem producenta oraz oprogramowanie, dla którego zakończono wydawanie poprawek,
• środowiska, do których dostawca nie otrzymał pełnych uprawnień administracyjnych,
• planowane okna serwisowe zgłoszone z ustalonym wyprzedzeniem.

Większość tych wyłączeń jest uzasadniona i często występuje w profesjonalnie przygotowanych umowach. Nie chodzi o to, żeby ich nie było, ale żeby wiedzieć, gdzie leży granica odpowiedzialności. Warto przy tym zauważyć, że wyłączenie odpowiedzialności za awarię u operatora nie musi oznaczać całkowitej bierności dostawcy. Może on nadal odpowiadać za eskalację sprawy, komunikację, uruchomienie rozwiązania zapasowego i koordynowanie podmiotu zewnętrznego. To warto ustalić wprost.

Szczególnej uwagi wymaga punkt o sprzęcie po zakończeniu wsparcia producenta, bo w wielu firmach dotyczy on urządzeń używanych codziennie.

Lista pytań przed podpisaniem umowy

Firmy porównujące oferty obsługi IT w Warszawie i w innych dużych miastach zwykle zestawiają ceny oraz deklarowane czasy reakcji, bo to jedyne parametry łatwe do porównania w tabelce. Przy wyborze obsługi informatycznej dla firm w Warszawie warto jednak poprosić o wzór SLA jeszcze przed porównaniem cen. Pozwala to sprawdzić nie tylko deklarowane godziny, ale też zasady wizyt na miejscu, sposób rozliczania dojazdów i listę wyłączeń.

Jeśli z całego artykułu miałaby zostać jedna rzecz, niech to będzie ta lista.

1. Czy podany czas dotyczy reakcji, przywrócenia usługi czy pełnego rozwiązania?
2. Jaka konkretna czynność jest w umowie uznawana za reakcję?
3. Kto nadaje priorytet i czy wynika on z opisanej macierzy wpływu i pilności?
4. Kiedy zegar SLA może zostać zatrzymany i jak jest to rejestrowane?
5. W jakich godzinach biegnie czas reakcji i co dzieje się poza nimi?
6. Czy dla awarii krytycznych obowiązuje osobny tryb i czy jest w abonamencie?
7. Czy wnioski o usługę, takie jak nowe stanowisko czy konto, podlegają SLA, czy są planowane osobno?
8. W jakim okresie rozliczana jest dostępność: miesięcznym czy rocznym?
9. Skąd pochodzą dane używane do obliczania dostępności i gdzie jest punkt pomiarowy?
10. Jakich elementów środowiska dotyczy deklarowana dostępność?
11. Jak wygląda procedura eskalacji i do jakiej funkcji prowadzi?
12. Jakie raporty otrzymuję i z jaką częstotliwością?
13. Jakie konsekwencje przewiduje umowa za przekroczenie parametrów i jak wygląda procedura ich naliczania?

Podsumowanie

Umowa SLA nie ma za zadanie chronić klienta przed awariami, bo to niemożliwe. Ma sprawić, że w momencie awarii obie strony wiedzą, co się stanie i w jakim czasie. Dobrze skonstruowane SLA jest więc narzędziem przewidywalności, nie gwarancją bezawaryjności.

Praktyczny wniosek jest prosty. Zamiast porównywać oferty po najniższej deklarowanej liczbie godzin, warto porównać je po precyzji zapisów. Dostawca, który rozgraniczy reakcję od przywrócenia usługi, opisze kryteria priorytetów, pokaże zasady zatrzymywania zegara i listę wyłączeń, prawdopodobnie dobrze rozumie własną pracę. Dostawca oferujący jedną atrakcyjną liczbę bez kontekstu składa obietnicę, której nikt nie będzie w stanie sprawdzić.

Artykuł zewnętrzny.