Close

Zarządzanie incydentami dla dynamicznych zespołów

Realizacja procesu zarządzania incydentami jak specjalista ds. eksploatacji IT

Autor: Nick Wright, menedżer ds. eksploatacji usług w Atlassian

Pozwólcie, że na początek powiem coś, co leży mi na sercu: ludzie pracujący na pierwszej linii wsparcia są cichymi bohaterami każdej firmy.

Każdej firmy.

Naprawdę uważam, że wsparcie techniczne należy uznać za branżę usługową, a klienci powinni mieć możliwość pozostawienia napiwku agentom, którzy zapewniają doskonałą obsługę. Gdybym tylko mógł, z radością dawałbym napiwek każdemu świetnemu pracownikowi działu wsparcia, który szybko — i z uśmiechem na twarzy — rozwiązał moje problemy.

Ale odchodzimy od tematu. Jeśli to czytasz, oznacza to, że prawdopodobnie zarządzasz zespołem pomocy technicznej lub jesteś jego członkiem. I prawdopodobnie akurat pali Ci się grunt pod nogami. Parzy w stopy. A zapach też nie należy do przyjemnych. Zróbmy więc coś z tym i odzyskajmy kontrolę nad Twoim procesem zarządzania incydentami IT.

Zanim przejdziemy do szczegółów zarządzania incydentami, wyjaśnijmy sobie podstawową powszechnie używaną terminologię.

ITSM a zarządzanie incydentami

Jeśli pracujesz w dziale IT, prawdopodobnie znasz pojęcia ITIL, ITSM, incydentu i problemu. Dla spójności zaprezentujmy jednak poniżej krótkie definicje tych pojęć, które stosujemy w Atlassian:

ITIL (Information Technology Infrastructure Library) jest zbiorem najlepszych praktyk ITSM (można je traktować jako porady strategiczne).

ITSM (zarządzanie usługami informatycznymi) jest powszechnie stosowanym podejściem do tworzenia i obsługi usług IT oraz zarządzania nimi. Podstawową koncepcją ITSM jest przekonanie, że technologia informatyczna powinna być dostarczana jako usługa. Jedną z kluczowych praktyk w ramach ITSM jest zarządzanie incydentami.

Incydentami są dowolnego rodzaju nieplanowane zdarzenia, które zakłócają dostarczanie usługi lub obniżają jej jakość (bądź stwarzają takie zagrożenie). Awaria aplikacji biznesowej jest incydentem. Spowolnienie działania serwera internetowego również może być incydentem, nawet jeśli nie dojdzie do jego całkowitego wyłączenia. Serwer pracuje powoli, a zatem wpływa niekorzystnie na produktywność. Co gorsza, stwarza większe ryzyko całkowitej awarii.

Problem to nieznana jeszcze główna przyczyna co najmniej jednego incydentu. W przypadku opisanego powyżej incydentu związanego z powolnym działaniem sieci i awarią aplikacji biznesowej problemem będącym źródłem obydwu zdarzeń może być źle skonfigurowany router.

Znaczenie zarządzania incydentami jako praktyki ITSM

Po co właściwie jest potrzebne zarządzanie incydentami? Dlaczego w ogóle stanowi ono część uniwersum ITSM?

Odpowiedzią są skutki. Badania wskazują, że w przypadku poważnych incydentów każda godzina niedostępności systemu kosztuje firmy średnio od 100 000 USD do 300 000 USD.

Właściwie zdefiniowany proces zarządzania incydentami może pomóc w znacznym stopniu obniżyć te koszty. Korzyści z właściwie zdefiniowanego procesu to między innymi:

  • szybsze rozwiązywanie incydentów;
  • mniejsze koszty lub straty przychodów dla organizacji;
  • lepsza komunikacja wewnętrzna i zewnętrzna w trakcie incydentów;
  • ciągłe uczenie się i doskonalenie.

Przepływ pracy – Zarządzanie incydentami

Wykorzystam ramy postępowania ITIL, aby zaprezentować ogólne omówienie właściwej obsługi zgłoszeń, jednak większość innych popularnych ram postępowania posługuje się mniej więcej zbliżonymi koncepcjami funkcjonującymi pod nieco innymi nazwami.

Kluczem do zarządzania incydentami jest opracowanie i przestrzeganie właściwego procesu.

Wiem, nawet to może wydawać się trudne. Dobra wiadomość jest taka, że możesz uczyć się na bazie doświadczeń tysięcy innych zespołów świadczących usługi IT.

Jednym z kluczowych błędów popełnianych przez intensywnie działające, rozrastające się organizacje IT jest próba odkrywania koła na nowo i tworzenia procesów od zera (bez sięgania do najlepszych praktyk) lub opracowywanie własnego narzędzia do obsługi zgłoszeń.

Identyfikacja i rejestracja incydentu

Incydent może dotrzeć do Ciebie z każdej strony. Może zadzwonić pracownik ze zgłoszeniem lub incydent może dosłownie spaść na Ciebie z sufitu, jeśli przeciek z dachu napotka na swojej drodze umieszczony w pechowym miejscu koncentrator sieciowy. (Nie, żebyśmy rzucali przykładami z własnego doświadczenia... *chrząknięcie*).

