Ostatnio dużo piszę o SLA i wydaje mi się, że nadal nie wyczerpałem tematu :-). W publikacji „SLA wygrany-wygrany” wskazywałem na potrzebę równowagi w SLA, pomiędzy wymaganiami biznesu a możliwościami IT. Natomiast w artykule „Jak funkcjonować z niekorzystnym SLA dla zamawiającego lub dostawcy”, zwracałem uwagę jak radzić sobie, gdy jednak SLA dla jednej ze stron jest dużo bardziej korzystne. Czy może być jeszcze gorzej. Według mnie może, gdy nie mamy żadnego SLA, a mimo to IT musi świadczyć usługi dla biznesu. Dla kogo jest to bardziej niekorzystna sytuacja? Wydaje się, że traci na tym biznes ale czy tylko? Zastanówmy się, jakie są konsekwencje takiej sytuacji w rzeczywistości i co można zrobić aby ją zmienić.

Nie mamy SLA i co nam zrobisz?

Dobrze przygotowane i uzgodnione SLA zabezpiecza interesy zamawiającego czyli biznesu i dostawcy czyli IT. Co jednak oznacza brak SLA dla wzajemnych relacji i działania operacyjnego?

Nie mamy ustalone, na jakim poziomie mają być świadczone usługi, co oznacza że nie wiemy czy są dostarczane we właściwy sposób. Co to oznacza w praktyce?

• Nie jest określone jaka powinna być dostępność usług. Czy wystarczające jest 95% a może 98 lub 99%? W jakim kalendarzu powinny być świadczone usługi?
• Nie mamy zdefiniowanej wydajności i wolumetrii usług. Czy czasy odpowiedzi są odpowiednie krótkie: 5, 3 a może 1 sekunda? Czy ilość wywołań usług jest na poziomie, dla jakiego zostały zaprojektowane usługi? A może nikt nie zastanawiał się tworząc te usługi?
• Nie ustalono jaki powinien być czas reakcji i rozwiązania, w przypadku pojawienia się zgłoszeń od użytkowników. Jak szybko zareagują zespoły wsparcia i w jakiem czasie usuną incydent lub problem? Czy 30 minut na czas reakcji jest wystarczające? Ile powinien wynosić czas rozwiązania w zależności od priorytetu zgłoszenia? 4, 8 godzin a może 1, 2 5 dni?
• Nie przewidziano w jakim czasie należy przywrócić usługi do działania, w przypadku wystąpienia katastrofy. Czy biznes może funkcjonować bez usług IT 1, 2 czy 4 dni?

Podałem przykładowe parametry SLA i możliwe wartości dopuszczalne dla nich, aby pokazać, jakie są konsekwencje braku SLA. Co można zrobić w takiej sytuacji? Rozwiązania na pewno się znajdą ale wymagają dobrej woli obu stron: biznesu i IT.

Zacznij od mierzenia SLA

Jak mam mierzyć coś czego nie ma? SLA to w dużym uproszczeniu lista parametrów, dla których zostały określone wartości dopuszczalne. Dlatego jeżeli nie mamy żadnego SLA, to na początek ustalmy, biznes i IT wspólnie, jakie parametry SLA chcielibyśmy mieć. Jak już będziemy mieli ustalone parametry SLA, musimy zacząć je mierzyć, czyli wyznaczać ich wartości rzeczywiste. Jak mierzyć parametry SLA możesz przeczytać w moich dwóch publikacjach „Jak mierzyć parametry SLA część 1” i „Jak mierzyć parametry SLA część 2„. Mierzenie parametrów SLA jest pierwszym krokiem do uzgodnienia SLA. Kolejnym jest liczenie wartości rzeczywistych parametrów SLA.

Licz wartości rzeczywiste parametrów SLA

