ITIL blisko nas czyli zarządzanie incydentami i problemami

Jadwiga Gnybek

W jednym z poprzednich wydań gazety omówiliśmy całokształt biblioteki ITIL. Ten jakże obszerny zbiór dobrych praktyk mających na celu organizację usług informatycznych, w wielu swoich fragmentach przebiega bardzo blisko zdarzeń, których jesteśmy bezpośrednimi uczestnikami.

Do zdarzeń takich z pewnością zaliczyć należy zarządzanie incydentami i problemami. Nie ma bowiem systemu informatycznego, w którym incydenty i problemy nie występują. Nie zawsze tylko mamy świadomość tego – jak widać solidnie ukonstytuowanego – zdarzenia. Przyjrzyjmy się więc nieco bliżej temu fragmentowi ITILa. Zacznijmy od pojęć podstawowych: czym jest incydent a czym problem.

Co to jest incydent?

Incydent to każde zdarzenie, które powoduje, lub może powodować przerwę w dostarczaniu usługi informatycznej zdefiniowanej na przykład jako dostępność lub wydajność systemu, czy określonej jego funkcjonalności. Przyczyną powstania incydentu może być na przykład uszkodzenie elementu infrastruktury IT. Incydentem jest zatem przerwa w działaniu serwera plików lub spadek wydajności serwera pocztowego poniżej poziomu zagwarantowanego umową, spowodowany jego awarią. Przyczyny incydentu mogą również leżeć po stronie oprogramowania, konfiguracji lub błędów w obsłudze.

Co to jest problem?

Problem to nieznana przyczyna jednego lub wielu incydentów. Idąc dalej tropem podstawnych definicji wprowadźmy jeszcze równie przydatne pojęcia takie jak:

  • Znany błąd zdefiniowany jako incydent lub problem, którego przyczyna wystąpienia jest znana i dla którego została zidentyfikowana tymczasowa, zastępcza droga postępowania (work-around) lub trwałe rozwiązanie.
  • RfC (Request for Change) czyli prośba o zmianę dowolnego elementu konfiguracji, procedury lub innego elementu związanego z infrastrukturą IT.

Ponieważ ITIL to podejście procesowe, mamy tu do czynienia z dwoma procesami przed którymi postawiono jasno sprecyzowane cele.

Celem procesu Zarządzania Incydentem

jest przywrócenie normalnego działania usługi, tak szybko, jak to możliwe, oraz minimalizowanie niekorzystnego wpływu incydentu na działanie biznesu. Tu nie ma miejsca na dociekanie przyczyn, tu stosuje się wypracowane, standardowe rozwiązania.

Proces Zarządzania Problemem

stawia przed sobą bardziej szczytny cel. Proces ten ma bowiem za zadanie minimalizowanie niekorzystnego wpływu incydentów i problemów oraz zapobieganie przed ponownym pojawieniem się incydentów. Aby to osiągnąć, uczestnicy procesu poszukują przyczyn występowania incydentów, a następnie podejmują działania zmierzające do trwałej naprawy sytuacji. Tak więc proces ten zawiera zarówno elementy reaktywne (wywoływane konkretną sytuacją awaryjną), jak i proaktywne, do których zaliczymy wszelkie działania prewencyjne podejmowane przed pojawieniem się incydentu lub problemu. I w tym bowiem przypadku powiedzenie „lepiej zapobiegać niż leczyć” znajduje swoje pełne potwierdzenie.

A po co to wszystko?

Bez względu na ilość użytych sił i środków, żadna organizacja nie jest w stanie zagwarantować całkowitej bezawaryjności eksploatowanych systemów informatycznych. Cóż nam zatem pozostaje? Minimalizować skutki, poprzez należyte przygotowanie się do usunięcia ew. awarii. Nasza praca to ciągła, niekończąca się wojna z czasem, pojawiającymi się jak Feniks z popiołów błędami i awariami systemu oraz oczekiwaniem użytkownika co do poziomu niezawodnej pracy systemu.