Jednak niezależnie od źródła, dwa pierwsze etapy są proste: ktoś dostrzega incydent, a następnie ktoś go rejestruje.

Jeśli dociera do Ciebie incydent zarejestrowany wcześniej a pośrednictwem działu obsługi, pierwsze dwa etapy masz już za sobą. Jeśli otrzymujesz telefon, e-mail, SMS lub gołębia pocztowego z powiadomieniem o incydencie, zadaniem działu obsługi jest odpowiednie zarejestrowanie incydentu w dziale obsługi.

Te rejestry incydentów (tj. zgłoszenia) zawierają zazwyczaj następujące informacje:

  • imię i nazwisko osoby zgłaszającej incydent;
  • data i godzina zgłoszenia incydentu;
  • opis incydentu (co nie działa lub działa niepoprawnie);
  • unikatowy numer identyfikacyjny przypisany do incydentu na potrzeby śledzenia.

Kategoryzacja incydentu

Te dwa kolejne etapy — kategoryzacja i określenie priorytetu — są zarówno krytyczne, jak i często pomijane. Są one również tym, co wyróżnia bardziej „zdroworozsądkowe” centra obsługi, z którymi miałem okazję współpracować, od… no cóż, mniej zdroworozsądkowych.

Najpierw do każdego incydentu musisz przypisać logiczną, intuicyjną kategorię (a w razie potrzeby także podkategorię). Jeśli tego nie zrobisz, pozbawisz się możliwości późniejszej analizy danych i wyszukiwania trendów oraz wzorców, co stanowi krytyczny element skutecznego procesu zarządzania problemami i zapobiegania incydentom w przyszłości.

Więc po prostu o tym nie zapominaj. I nie wybieraj dla centrum obsługi IT rozwiązania, które nie pozwala na łatwe dostosowywanie kategorii incydentów.

Określenie priorytetu incydentu

Następnie każdemu incydentowi należy przypisać priorytet.

Aby nadać incydentowi priorytet, zacznij od oceny jego wpływu na działalność. Weź pod uwagę, na ilu ludzi będzie miał on wpływ, oraz przeanalizuj potencjalne skutki finansowe i związane z bezpieczeństwem i zapewnianiem zgodności z przepisami. Pomoże to określić, jak wiele problemów powoduje dany incydent i jak pilnie firma musi go rozwiązać.

W tym przypadku najlepszą praktyką jest zdefiniowanie poziomów istotności i priorytetów zanim dojdzie do incydentu, aby ułatwić osobom zarządzającym incydentami szybkie ustalenie priorytetu.

W razie wątpliwości dotyczących poziomu priorytetu postaw na wyższy priorytet. Lepiej przesadzić z ostrożnością niż pozwolić, aby jakiś poważny incydent został przeoczony.

Po określeniu priorytetów zajmij się wszystkimi otwartymi incydentami w kolejności ich priorytetów. Większość organizacji zawiera w umowach o świadczenie usług konkretne dane dotyczące poszczególnych poziomów priorytetów, aby klienci wiedzieli, jak szybko mogą spodziewać się reakcji i rozwiązania. Zdecydowanie polecam tę praktykę.

Reagowanie

Reagowanie na incydenty jest pojęciem dosyć szerokim, dlatego podzielmy je na etapy, które prawdopodobnie trzeba będzie zrealizować po zidentyfikowaniu incydentu i przypisaniu mu kategorii oraz priorytetu.

Początkowa diagnoza
Pomyśl o tym jako o klasyfikacji stanu nowych pacjentów wykonywanej w szpitalu. Pracownik centrum obsługi formułuje szybką hipotezę na temat tego, co może być nie tak, aby podjąć decyzję o samodzielnym rozwiązaniu problemu lub wdrożeniu stosownych procedur i zorganizowaniu właściwych zasobów do jego rozwiązania.

Bazy wiedzy i instrukcje diagnostyczne także są przydatnymi narzędziami na tym etapie.

Jeśli agent centrum obsługi pierwszego poziomu może rozwiązać incydent na podstawie wstępnej diagnozy oraz dostępnych informacji i narzędzi, incydent zostaje rozwiązany. W innym przypadku konieczna jest eskalacja.

Eskalacja incydentu
Eskalacja brzmi jak przekleństwo, ale nim nie jest.

Zespół pierwszej linii wsparcia powinien być w stanie rozwiązać wiele spośród często występujących incydentów bez ich eskalowania. Jednak w przypadku incydentów, których nie może rozwiązać, celem jest raczej zebranie i zarejestrowanie właściwych informacji, które ułatwią (bardziej technicznym) pracownikom wsparcia drugiego i trzeciego poziomu szybkie rozpoczęcie pracy w celu sprawnego rozwiązania incydentu.

Badanie i diagnoza
W ITIL ten etap został opisany jako zupełnie niezależny krok. W rzeczywistości jednak jest on elementem cyklu życia incydentu.