Jak już mierzymy i zbieramy wartości parametrów SLA, możemy zacząć wyznaczać wartości rzeczywiste tych parametrów za ustalony okres czasu: dzień, tydzień, miesiąc, kwartał, rok. Policzone wartości pokazują nam na jakim poziomie świadczone są usługi dla poszczególnych parametrów SLA. Możemy porównywać te wartości dzień do dnia, tydzień do tygodnia, miesiąc do miesiąca itd. Uzyskana w ten sposób wiedza, pozwala nam na analizę wartości rzeczywistych i poznanie trendów oraz możliwości organizacji IT. Jest to nie ocenione źródło informacji, jak działają usługi i organizacja utrzymania, która wspiera prawidłowe funkcjonowanie usług IT.

Ustal wartości dopuszczalne parametrów SLA

Wyznaczane regularnie wartości rzeczywiste parametrów SLA, są podstawą do ustalenia, jakie powinny być wartości dopuszczalne dla tych parametrów. Według mnie można do najwcześniej zrobić posiadając dane z przynajmniej 3 miesięcy. Jednak aby nasza prognoza była lepsza, lepiej dysponować danymi z 6 a najlepiej z 12 miesięcy. Pierwsza propozycja wartości dopuszczalnych parametrów SLA powinna być średnią wartości rzeczywistych z liczby miesięcy, za które posiadamy dane. Im więcej miesięcy tym wartość dopuszczalna lepiej będzie odzwierciedlać możliwości IT. Co jednak, gdy wyznaczone wartości dopuszczalne, nie spełniają oczekiwań biznesu?

Rozpocznij negocjacje i uzgodnij SLA

Jeżeli wartości dopuszczalne parametrów SLA nie spełniają wymagań biznesu, obie strony myszą siąść do rozmów i rozpocząć negocjacje, których celem będzie ustalenie takich wartości SLA, które będą korzystne dla obu, biznesu i IT. Strategii negocjacyjnych jest bardzo dużo, nie chodzi jednak aby jedna strona przechytrzyła drugą ale aby porozumiały się, co do wspólnych parametrów. Zrozumiałe jest, że biznes będzie chciał jak najlepsze wartości dla siebie a IT dla siebie. Mimo tego musi dojść do kompromisu. Pamiętajmy, że biznes, nie ma żadnego SLA, dlatego powinien dążyć do ustalenia SLA, które będzie z korzyścią dla obu stron. Przecież, jeżeli nie ma SLA, to IT nie zgodzi się na SLA, którego nie będzie mogło spełnić.

Najważniejsze jest mierzenie wartości rzeczywistych parametrów SLA i otwartość biznesu i IT, do rozmów na temat jakie SLA będzie korzystne dla obu stron. Bez woli współpracy i wypracowania wspólnego rozwiązania, nie będzie możliwe doprowadzenie do uzgodnienia SLA i nadal nie będzie żadnego SLA. Taki scenariusz jest najgorszy z możliwych i niekorzystny dla zamawiającego i dostawcy.

Pytanie: Jak rozwiązałeś sytuacje braku SLA w swojej organizacji?

Artykuł Co zrobić jeżeli brak jest SLA? pochodzi z serwisu Mariusz Siek.

Zdefiniowanie i uzgodnienie SLA, które będzie korzystne zarówno dla biznesu jak i IT, wymaga wiedzy i doświadczenia. Nie jest łatwo pogodzić wysokie wymagania biznesu z często ograniczonymi możliwościami IT. Ktoś może powiedzieć, że co to za filozofia napisać SLA i uzgodnić, przecież IT jest dla biznesu a nie odwrotnie. Opracowanie i uzgodnienie SLA, powinno prowadzić do sytuacji wygrany-wygrany, w przeciwnym razie zapewnienie najwyższej jakości usług przez IT dla biznesu, będzie niemożliwe.

Jakich błędów nie popełnić i jak ich uniknąć?

1Brak partnera po stronie biznesu