Na pierwszej linii tego frontu jest właśnie Zarządzanie Incydentami. W połączeniu z procesem Zarządzania Problemami tworzy zwarty i zamknięty cykl życia zlecenia (zgłoszenia incydentu / awarii).

Cykl życia zgłoszenia

Cykl życia zgłoszenia rozpoczyna się z chwilą powstania błędu w infrastrukturze lub funkcjonalności aplikacji, zaś swój koniec znajduje z chwilą dostarczenia systemowego rozwiązania. Na swojej drodze zgłoszenie spotyka zwykle procesy Zarządzania Incydentami, Problemami i Zmianą. Sygnał o awarii w infrastrukturze lub niepoprawnym działaniu funkcjonalności aplikacji (niezależnie czy pochodzi od użytkownika, czy też został wychwycony przez pracowników IT lub systemy monitorujące), powinien zostać rejestrowany w systemie obsługi zgłoszeń.

Tak właśnie rodzi się incydent.

Jego dalsze życie toczy się w rytm procesu Zarządzania Incydentami. Jeśli w chwili zarejestrowania incydentu nie jest znane jego rozwiązanie i musi ono zostać dopiero wypracowane, wówczas rejestrujący zgłoszenie ServiceDesk ogranicza się do odnotowania zaistniałego faktu. W sytuacji, gdy incydent spowodowany jest znanym i opisanym już błędem, zadaniem ServiceDesku jest również dostarczenie użytkownikowi systemu natychmiastowej pomocy – najczęściej w postaci tymczasowego obejścia nieprzyjemnej sytuacji lub takiego pokierowania użytkownikiem, aby wyeliminować negatywne skutki incydentu. Jest tak dlatego, że problemy nie wynikają z błędu aplikacji, a jedynie z niepoprawnej lub niepełnej procedury postępowania z nią.

Według metodyki ITIL, Service Desk powinien rozwiązywać nawet do 80% wszystkich zgłoszeń już podczas pierwszego kontaktu, bez eskalacji do innych zespołów zajmujących się wsparciem. Wynika to stąd, że identyfikując zaledwie 20% przyczyn opisujemy jednocześnie aż 80% możliwych do pojawienia się skutków.

Zawsze jednak pozostanie margines zgłoszeń których nie przewidziano, lub które nie poddają się opisowi. Te ostatnie będą przekazywane do procesu Zarządzania Problemem, aby stanowić przyczynek do jego rozwiązania. Przyczyną problemu może być jeden lub wiele incydentów. To właśnie stanowi naturalną ścieżkę łączącą cykl życia zgłoszeń-incydentów z procesu Zarządzania Incydentem (stanowiącego pierwsze sito wsparcia), z cyklem życia problemu, stanowiącego sedno procesu Zarządzania Problemem. To właśnie w tym procesie następuje diagnoza i identyfikacja przyczyn występowania incydentów. Znalezienie rozwiązania danej grupy incydentów powoduje zmianę jej statusu z problemu na znany błąd. A ze znanymi błędami już umiemy sobie radzić!

Co ważne, w ramach procesu Zarządzania Incydentami powinny być dostarczone rozwiązania dla znakomitej większości zgłoszeń. Stanowi to o randze tego procesu w organizacji. Jeżeli proces ten jest zorganizowany nieskutecznie, objawia się to lawiną problemów, które nie mają rozwiązań, a których naprawa wydaje się wymagać szybkiego działania. Stąd już prosta droga do nieprzygotowanych i nie przetestowanych zmian, które co prawda rozwiązują jeden problem, ale przy okazji generują kilka kolejnych. Podstawowym materiałem do działania w procesie Zarządzania Incydentami jest zatem Baza Wiedzy zawierająca uprzednio przygotowane, opisane i sprawdzone rozwiązania. Baza Wiedzy zawierać powinna również opis rozwiązań zastępczych, tzw. work-arounds. Rozwiązania te stosowane są w sytuacjach, gdy brak jest jeszcze dobrego trwałego rozwiązania. To trochę jak środek przeciwbólowy, który nie eliminuje przyczyn występowania incydentu, lecz chwilowo eliminuje wywołane przez incydent skutki.