Pracownik pierwszej linii wsparcia już rozpoczyna jego badanie w stopniu koniecznym do zebrania informacji. Taka osoba może nawet pomyślnie zdiagnozować, a nawet rozwiązać incydent bez dalszej eskalacji.

W takim przypadku pomija się bezpośrednio kilka kolejnych etapów, takich jak rozwiązywanie i przywracanie oraz zamknięcie incydentu.

W innym przypadku badanie oraz diagnoza są elementem każdego etapu procesu w miarę eskalacji incydentu do wsparcia 2 lub 3 poziomu bądź wprowadzania zasobów zewnętrznych lub innych członków działu w celu uzyskania konsultacji i pomocy przy rozwiązaniu.

Rozwiązywanie i przywracanie
W końcu — a najlepiej w czasie przewidzianym w umowach o gwarantowanym poziomie świadczenia usług (SLA) — uzyskujesz diagnozę i podejmujesz działania konieczne do rozwiązania incydentu. Przywracanie odnosi się po prostu do czasu, jaki może zająć pełne przywrócenie normalnego działania, ponieważ niektóre korekty (np. poprawki błędów) mogą wymagać przetestowania i wdrożenia już po ustaleniu właściwego rozwiązania.

Zamknięcie incydentu
Incydent jest następnie przekazywany z powrotem do centrum obsługi (jeśli doszło do jego eskalacji) w celu zamknięcia. Aby zachować jakość i płynność procesów, incydenty mogą zamykać wyłącznie pracownicy centrum obsługi, a właściciel incydentu powinien skonsultować się z osobą zgłaszającą, w celu potwierdzenia, że jest ona zadowolona z rozwiązania, a sam incydent faktycznie można zamknąć.

Wniosek: nie pomijaj żadnych etapów

Proces może wydawać się niepotrzebnie sformalizowany, zwłaszcza jeśli masz jedynie kilku analityków centrum obsługi. Jednak niezależnie od struktury zespołu, cykl życia incydentu jest nadal taki sam.

Załóżmy, że masz tylko jednego analityka centrum obsługi, więc nie ma trzeciego poziomu wsparcia. Jednak incydenty, które wykraczają poza wiedzę Twojego analityka centrum obsługi, muszą gdzieś trafić, na przykład do głównego inżyniera, konsultanta zewnętrznego, a nawet do Ciebie, prawda?

Voila! W rzeczywistości masz więc wsparcie drugiego lub trzeciego poziomu — po prostu tym wsparciem jesteś Ty lub Twój inżynier.

Co chcę przez to powiedzieć? Choć wytyczne ITIL mogą się wydawać czystą semantyką, nie daj się zwieść. Poszukaj łatwych sposobów dostosowania Twojej hierarchii organizacyjnej i przepływów pracy procesów do prostego modelu zarządzania usługami IT, takiego jak nakreślony przeze mnie powyżej.

W ten sposób zapewnisz znacznie lepszą obsługę klienta i znacznie większe korzyści dla firmy. (A dodatkowo przestaniesz ciągle biegać po rozżarzonych węglach — taki bonus!).

Na koniec kilka kwestii, o których warto pamiętać:

  • Rejestruj każdy incydent. Nadaj mu unikatowy numer. I zapisz ważne szczegóły na jego temat (takie jak data, godzina i opis) w centralnym systemie pomocy technicznej.
  • Jeśli musisz powiadamiać o incydentach dużą grupę odbiorców wewnętrznych lub zewnętrznych, rozważ utworzenie strony stanu do informowania o incydentach.
  • Przypisz każdemu incydentowi kategorię (a w razie potrzeby także podkategorię).
  • Nadaj każdemu incydentowi priorytet, a do każdego poziomu priorytetu przypisz umowę SLA.
  • Opracuj przejrzyste definicje ról pełnionych przez osoby reagujące na incydenty, takie jak zarządzający incydentami, menedżer ds. poważnych incydentów czy lider ds. komunikacji.
  • W miarę możliwości zapewnij zespołowi pierwszej linii wsparcia dostęp do bazy wiedzy zawierającej artykuły i skrypty diagnostyki incydentów, aby ułatwić im szybkie rozwiązywanie incydentów.
  • Upewnij się, że centrum obsługi przez cały czas kontroluje przebieg incydentu, jego przekierowania oraz status.
  • Nie ograniczaj się do rejestrowania danych incydentu. Analizuj je! Szukaj trendów, wzorców i potencjalnych problemów leżących u ich podstaw, aby ograniczać liczbę incydentów i zmniejszyć ryzyko ich wystąpienia.
Autor

Nick Wright
Menedżer ds. eksploatacji usług w Atlassian

Mój zespół i ja zapewniamy jak najlepsze działanie aplikacji i infrastruktury chmurowej Atlassian. Chętnie opowiem, jak to robimy przy jednoczesnym szybkim skalowaniu. Jestem z Nowej Zelandii, ale pomimo silnego akcentu potrafię się porozumieć. W wolnym czasie jeżdżę na rowerze, gram w gry albo spędzam czas z żoną i uroczą córeczką.