Kategorie szkoleń | Egzaminy | Kontakt
  • 3
  • 2
  • 1.3K
Komentarze (2)
Dostępność systemu dotyczy dostępności w Gwarantowanym czasie świadczenia usługi, a więc przerw na okna serwisowe nie wliczamy.
Skomentował : @ Marek_Prasol_10K1 ,28.03.2019
  • 2
  • 0
  • 0
Gwarantowany czas świadczenia usługi [%] = 100% - dopuszczalna niedostępność usługi (w gwarantowanym czasie świadczenia usługi) [%]

Czas niedostępności usługi [%] = Gwarantowany czas świadczenia usługi [%] – niedostępność usługi w gwarantowanych czasie świadczenia usługi [%]

Dostępność usługi = Gwarantowany czas  świadczenia usługi [%] – Czas niedostępności usługi [%]
Skomentował : @ Marek_Prasol_10K1 ,28.03.2019
  • 2
  • 0
  • 0

Odpowiedzi (3)

  • 17

Witam.

Pani Karolino, na wstępie krótko: moim zdaniem jeżeli porozumienie (zobowiązanie) SLA tego inaczej nie precyzuje, przyjąłbym, że usługodawca gwarantuje 98% z uzgodnionego (po  odjęciu ewentualnych przerw technicznych i biorąc pod uwagę godziny świadczenia) czasu świadczenia usługi, 2% pozostawia sobie na sytuacje nieprzewidziane. Oczywiście  nie znam usługi, nie widziałem zapisów porozumienia, więc jest to trochę w ciemno.

Przykład 1

Umawiamy się z usługodawcą, że usługa ma być dostępna od godziny 8:00 do godziny 18:00 w dni powszednie tzw. pracujące.

Dodatkowo w tym czasie usługodawca rezerwuje sobie np. 2 godzinne przerwy techniczne, z zastrzeżeniem, że powiadomi o nich z wyprzedzeniem 50 godzin czasu świadczenia usługi i nie będą to 3 ostatnie dni miesiąca ani dwa pierwsze (gorący okres np. w dziale finansowym lub kadry-płace).

W kwietniu 2014 mamy 20 dni pracujących (30 dni w miesięcy, 2 dni świąt, w tym jedno przypadające w niedzielę do odbioru). Mamy zatem 20 x 10 = 200 godzin świadczenia usługi w tym miesiącu.

W każdym miesiącu usługodawca gwarantuje sobie 2 godziny techniczne, stąd mamy 198 godzin jako bazę – to jest gwarantowany czas świadczenia usługi w kwietniu 2014.

Tę gwarancję jest w stanie usługodawca zrealizować z 98% prawdopodobieństwem (wyszło mu to na bazie metody historycznej, analitycznej lub tzw „eksperckiej” – o tym szerzej na szkoleniu).

Tak więc, 2% z 198 to 3,98 (dziesiętnie) godziny (jest to 3 godzinny i 58,8 minuty). Jeżeli w miesiącu wydarzą się 3 godzinne awarie związane z niedostępnością usługi, jesteśmy jeszcze w granicach SLA. Jeżeli takich awarii było 5, przekroczone zostały parametry SLA.

Przykład 2

Usługa jest świadczona 24 godziny na dobę cały miesiąc. Usługodawca gwarantuje sobie jedną 4 godzinną przerwę i 98% dostępności usługi. Jedyne zastrzeżenie jest, że przerwa techniczna nie odbywa się w godzinach 18:00 do 23:00 (np. usługi typu telewizja kablowa). Też bym w takim przypadku przyjął, że gwarantowany (bazowy) czas świadczenia to 30*24 – 4 godziny, co daje: 716 godzin,z czego 2% to 14,32 godziny na nieprzewidziane awarie ( około 14 godzin i 20 minut).

Dobre praktyki ITIL(R)

Co do dobrych praktyk – dobrą praktyką ITIL® jest to, aby porozumienie SLA pomiędzy usługodawcą i usługobiorcą było jednoznaczne i jasne dla obu stron. To jest m.in. celem takich logicznie powiązanych zbiorów działań (czyli procesów) jak Service Level Management, Business Relationship Management, a w wypadku dostępności Availability Management.

Warto tutaj zwrócić silnie uwagę samo pojęcie SLA. Niestety, niefortunnie od wielu wielu lat funkcjonuje ono w języku polskim pod tłumaczeniem „umowa”. A umowa kojarzy się nam z umową w formie prawnej. Po angielsku to będzie jednak „contract”.

Service Level Agreement to porozumienie się usługodawcy i usługobiorcy co do tzw. poziomów świadczenia usługi – czyli jej parametrów. Parametry mogą być z obszarów dostępności, ciągłości, bezpieczeństwa i wiele innych.