Obsługa incydentu

Proces Zarządzania Incydentami ze swojej natury jest reaktywny. Aby reagować sprawnie i skutecznie, wymaga formalnych metod pracy, które mogą i powinny być wsparte narzędziami informatycznymi. Napędzające proces Incydenty pochodzą przede wszystkim ze zgłoszeń od użytkowników, przy czym nie ma prostej relacji: jedno zgłoszenie – jeden incydent. Bardziej złożone zgłoszenie może zaowocować zarejestrowaniem wielu incydentów. Możliwa jest również sytuacja, gdy mając do czynienia z kolejnym zgłoszeniem tego samego typu, powiążemy go z wcześniej zarejestrowanym incydentem. Z sytuacją taką możemy mieć na przykład do czynienia w przypadku awarii serwera pocztowego. Z dużym prawdopodobieństwem, w krótkim czasie dostaniemy lawinę telefonów dotyczących tej jednej kwestii. Aby nie rozpatrywać każdego z tych zgłoszeń oddzielnie, konieczna jest możliwość wiązania jednorodnych zgłoszeń w jedną grupę, dla której przygotowane zostanie wspólne rozwiązanie.

Proces Zarządzania Incydentami może również obejmować działania proaktywne, do których zaliczyć można monitorowanie sieci i systemów informatycznych. Działania te mają na celu wychwycenie potencjalnie groźnych sytuacji, zanim jeszcze dotkną one użytkownika. W praktyce proporcje pomiędzy obydwoma typami aktywności w sporym stopniu wskazują na dojrzałość organizacji. Nie jest łatwo bowiem zaakceptować koszty związane z realizacją zadań nie przynoszących konkretnych efektów w postaci imponujących statystyk przyjętych, zarejestrowanych i rozwiązanych zgłoszeń od użytkownika. Znacznie trudniej docenić działania, które wykonane z własnej inicjatywy dostarczają rozwiązań zapobiegających powstawaniu awarii.

Jednak i z tym nie można przesadzać! Proces Zarządzania Incydentami nie służy w zasadzie do realizacji działań prewencyjnych – jest to przede wszystkim proces wsparcia użytkownika i jego kłopotów w eksploatacji systemu. Dopiero w procesie Zarządzania Problemami działania proaktywne stają się priorytetem – to tam docieka się przyczyn występowania incydentów i opracowuje rozwiązania systemowe. Generalnie w procesie Zarządzania Incydentami na działania takie nie ma czasu. Tu nie ma miejsca na dociekanie przyczyn, tu stosuje się wypracowane, standardowe rozwiązania.

Struktura eskalacji w procesie Zarządzania Incydentami

Proces Zarządzania Incydentami nie ogranicza się tylko do pracowników pierwszej linii wsparcia, a więc ludzi bezpośrednio komunikujących się z użytkownikami za pomocą telefonu, czy poczty elektronicznej, a więc wspomnianego wcześniej ServiceDesku. Kolejne linie wsparcia tworzą zarówno jednostki działające w ramach naszej organizacji, jak i zewnętrzni dostawcy usług. Rozwiązanie incydentu może wszak wymagać wiedzy i uprawnień osób z kolejnych linii wsparcia. Z drugiej strony jednak, wiele czynności administracyjnych – takich, jak założenie konta, jego usunięcie, odblokowanie, czy zmiana parametrów – będzie wykonywana przez administratorów aplikacji, czyli na przykład pracowników jednostek biznesowych naszej organizacji. Czynności te bowiem – choć stosunkowo proste i powtarzalne – mogą wymagać uprawnień, których nie ma ani użytkownik, ani pracownik IT pierwszej linii wsparcia. Jeśli zaś do zamknięcia incydentu niezbędna jest głębsza ingerencja w system, incydent taki przekazany zostaje specjalistom. Mamy wtedy do czynienia z eskalacją poziomą lub funkcjonalną. W dowolnym momencie procesu możemy skorzystać również z eskalacji hierarchicznej. Eskalacja hierarchiczna może być np. pochodną reklamacji użytkownika lub wynikać z niestandardowej sytuacji, która wymaga niestandardowego postępowania. Eskalacja hierarchiczna jest przeznaczona do sytuacji wyjątkowych i zdecydowanie nie powinna być nadużywana. Wymaga ona bowiem odwołania się do bezpośredniego przełożonego lub osoby przez niego wyznaczonej do zamknięcia incydentu.

