Prosto o ITIL – Od czego zacząć wdrażać ITIL? – część 2

Podziel się

W pierwszej części opisałem cztery praktyki od których warto zacząć swoją podróż z ITIL: zarządzanie katalogiem usług, zarządzanie poziomem świadczenia usług, service desk i zarządzanie incydentami. Na początek mogą wystarczyć ale od początku należy planować wykorzystanie kolejnych praktyk.

ITIL 4 bardzo mocno podkreśla znaczenie strumieni wartości usług, które wykorzystują wiele, różnych praktyk. Jedna praktyka nie może dostarczyć wartości dlatego trzeba korzystać z wielu, powiązanych ze sobą praktyk.

Jeżeli spojrzymy na strumień wartości „przywrócenie usługi do działania”, to wspomniane cztery praktyki są niewystarczające. Kolejną praktyką, jaką należy „wdrożyć” jest zarządzanie konfiguracją usług.

Zarządzanie konfiguracją usług

Jedna z ważniejszych praktyk, która pomaga rozwiązywać incydenty i problemy oraz wprowadzać zmiany. Jest to praktyka „backendowa”, ponieważ nie korzystają z niej praktyki taki jak zarządzanie incydentami i problemami oraz umożliwianie zmian.

Obejmuje elementy konfiguracji (Configuration Item – CI) oraz bazę zarządzania konfiguracjami (Configuration Management Database – CMDB), w której zawarte są wszystkie elementy konfiguracji oraz relacje pomiędzy CI.

Te informacje są bezcenne do:

  • Określenia kategorii incydentu i problemu, czyli wskazania do jakiej grupy wsparcia zgłoszenie ma być skierowane. Mówiąc prościej kto ma rozwiązać incydent lub problem.
  • Zdiagnozowania i rozwiązania incydentów, wykorzystując model/mapę usługi można szybko i skutecznie weryfikować jak nie działanie jednego elementu konfiguracji wpływa na inne elementy konfiguracji w tym na usługę.
  • Badania przyczyn źródłowych problemów, które mogą być złożone nie było by możliwe bez informacji o elementach konfiguracji i zależnością między nimi. Współpraca wielu zespołów może być wymagana aby rozwiązać problem.
  • Wprowadzania zmian zakończonych sukcesem, jest tylko możliwe, jeżeli wiadomo jak zmiana jednego elementu konfiguracji wpływa na inne elementy konfiguracji i usługi.

Jednym słowem jeżeli nie masz CMDB z odpowiednimi informacjami to dłużej rozwiązujesz incydenty, przez dłuższą diagnozę i przekazanie do właściwego zespołu wsparcia, więcej czasu zajmu Ci badanie przyczyny źródłowej błędu/problemu i masz większe ryzyko, że źle oceniłeś zmianę i mniejsze prawdopodobieństwo, że wdrożysz ją prawidłowo.

Zarządzanie problemami

Praktyka zarządzania problemami została już wywołana do odpowiedzi przy okazji zarządzania konfiguracją usług. Jeżeli mamy już wdrożoną praktykę zarządzania incydentami i chcemy aby było mniej incydentów, to musimy zacząć rozwiązywać problemy. W każdej usłudze, systemie, aplikacji były, są i będą błędy. Nie ma usług bez błędów, dlatego tak ważne jest aby identyfikować potencjalne źródła problemów rejestrować je i rozwiązywać.

Problemy to zagadnienia bardziej złożone niż incydenty dlatego do ich obsługi powinny włączyć się wszystkie zespoły w organizacji. Wymagana jest współpraca pomiędzy wieloma interesariuszami aby znaleźć przyczynę źródłową oraz rozwiązanie problemu. Zidentyfikowane i zarejestrowane problemy oraz znane błędy łączymy z incydentami.

Praktyka zarządzania problemami opracowuje obejścia (workaround) dla incydentów i udostępnia je praktyce zarządzania incydentami, najlepiej poprzez bazę wiedzy. Jeżeli zarządzanie incydentami nie może samodzielnie rozwiązać incydentu, może wspierać się zarządzaniem problemami, które pomaga opracować i dostarczyć rozwiązanie incydentu.

Umożliwianie zmian

Rozwiązując incydent lub problem może się okazać, że wymagane jest wdrożenie zmiany. Wtedy należy złożyć wniosek o zmianę (Request of change – RfC) czyli skorzystać z praktyki umożliwiania zmian. Każda zmiana związana jest z ryzykiem i każda zmiana wymaga autoryzacji, akceptacji. W przypadku incydentów możemy potrzebować realizacji zmiany pilnej a w przypadku problemów powinniśmy korzystać ze zmiany normalnej, którą planujemy w harmonogramie zmian.

Nie możemy wprowadzić żadnej zmiany na środowisko produkcyjne, jeżeli nie „przejdzie” ona przez praktykę umożliwiania zmian, która jest policjantem pilnującym aby wprowadzanie zmiany nie zaburzały produkcyjnie działających usług.

Do pełnego wdrożenia zmiany na produkcji potrzebujmy jeszcze praktykę zarządzania wdrażaniem, która odpowiada za przeniesienie komponentów do środowiska produkcyjnego i wydaniem, która pozwala udostępnić usługę lub funkcjonalność użytkownikom.

Zarządzanie wnioskami o usługę

Na koniec praktyka, która dotyczy normalnego świadczenia usług, nie incydenty, nie problemy, czyli zarządzanie wnioskami o usługę. Tą praktykę bardzo często organizacje wdrażają aby obsługiwać zmiany standardowe, które są dobrze znane i sprawdzone. Wnioski o usługę udokumentowane są w katalogu wniosków o usługę, który jest częścią katalogu usług, obsługiwanego przez praktykę zarządzanie katalogiem usług. Pamiętamy, że wnioski o usługę związane są z konkretnymi usługami i powstają na etapie tworzenia usługi, tak aby mogły być odpowiednio przetestowane i sprawdzone. Ponieważ wnioski o usługę realizowane są na podstawie procedur, ich czas wykonania można określić, tak aby użytkownik, składając wniosek, wiedział jak długo będzie czekał na realizację.

Jeszcze zostało kilka ważnych praktyk więc dokończę ich opis w części trzeciej.


Podziel się

Discover more from Mariusz Siek

Subscribe to get the latest posts sent to your email.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.