ITIL wskazuje, że powinny one być jednoznacznie zrozumiałe dla obu stron, nie powinny być spisane językiem prawnym ani technicznym. O to powinny zadbać po stronie usługodawcy w/w procesy.

Oczywiście, jeżeli stosunek między usługodawcą a usługobiorcą dotyczy prawa handlowego, to za uzgodnieniem parametrów (czyli SLA) powinna iść też umowa prawa handlowego – wtedy SLA może być załącznikiem do takiej umowy. Nie mylmy jednak SLA z umową np. cywilno-prawną.

Co do samej dostępności – stosowany parametr procentowy (np. 98%) dotyczy zwykle pozostawienia sobie czasu na nieprzewidziane zdarzenia, biorąc pod uwagę analizę ryzyk, którą zapewne dokonał usługodawca.

 

 

 

Negocjując porozumienie SLA, warto wziąć pod uwagę również takie parametry jak gorące okresy, szybkość przywrócenia usługi itp.:

Niezawodność (Reliability) - zdolność zapobiegania awariom i umiejętność zapewniania ciągłości świadczenia usług, bez przestojów.

Możliwość utrzymania (Maintainability) - zdolność do przywracania usługi po awarii do stanu normalnego działania.

Możliwość świadczenia usług (Serviceability) - wsparcie, którego udzielają związani umowami dostawcy zewnętrzni, dostarczający komponenty infrastruktury IT.

W niektórych porozumieniach pojawiają się czasem zapisy dotyczące częstotliwości występowania awarii (np. nie częściej niż co 10 godzin w uzgodnionym czasie świadczenia). Ten i powyższe parametry, oczywiście, wynikają z Planu Ciągłości Usług IT, a ten wynika z Planu Ciągłości Biznesu.

Przykład uzgodnień dotyczących dostępności usługi (nazwijmy to SLR).

Proszę zwrócić uwagę, jak definiujemy usługę - nie dostarczenie systemu, ale danie wartości procesowi biznesowemu. W ITIL-u  raczej nie dostarczamy odbiorcy infrastruktury czy aplikacji, lecz usługi. A usługa to dostarczenie wartości.

Usługa jest zdefiniowana jako danie grupie pracowników działu finansowego możliwości wykonywania raportów finansowych oraz przeprowadzania analiz (wykaz raportów i analiz w załączniku).

Poziom gwarancji

Każdy pracownik ma zagwarantowane z ustalonymi parametrami (poniżej) dostęp do urządzenia, na którym pracuje aplikacja, dostęp do sieci, utrzymanie poziomu umiejętności korzystania z aplikacji (itp., itd., tutaj może być wiele zapisów związanych z bezpieczeństwem, ciągłością, wsparciem dostawców).

Po negocjacjach i rozpoznaniu potrzeb usługobiorcy oraz możliwości usługodawcy uzgodniono, że:

 

  • Usługa powinna być dostępna w dni pracujące w godzinach 6:00 – 23:00
  • Usługobiorca dodatkowo wymaga, aby okres każdego ostatniego tygodnia miesiąca był potraktowany priorytetowo.
  • Usługodawca rezerwuje sobie 1 godzinną przerwę serwisową poza okresem priorytetowym, o której poinformuje do 30 godzin wcześniej.
  • Powyższa uzgodniona dostępność usługi zagwarantowana jest przez usługodawcę w 98%, biorąc pod uwagę nieprzewidziane awarie i inne problemy techniczne.
  • Usługodawca gwarantuje, że rozpocznie działanie, zmierzające do wyeliminowania awarii bezzwłocznie od momentu poinformowania go o zaistniałej niedostępności. Centrum zgłoszeń niedostępności czynne jest w gwarantowanym czasie świadczenia usługi (dni pracujące 6:00 - 23:00). Sposób kontaktu (telefon, email itp.) podany został w załączniku.
  • Usługodawca gwarantuje, że awarie związane z dostępnością usługi:
    • W okresie priorytetowym: nie więcej niż jedna awaria, w której czas przywrócenia usługi nie będzie dłuższy niż jedna godzina.
    • W pozostałym okresie: awarie przywracane będą w czasie nie dłuższym niż 2 godziny każda, zaś czas pomiędzy awariami  (od zakończenia jednej do rozpoczęcia następnej) nie będzie krótszy niż 5 godzin.

 

Później jest to przekładane na konkretny zbiór parametrów SLA.

Jak widać, porozumiewając się w celu uzgodnienia parametrów SLA, możemy żonglować wieloma parametrami, gorącymi okresami – wszystko z jednej strony wynika z potrzeb biznesu, z drugiej z potencjału wykonawczego organizacji świadczącej usługi IT.

Jeszcze jedna uwaga: czasy reakcji, szybkość przywrócenia - to parametry związane z procesami wsparcia (zwykle incydent, problem, change management). Są to bardzo ważne parametry, niemniej SLA to zwykle szerszy zbiór parametrów, dotyczący jako takiego dostarczania usługi.