Przygotowanie i uzgodnienie SLA wymaga dwóch stron: biznesu i IT. Często zdarza się, że strony biznesowej nikt nie reprezentuje. Bez wiarygodnego i decyzyjnego partnera po stronie biznesu, nie jest możliwe uzgodnienie dobrego SLA. W większości przypadków inicjatorem SLA jest IT i to ono przygotowuje propozycję SLA, która jest przedstawiana biznesowi. Jeżeli biznes, nie znajdzie w swoich szeregach osób, które krytycznie ale konstruktywnie spojrzą na propozycję SLA przygotowaną przez IT, to:

• Po pierwsze będzie to SLA jednostronne
• Po drugie nie można będzie go uzgodnić
• Po trzecie faktycznie nie będziemy mieli żadnego SLA, bo SLA nie uzgodnione jest bezwartościowe

Aby zaradzić tej sytuacji, należy jeszcze przed rozpoczęciem przygotowywania SLA przez IT, wystąpić do biznesu z prośbą, o wskazanie biznesowego właściciela usługi/usług, który będzie odpowiadał za uzgodnienie SLA z IT.

2Brak uprawnień

Aby SLA mogło zostać uzgodnione i obowiązywało obie strony, biznesowy właściciel usługi musi mieć wymagane uprawnienia do reprezentowania biznesu. Bez takich uprawnień nie będzie możliwe podpisanie SLA. Należy zadbać aby osoba pełniąca rolę biznesowego właściciela usługi, zajmowała „wysoką” pozycję w organizacji.

3Brak wymagań biznesowych

Jeżeli już mamy partnera po stronie biznesu, to może się okazać, że nie ma wymagań niefunkcjonalnych związanych z działaniem usługi/usług. Brak wymagań biznesowych może wynikać z:

• Braku kompetencji po stronie biznesu. Najzwyczajniej w świecie, biznes nie wie co to jest SLA i trudno mu odnieść się do propozycji przedstawionej przez IT
• Brak doświadczenia. Nigdy nie uzgadniali SLA i nie mają skali porównawczej, do której mogą się odnieść.

W tym przypadku, rolą IT jest wyedukować biznes z wymagań niefunkcjonalnych i parametrów SLA.

4Zbyt duże wymagania biznesu

Również niekorzystna sytuacją jest, gdy biznes ma zbyt duże wymagania, co do SLA. Wtedy bardzo trudno jest uzgodnić SLA, ponieważ, żadna ze stron nie chce ustąpić, broniąc swoich racji. IT znając swoje możliwości, nie chce zgodzić się na wygórowane wymagania biznesu. Biznes chcąc zapewnić jak najwyższą jakość usług, nie chce złagodzić swoich wymagań. Sytuacja jest patowa.

Jako jej rozwiązanie, proponuję aby IT przedstawiło jakie są koszty związane ze świadczeniem usługi/usług na wysokim poziomie oczekiwanym przez biznes. Język finansów, powinien pomóc w złagodzeniu wymagań biznesowych lub spowodować dodanie pieniędzy do budżetu IT.

5Niewłaściwe zdefiniowanie parametrów SLA

Definiując każdy parametr SLA, trzeba pamiętać aby był dostosowany do usługi i odzwierciedlał wymagania biznesu. Jeżeli opracujemy parametr, który nie będzie odpowiadał na wymagania biznesowe, to nie oczekujmy, że biznes będzie z tego zadowolony i wysoko będzie oceniał jakość naszych usług. Pokazujmy biznesowi jakie są możliwości i konsekwencje przygotowanej definicji parametru, aby był świadomy jaki ma wybór.

IT odpowiada za poprawne zdefiniowanie parametrów SLA i powinno o tym zawsze pamiętać.

6Brak narzędzi do mierzenia SLA

Każde SLA, nawet to najlepsze dla obu stron, jest nic nie warte, jeżeli nie potrafimy go mierzyć. Bez odpowiednich narzędzi, IT nie będzie w stanie wykazać, czy spełnia czy nie obowiązujące SLA. Jeżeli IT nie zadba o ten aspekt, będzie narażona ze strony biznesu na oskarżenia, że świadczy usługi na nie wystarczających poziomie. Niestety, nikt nie będzie mógł tego udowodnić ale niezadowolenie biznesu, będzie skutkowało co raz gorszymi relacjami z IT.

