Dla większości osób zaznajomionych z terminologią stosowaną w bibliotece ITIL terminy takie jak 'incydent’, 'problem’, 'znany błąd’, czy 'obejście’ są dobrze znane. Jak się jednak okazuje dla pozostałych same definicje mogą być mało czytelne. Dlatego też jako uzupełnienie mojego poprzedniego wpisu („Czy SCRUM nadaje się do projektów utrzymaniowych„) przygotowałem krótki artykuł objaśniający znaczenie tych pojęć, oraz przykład, który to zilustruje.
Definicje
[jeśli nie lubisz definicji to kliknij TUTAJ 🙂 ]
Zacznijmy zatem od definicji wziętych wprost z ITIL v3 2011 (w wersji 4 nie uległy one znacznym zmianom):
Incydent
Incydent (ang. Incident) – nieplanowana przerwa w usłudze informatycznej lub obniżenie jej jakości. Awaria elementu konfiguracji (CI), który nie wpłynął jeszcze negatywnie na usługę również jest incydentem.
Poważny Incydent (ang. Major Incident) – najwyższa kategoria wpływu incydentu. Poważne incydenty w istotnym stopniu zakłócają działanie organizacji biznesowej, dlatego też wymagają: odrębnych (bardziej efektywnych) procedur obsługi, krótszych czasów rozwiązania, najwyższego priorytetu.
Model incydentu to powtarzalne podejście do zarządzania konkretnym typem incydentu.
Obejście (work-around)
Obejście (ang. Workaround) – zmniejszenie lub wyeliminowanie wpływu incydentu lub problemu, którego pełne rozwiązanie nie jest jeszcze dostępne – na przykład, przez restart niedziałającego elementu konfiguracji (CI).
Obejścia dla problemów są dokumentowane w Bazie Znanych Błędów (ang. Known Error Database, KEDB). Obejścia dla incydentów, które nie posiadają związanych z nimi Rejestrów Problemów, są dokumentowane w Rejestrze Incydentów.
Problem
Problem (ang. problem) – przyczyna jednego lub wielu incydentów.
Przyczyna nie zawsze jest znana w chwili rejestrowania (zapisu) problemu.
Proces zarządzania problemami jest odpowiedzialny za dalsze badania i diagnozę.
Znany błąd
Znany błąd (ang. known error) – problem, który ma udokumentowaną przyczynę źródłową i obejście.
Znane błędy są rejestrowane i zarządzane przez proces zarządzania problemami w trakcie całego ich cyklu życia. Znane błędy mogą być również identyfikowane przed programistów lub dostawców.
Procesy związane z incydentami i problemami
Żeby lepiej zrozumieć powyższe definicje, zobaczmy jakie są cele procesów związanych z zarządzaniem incydentami i problemami:
Zarządzanie Incydentami – proces odpowiedzialny za zarządzanie cyklem życia wszystkich incydentów.
Zarządzanie Incydentami zapewnia, że przywrócenie usługi informatycznej odbiorcom nastąpi tak szybko jak to tylko możliwe. Zarządzanie Incydentami zapewnia również minimalizowanie wpływu incydentów na biznes. Zarządzanie Incydentami NIE ZAJMUJE SIĘ ustalaniem przyczyn wystąpienia incydentów.
Zarządzanie problemami – proces odpowiadający za zarządzanie cyklem życia wszystkich problemów.
Prewencyjnie zapobiega powstawaniu incydentów oraz minimalizuje wpływ incydentów, którym nie można zapobiec.
Cele tego procesu to m.in.: wyjaśnienie źródłowych przyczyn każdego incydentu, znalezienie rozwiązania (wyeliminowanie źródłowych przyczyn), wyeliminowanie powtarzających się incydentów i problemów, dostarczanie rozwiązań poprzez publikację w Bazie Znanych Błędów (KEDB).
Zarządzanie Problemem NIE ZAJMUJE SIĘ przywracaniem usługi użytkownikowi.
Gdybyśmy zatem mieli określić relację pomiędzy incydentami a problemami to można to ująć następująco:
Incydent jest skutkiem (objawem) występowania problemów, podczas gdy problem zawsze oznacza przyczynę incydentu bądź incydentów.
Przykład
Łatwiej będzie nam przenieść powyższe definicje na grunt projektu programistycznego, jeśli rozważymy prosty przykład:
Załóżmy, że mamy działającą aplikację webową, z której korzystają pracownicy firmy. System jest objęty umową SLA (gwarantowaną przez wewnętrzne IT, lub dostawcę zewnętrznego- nie ma to większego znaczenia dla rozważanego przykładu). Parametry czasów reakcji dla tej umowy SLA przedstawia tabelka poniżej:
Któregoś dnia aplikacja przestaje być dostępna dla użytkowników – przy próbie zalogowania do systemu pojawia się błąd 500. Użytkownicy zgłaszają tą sytuację do Service Desk, np. przez stworzenie zgłoszenia w systemie ITSM (np. Jira Service Desk, BMC Remedy, HP Service Desk czy podobny) – od tego momentu rozpoczyna się bieg czasu reakcji (reaction time). Kolejne zgłoszenia dotyczące tego samego zdarzenia powinny być zgrupowane w jeden rekord (jako incydent masowy, gdyż dotyczy wielu użytkowników), a ponieważ system ten jest istotny z punktu widzenia ciągłości działania firmy mamy do czynienia z Poważnym Incydentem (nie każdy incydent masowy musi być incydentem poważnym – np. awaria intranetowego forum miłośników sportu może dotknąć wielu użytkowników, ale nie zagraża ciągłości działania organizacji). W związku z tym incydent otrzymuje też najwyższy priorytet (oznaczany w systemach jako P1, krytyczny itp).
W momencie gdy pracownik I linii wsparcia (zwykle nazywanym w organizacjach jako Service Desk, Support, Help Desk), lub osoba pełniąca dyżur (on-call, pager duty) podejmuje te zgłoszenie i przystępuje do próby jego rozwiązania zatrzymujemy czas reakcji i rozpoczynamy bieg czasu rozwiązania (resolution time). [uwaga – czasami czas rozwiązania jest mierzony od momentu zgłoszenia incydentu przez użytkownika, a nie jego podjęcia przez I linię – zależy to od zapisów w umowie SLA, ale takie podejście jest mniej korzystne dla świadczącego usługę wsparcia IT]
W powyższym przykładzie Service Desk ma 2 godziny robocze na odebranie zgłoszenia i podjęcia prób jego rozwiązania (ponieważ I linia wsparcia pracuje w tym wypadku w reżimie 24/7 oznacza to także 2 godziny zegarowe). Przy bardzo restrykcyjnych umowach SLA czas reakcji wynosi czasami 30 czy nawet 15 min.
Załóżmy że pracownicy Service Desk po raz pierwszy stykają się z taką sytuacją i nie wiedzą w jaki sposób rozwiązać te zgłoszenia – incydent jest więc bezzwłocznie eskalowany do kolejnej linii wsparcia (administratorów systemów informatycznych). Może nastąpić też eskalacja hierarchiczna – informację o awarii otrzymują też odpowiedni kierownicy, dyrektorzy itp. (jeśli kluczowy system informatyczny jest niedostępny przez dłuższy czas może zajść konieczność uruchomienia procedur awaryjnych – np. papierowej ewidencji spraw, lub też całkowitego wstrzymania świadczenia usługi dla klientów do czasu przywrócenia działania aplikacji).
Pracownicy drugiej linii wsparcia IT analizują przyczyny niedostępności systemu i załóżmy, że zaobserwowali całkowite wykorzystanie pamięci operacyjnej na serwerach aplikacyjnych. Przyczyna tego zdarzenia nie jest jeszcze znana, natomiast w ramach działań zmierzających do jak najszybszego przywrócenia usługi IT zostaje podjęta decyzja o restarcie serwerów aplikacyjnych (czyli klasyka klasyk – „Proszę wyłączyć i włączyć„). Po ponownym uruchomieniu serwerów wszystko wraca do normy – aplikacja działa poprawnie dla użytkowników końcowych – można zamknąć incydent i poinformować użytkowników, że awaria została usunięta (’przyzwoite’ systemy ITSM wyślą takie powiadomienie automatycznie 🙂 W tym momencie kończymy także mierzenie czasu rozwiązania – ponieważ został dostarczony work-around który zadziałał.
Należy też udokumentować obejście w Rejestrze Incydentów (nie robimy jeszcze wpisu w Bazie Znanych Błędów, gdyż przyczyna tego incydentu nie jest znana).
Rozwiązanie i zamknięcie incydentu nie kończy jednak tematu – niedostępność systemu została przez coś spowodowana, należy zatem ustalić przyczynę i jeśli to możliwe usunąć ją, żeby zapobiec podobnym zdarzeniom w przyszłości. Tutaj właśnie uruchamiamy proces zarządzania problemem oraz rozpoczynamy mierzenie czasu dostarczenia rozwiązania docelowego (root cause fix time). [Uwaga jak powyżej – w zależności od zapisów w konkretnej umowie SLA ten czas może być także mierzony od momentu zgłoszenia incydentu, bądź jego podjęcia przez I linię]
Do znalezienia przyczyn źródłowych problemu oraz jego rozwiązania zwykle powołuje się zespół interdyscyplinarny składający się np. z administratorów systemów IT, developerów itd. Wśród wykorzystywanych narzędzi/metod można wymienić analizę logów aplikacyjnych i systemowych, próby odtworzenia błędu na środowisku testowym, monitoring systemu itp. Bardzo często samo znalezienie przyczyn źródłowych jest zadaniem bardzo czasochłonnym i nie zawsze możliwym – zdarzają się sytuacje, gdzie stwierdzamy, że incydent był spowodowany jakimś randomowym zdarzeniem w systemie i jedyne co można zrobić to obserwować czy awaria się nie powtórzy (można np. dołożyć dodatkowe monitorowanie, albo odpowiednio ustawić alarmy, żeby wsparcie IT było wcześnie powiadomione o problemie).
Załóżmy jednak, że w omawianym przykładzie udało się dociec przyczyny awarii – użytkownicy w tym dniu wywołali wielokrotnie rzadko używaną funkcję, która zawiera błąd powodujący wyciek pamięci i w konsekwencji zajęcie całej dostępnej pamięci operacyjnej na serwerach aplikacyjnych, co skutkuje niedostępnością systemu. W związku z tym, że problem leży po stronie kodu aplikacji (a nie np. infrastruktury) należy dodać do rejestru produktu odpowiedni wpis (może to być np. issue typu bug w JIRA). W tym miejscu warto wspomnieć, że jeśli dostarczenie rozwiązania docelowego jest również objęte reżimem SLA, to zespół developerski powinien mieć opracowane odpowiednie procedury postępowania z takimi bugami (moje rozważania w tym obszarze możesz przeczytać w tym artykule).
Znalezienie i udokumentowanie przyczyny źródłowej pozwala nam dokonać wpisu do KEDB (patrz definicje powyżej). W idealnym świecie należałoby teraz przystąpić do usunięcia przyczyny źródłowej, czyli poprawienia kodu wadliwej funkcji. Nie zawsze jest to możliwe – czasami jest to legacy code, do którego brakuje dokumentacji, a osoby które to pisały dawno już nie pracują w organizacji. Problem może dotyczyć zewnętrznej biblioteki, która nie jest już wspierana lub koszty przepisania takiego fragmentu kodu mogą być po prostu bardzo wysokie. Czasami rozwiązaniem może być wprowadzenie jakiegoś obejścia – np. ograniczenie ilości użytkowników uruchamiających wspomnianą funkcję systemu, dodanie dodatkowego monitorowania itp.
Jeśli w omawianym przypadku udałoby się poprawić występujący w oprogramowaniu błąd można również zakończyć bieg czasu dostarczenia rozwiązania docelowego oraz zamknąć rekord problemu w systemie ITSM. Oczywiście warto jeszcze zrobić analizę ’post-mortem’, która może pomóc w wyciągnięciu wniosków na przyszłość i uniknięcia podobnych awarii (proces zarządzania problemami zajmuje się zarówno działaniami reaktywnymi jak i proaktywnymi/prewencyjnymi). Jednym z wniosków mogłoby być przeznaczenie min. 20% czasu developerów pracujących nad rozwojem systemu na prace maintenance i stopniowy refactoring legacy code.