Druga uwaga: w SLA powinny się też znaleść informacje o sposobach kontaktu, ścieżkach eskalacji itp., itd.

I jeszcze jedna uwaga: rozpatrując usługę nieinfrastrukturalnie (czyli nie dostarczamy systemu, aplikacji lecz wartość), parametry SLA powinny objąć wszystkie elementy związane z tą wartością np. kwestie umiejętności korzystania przez pracownika z narzędzia, kwestie sprzętu, sieci itp., itd. Nie chodzi bowiem o to, aby dać wędkę, lecz umożliwić łowienie ryb - sama wędka bez umiejętności, przynęty itp.  nie da żadnej wartości odbiorcy.

Wracając do samych parametrów dostępności...

Oczywiście w złej praktyce na rynku mogą się przytrafić podmioty, które celowo będą tak przygotowywać parametry, aby zaciemnić obraz albo wyeliminować własne ryzyka. Nie jest to jednak dobra praktyka ITIL-owa. Celem zarządzania usługami ( i ITIL-a) m.in. jest to, aby zapewnić przejrzystość oraz uczciwość organizacji, świadczącej te usługi dla odbiorcy.

Podsumowując:

Dobrą praktyką byłoby w przypadku, który Pani podała, renegocjowanie porozumień SLA tak, aby parametry były jasne i zrozumiałe dla obu stron.

Pozdrawiam.
Paweł Dąbrowski.

  • Odpowiedział
  • @ | 14.04.2014
  • TRENER MODERATOR ALTKOM AKADEMII
  • 1

Ciekawe opracowanie na kanwie, którego przypomniał mi się ciekawy aspekt.

Co to jest ta "dostępność"?

Bez jej zdefiniowania dla każdej usługi pojawia się ryzyko rozjechania się oczekiwań klienta i oceny dostawcy. Otóż dla przykładu bowiem IT deklaruje 99% dostępności miesięcznie w kalendarzu 24 godziny na dobę, co z grubsza patrząc, jest wysoką dostępnością. 30 dni w miesiącu po 24 godziny daje 720 godzin. IT obiecuje, że niedostępność nie będzie dłuższa niż 7,2 godziny w miesiącu. W ciągu roku to zaledwie 87,6 godziny, trzy i pół doby. Nieźle jak za taką cenę – ocenia klient. Dlaczego więc po dwóch miesiącach zaczynają się schody? IT przedstawia cykliczne raporty, z których wynika, że dostępność zawsze jest powyżej 99%, a klient od swoich użytkowników wysłuchuje skarg i narzekań, że usługa ciągle nie działa.

Otóż dla IT dostępność usługi to czas, w którym wszystkie serwery (aplikacyjny, bazodanowy) działają. Przecież w monitoringu wszystko jest na zielono, więc o co pretensje. Użytkownicy zaś chcą działania wszystkich lub co najmniej kluczowych funkcji w usłudze. Możliwość zalogowania się nie wystarczy. ;)

Sama karta usługi musi opisywać, jak definiowana i jak mierzona jest „dostępność”. Definicja dla wszystkich klientów musi być precyzyjna i akceptowalna. IT musi rozumieć potrzebę klienta i jeśli nie posiada narzędzi monitorujących całą usługę, a nie tylko wybrane elementy konfiguracji, to bezpieczniej jest np. oprzeć się w pomiarze na rejestrze incydentów. Ale i tu musi być precyzyjna definicja, zaakceptowana przez klienta. Dla przykładu – kiedy usługa e-mail jest dostępna, a kiedy przestaje być dostępna? Dla jednych ważniejsze jest odbieranie wiadomości, dla drugich wysyłanie, a dla innych dostęp do archiwum wiadomości.

Reasumując, ważniejsze od podkręcania liczby dostępności jest uzgodnienie jej definicji i metody pomiaru.

 

Na marginesie - im mniej precyzyjne pytanie, tym dłuższa odpowiedź. ;)

 

Hubert_Bedyk
  • Odpowiedział
  • @ Hubert_Bedyk | 26.10.2014
    • 2
    • 0
    • 1
  • 0

Gwarantowany czas świadczenia usługi [%]100% - dopuszczalna niedostępność usługi (w gwarantowanym czasie świadczenia usługi) [%]

Czas niedostępności usługi [%] = Gwarantowany czas świadczenia usługi [%] – niedostępność usługi w gwarantowanych czasie świadczenia usługi [%]

Dostępność usługi = Gwarantowany czas  świadczenia usługi [%] – Czas niedostępności usługi [%]

 

Marek_Prasol_10K1
  • Odpowiedział
  • @ Marek_Prasol_10K1 | 28.03.2019
    • 2
    • 0
    • 0