Po stronie IT leży odpowiedzialność, przygotowania odpowiednich narzędzi, które będą mierzyły i wyznaczały, poszczególne parametry SLA.

Mam nadzieję, że przybliżenie, jakie błędy można popełnić przygotowując i uzgadniając SLA, pozwoli chociaż w części ich uniknąć.

Pytanie: Z którym błędem masz najczęściej do czynienia i jak sobie z nim radzisz?

Artykuł 6 najczęściej popełnianych błędów w SLA pochodzi z serwisu Mariusz Siek.

Zagadnienie jak mierzyć parametry SLA jest bardzo rozległe i jego rzetelne przedstawienie, wymagało podzielenia materiału na dwie części. W pierwszej części opisałem parametry SLA związane z dostępnością i czasem rozwiązania. W części drugiej rozwinę temat czasu rozwiązania i czasu reakcji oraz wydajności.

Czas rozwiązania

Czas rozwiązania może dotyczyć zarówno incydentów, problemów jak i service requestów. Zasady związane z mierzeniem czasu rozwiązania są dla wszystkich analogicznie. Kluczowe jest ustalenie:

• czasu rozpoczęcia
• czasu zakończenia
• zatrzymania czasu rozwiązania

Przykładowe zdarzenia rozpoczynające i kończące czas rozwiązania, podałem w części pierwszej. Oczywiście, które powinny być użyte do mierzenia czasu rozwiązania zależy, kto ten parametr definiuje. Dostawca, czy to w postaci wewnętrznego działu IT czy firmy zewnętrznej, będzie dążył do „skracania” początku i końca związanego z czasem rozwiązania. Oznacza to, że będzie wybierał te zdarzenia, które są korzystne dla niego. Jako rozpoczęcie będzie wskazywał, potwierdzenie przez Service Desk przyjęcia zgłoszenia, a jako zakończenie, rozwiązanie zgłoszenia przez zespoły wsparcia. 

Klient, nazywany również biznesem, będzie chciał aby czas rozwiązania obejmował jak najszerszy przedział czasu. Jest to jak najbardziej naturalne postępowanie obu stron :-).

Do wyjaśnienia pozostaje jeszcze kwestia zatrzymywania czasu rozwiązania. Jest to sposób na wydłużanie czasu rozwiązania, w sytuacji gdy zespoły wsparcia nie mogą rozwiązywać zgłoszenia, ponieważ:

• Nie mogą odtworzyć błędu i potrzebują kontaktu ze zgłaszającym
• Brakuje im wymaganych w zgłoszeniu danych
• Do rozwiązania potrzebują interakcji ze zgłaszającym

Oczywiście mówimy tu o zatrzymywaniu czasu rozwiązania, tylko w uzasadnionych przypadkach. Nie można dopuścić do sytuacji, w której zatrzymywany jest czas rozwiązania, aby „sztucznie” wydłużyć jego trwanie. Z drugiej strony, nie może być wliczane do czasu rozwiązania oczekiwanie na kontakt, ze zgłaszającym, który jest zajęty lub nieobecny w pracy.

Czas reakcji

Z czasem reakcji jest trochę łatwiej, niż z czasem rozwiązania, jednak musimy uważać na jego rozpoczęcie. Zakończenie czasu reakcji jest mniej problematyczne i przeważnie jest nim potwierdzenie przez Service Desk przyjęcia zgłoszenia. Bardzo często to potwierdzenie jest automatyczne, po zarejestrowaniu zgłoszenia w systemie ITSM lub wysłaniu emaila na określony adres.

Zwrócić należy uwagę na rozpoczęcie czasu reakcji, który może być mierzony od:

• Odebrania zgłoszenia telefonicznego przez operatora Service Desk
• Wysłania emaila na wskazany adres
• Zarejestrowania zgłoszenia w systemie klasy ITSM