Klasyfikacja incydentu

Klasyfikacja incydentu jest najbardziej krytyczną czynnością w procesie Zarządzania Incydentami. To tutaj odpowiadamy na pytanie: Czego właściwie dotyczy dane zgłoszenie?

Klasyfikacja incydentu opiera się przede wszystkim o wywiad / rozmowę z użytkownikiem. Pomocą w klasyfikacji incydentu może być również Centralna Baza Konfiguracji (CMDB). Zawiera ona listę elementów infrastruktury IT i relacji zachodzących pomiędzy nimi. Głównym celem klasyfikacji incydentu jest powiązanie go z rozwiązaniem zapisanym w Bazie Wiedzy. Jeśli tego rozwiązania tam nie ma, to znaczy, że mamy do czynienia z sytuacją nową, dotychczas nierozpoznaną i nieopisaną. W praktyce oznacza to, że taki incydent trafia do procesu Zarządzania Problemami. W praktyce nie musi to wcale oznaczać przekazania zgłoszenia do innego zespołu. Zalecane jest jednak, by zespół zajmujący się incydentami mógł poświęcać na to większość swojego czasu. Jest bowiem rozliczany z szybkiego reagowania na zgłoszenia użytkownika i szybkiego dostarczania rozwiązań. Z kolei zespół zajmujący się problemami nie powinien być nadmiernie obciążany incydentami, by miał komfort psychiczny skupienia się na przyczynach występowania incydentów, identyfikacji incydentów powtarzających się najczęściej lub najbardziej dotkliwych dla organizacji, wreszcie opracowywaniu trwałych rozwiązań problemów.

Kolejnym nieodłącznym elementem klasyfikacji incydentu jest nadanie mu priorytetu.

Priorytet określa zwykle pracownik IT, do którego trafia zlecenie (pytanie o priorytet zgłoszenia, skierowane do użytkownika który je zgłosił, da łatwo przewidywalną odpowiedź). Zgodnie z biblioteką ITIL, przy nadawaniu priorytetu powinny być brane pod uwagę co najmniej dwa czynniki: wpływ incydentu na procesy biznesowe naszej firmy oraz jego pilność. Dla przykładu: zgłoszenie kluczowego użytkownika systemu informatycznego mającego problem ze stacją roboczą (zgłoszenie o wysokim wpływie na biznes) może zostać zarejestrowane z niską pilnością, jeżeli użytkownik wyjeżdża na dwutygodniowy urlop zaraz po zgłoszeniu incydentu. Oczywiście, priorytety nadajemy po to, by efektywnie zarządzać posiadanymi zasobami. Zazwyczaj mamy ich za mało, stąd konieczność podjęcia decyzji, czym się zajmiemy w pierwszej kolejności, a co zostanie odłożone na później.

Wdrożenie rozwiązania