W zależności, które zdarzenie wybierzemy, będziemy mieli inną wartość czasu reakcji.

Bardzo ważne jest, aby ustalić z biznesem, początek i koniec czasu reakcji i rozwiązania, aby nie było później nieporozumień, co do ich mierzenia i rozliczania.

Wydajność

Jak mierzyć parametry SLA dla wydajności, wolumetrii i czasu odpowiedzi, jest bardzo złożonym zagadnieniem obszaru SLA.

• Po pierwsze, należy zwrócić uwagę, czy pomiar jest wykonywany z perspektywy systemy czy użytkownika końcowego. Bardzo często mierzymy czas odpowiedzi na serwerze aplikacyjnym, nie uwzględniając opóźnień sieciowych i innych występujących pomiędzy użytkownikiem końcowym a systemem/aplikacją IT.
• Po drugie, jakie operacje, czynności podlegają pomiarowi. Aby optymalizować kosztowo testy wydajnościowe, uwzględnia się tylko najważniejsze i najczęściej wykorzystywane ścieżki działania użytkownika. Może to prowadzić do nie mierzenia w ogóle, pewnych aktywności w systemie.
• Po trzecie, testy wydajnościowe przeprowadzane są najczęściej na środowisku testowym, które nie odzwierciedla w 100% środowiska produkcyjnego, co może skutkować niedokładnością pomiaru. Dodatkowo, testy wydajnościowe przeprowadzane są przeważnie raz, podczas tworzenia systemu/aplikacji. Aby weryfikacja podczas testów wydajnościowych była wiarygodna, powinno się je powtarzać okresowe co 3 lub 6 miesięcy.
• Po czwarte, testy wydajnościowe nie mierzą rzeczywistej wolumetrii i czasów odpowiedzi, tylko wyznaczają wartości w środowisku laboratoryjnym. Aby mierzyć wartości rzeczywiste, w środowisku produkcyjnym, należy wybrać jedną z możliwości:
  • Uruchomić i skonfigurować narzędzie monitorowania wydajności, np. appDynamics aby móc na bieżąco, mierzyć parametry wydajnościowe
  • Zaprojektować i wdrożyć mechanizm, wyznaczania czasów pojedynczych wywołań, dla poszczególnych usług. Czasy te powinny być zapisywane w dedykowanej tabeli, na podstawie której można będzie wyliczyć, wymagane parametry wydajnościowe

Zagadnienia pomiaru wydajności są bardzo ciekawe i wielowątkowe, dlatego pomyślę aby opisać je bardziej szczegółowo w oddzielnym artykule.

Tak naprawdę, to przedstawiłem tylko najważniejsze kwestie związane z mierzeniem wybranych, najczęściej stosowanych parametrów SLA. Mam nadzieję, że zainteresowałem Ciebie tą wiedzą. Jeżeli masz pytania, napisz je w komentarzu. Chętnie na wszystkie odpowiem. Na koniec pytanie ode mnie.

Pytanie: Jak mierzysz rzeczywiste wartości parametrów wydajnościowych?

Artykuł Jak mierzyć parametry SLA – część 2 pochodzi z serwisu Mariusz Siek.

Tworząc katalog usług często pamiętamy, aby dobrze zdefiniować usługi i później rzetelnie określić dla nich SLA. Czy jednak zastanawiamy się, jak będziemy mierzyć wartości rzeczywiste poszczególnych parametrów? Na ile wykonane pomiary, będą odzwierciedlać rzeczywisty poziom usług odczuwany przez użytkownika? Posiadanie SLA bez jasno i precyzyjnie wskazanych metod pomiarowych, w jaki sposób będziemy wyznaczać wartości rzeczywiste, jest niewystarczające, aby dobrze rozliczać SLA.

Czym jest metoda pomiarowa?