Efektem prac prowadzonych przez proces Zarządzania Problemami jest zwykle opracowanie zbioru czynności niezbędnych do wykonania w systemie w celu definitywnego wyeliminowania przyczyny problemu, a więc przyczyny powstawania incydentów. Wdrożenie takiego rozwiązania do środowiska produkcyjnego może wymagać wykonania zmiany w infrastrukturze IT, na przykład: upgrade aplikacji do nowszej wersji, zmiany kodu w jednym z modułów systemu, instalacji patcha, zmiany typu pola w bazie danych, zwiększenia powierzchni dyskowej serwera lub postawienia backup’owego serwera itp. Aby w sposób profesjonalny i w pełni autoryzowany wykonać tego typu działania, z procesu Zarządzania Problemem wysyłany jest do procesu Zarządzania Zmianą tzw. RfC (prośba o zmianę). To właśnie ten proces odpowiada za prawidłową implementację każdej zmiany w produkcyjnym środowisku systemu informatycznego. Jeśli z jakiegoś uzasadnionego powodu organizacja (w tym przypadku reprezentowana przez proces Zarządzania Zmianą) odmówi wprowadzenia przygotowanej poprawki, nie pozostanie nam nic innego jak pozostawić znany błąd bez rozwiązania – w myśl zasady, że „ten typ tak ma”. Jeśli jednak uda nam się przekonać osoby odpowiedzialne za stabilną pracę systemu o konieczności dokonania poprawki, wówczas należy pamiętać, że każda wprowadzana w systemie zmiana powinna zostać odnotowana w CMDB (Bazie Konfiguracji), a udana jej implementacja spowoduje zamknięcie problemu, znanego błędu oraz wszystkich podpiętych incydentów!

Samo zamknięcie problemu i powiązanych z nim incydentów musi jednak wiązać się ze sprawdzeniem, czy wprowadzone zmiany rzeczywiście rozwiązały problem, czyli tzw. Post-Implementation Review (PIR). W przypadku drobnych incydentów może to oznaczać nic więcej jak telefon do użytkownika i upewnienie się, że jest zadowolony z rozwiązania. W przypadku bardziej złożonych problemów, konieczny będzie formalny przegląd, typowy dla projektów, gdzie sprawdzamy osiągnięcie zakładanych celów orz sposób ich osiągnięcia.

A co dzieje się z incydentami które nie znalazły rozwiązania?

Trafiają one do podprocesu Kontroli Problemu i Błędu! Jego zadaniem jest zidentyfikowanie przyczyn incydentów (root case analysis), dostarczanie informacji o takich przypadkach do ServiceDesku oraz przygotowanie rozwiązań tymczasowych, o ile takie są dostępne. Kontrola problemu jest więc bardzo podobna do procesu Zarządzania Incydentami. Kontrola problemu koncentruje się na przekształcaniu problemów w znane błędy.

I jeszcze tylko – jak to wdrożyć?

Dobre Zarządzanie Problemami zależy w dużej mierze od efektywności procesu Zarządzania Incydentami. Ponieważ te dwa procesy stanowią nieodłączny tandem, sensowne wydaje się wdrażanie obu tych procesów równolegle. Można również wyobrazić sobie scenariusz w którym w pierwszym etapie skupiamy się na implementacji procesu Zarządzania Problemami czyli kontroli problemu i błędu, a dopiero po osiągnięciu sukcesu w tym obszarze, rozszerzamy krąg zainteresowań o działania proaktywne. W drugim etapie prac rozpoczynamy zatem wdrażanie procesu Zarządzania Incydentami.

Na koniec o zapobieganiu zamiast leczenia

Co by na ten temat nie powiedzieć, kluczowym elementem procesu Zarządzania Problemami są działania, które nie są wymuszone koniecznością reakcji na zgłoszenia użytkownika. W ramach działań proaktywnych należy wyróżnić przede wszystkim identyfikowanie i śledzenie trendów oraz przegląd kluczowych problemów systemu. Analizując takie dane możemy niejednokrotnie natknąć się na problemy, które nie zostały wcześniej dostrzeżone i rozwiązane. Problemy, które w dogodnych okolicznościach przyrody na pewno dadzą o sobie znać.

Proaktywne zarządzanie problemem nie musi koniecznie być zadaniem pełnoetatowym. W mniejszych organizacjach wystarczającym może być przydział pracowników wsparcia jedynie na okres na przykład dwóch tygodni w ciągu półrocza, do analizy zebranych w tym czasie danych dotyczących incydentów i problemów.