Ustalając z biznesem poszczególne parametry poziomu usług, powszechnie nazywane SLA, musimy oprócz podania ich wartości dopuszczalnych, pokazać jak będą wyznaczane wartości rzeczywiste tych parametrów. Sposób wyznaczania wartości rzeczywistych nazywam metodą pomiarową. Aby precyzyjnie ją opisać należy zdefiniować wzór, według którego będzie wyznaczana wartość rzeczywista parametru oraz opisać wszystkie symbole we wzorze. Nie będę tutaj podawał szczegółowych wzorów ale chciałbym zwrócić uwagę, na najważniejsze sposoby liczenia, dla poszczególnych parametrów SLA.

Dostępność

Dostępność usługi biznesowej można liczyć na dwa sposoby

• Pierwszy, polega na mierzeniu w narzędziu monitorowania dostępności poszczególnych usług systemowych/technicznych, wchodzących w skład usługi biznesowej.
• Drugi, polega na mierzeniu czasu rozwiązania incydentów, powodujących niedostępność usługi biznesowej dla użytkowników.

W obu przypadkach należy pamiętać, o okresie za jaki liczona jest dostępność usługi biznesowej. Najczęściej liczymy ja za okres jednego miesiąca. Wynika to z okresu, za jaki rozliczamy się z biznesem, ze świadczenia danej usługi biznesowej

Narzędzie monitorowania dostępności

Opierając się na narzędziu monitorowania dostępności (np. Nagios), dostępność usługi biznesowej wyznacza się na podstawie dostępności poszczególnych usług systemowych/technicznych. Może to być prosta zależność, że niedostępność jednej usługi systemowej/technicznej oznacza niedostępność całej usługi biznesowej. Możemy skomplikować ten model i dodać wagi, określające wpływ usługi systemowej/technicznej na dostępność usługi biznesowej. Zastosowanie konkretnego rozwiązania zależy od złożoności usługi biznesowej i naszych potrzeb.

Ważnym zagadnieniem jest również czy mierzymy dostępność usług systemowych od wewnątrz, czyli z perspektywy IT. Czy od zewnątrz z perspektywy użytkownika końcowego. Oba sposoby mogą dawać znacząco różne wyniki dostępności usługi biznesowej.

Narzędzie klasy ITSM

Korzystając z narzędzia klasy ITSM, wyznaczamy czasy rozwiązania, dla poszczególnych incydentów, które powodowały niedostępność usługi biznesowej dla użytkownika. Suma czasów rozwiązania incydentów, wyznacza dostępność w % oraz niedostępność usługi biznesowej. Oczywiście oddzielnym zagadnieniem jest, jak liczony jest czas rozwiązania incydentu, ale o tym później.

Który sposób liczenia dostępności jest lepszy? Bardziej dokładna jest pierwsza metoda pomiaru, ponieważ mierzymy faktyczną niedostępność usługi biznesowej, niezależnie czy była czy nie była, wykorzystywana przez użytkownika. W drugiej metodzie mierzymy tylko tą niedostępność usługi biznesowej, widzianą z perspektywy użytkownika końcowego.

Pozostawiam czytelnikom do wyboru, która metoda jest dla nich bardziej odpowiednia.

Czas rozwiązania incydentu

Dla czasu rozwiązania incydentu należy określić jego początek i koniec. Liczenie czasu rozwiązania może zaczynać się od:

• otrzymania zgłoszenia przez I linię wsparcia
• przyjęcia zgłoszenia przez I linię wsparcia 
• potwierdzenia przez Service Desk przyjęcia zgłoszenia

Zakończenie liczenia czasu rozwiązania może być spowodowane przez:

• rozwiązanie incydentu przez zespoły wsparcia
• dostarczenie skutecznego rozwiązania do użytkownika
• wdrożenie rozwiązania na produkcję

Do Waszej rozwagi pozostawiam, który początek i koniec czasu rozwiązania powinno się wybrać .

Omówienie kolejnych parametrów SLA, opiszę w następnej publikacji.

Pytanie: Jak w Twojej organizacji wyznaczasz dostępność?

Artykuł Jak mierzyć parametry SLA – część 1 pochodzi z serwisu Mariusz Siek.