Close

Droga do lepszego zarządzania incydentami zaczyna się tutaj

Zasady eskalacji sprzyjające skutecznemu zarządzaniu incydentami

Gdy dochodzi do incydentu, w najlepszym wypadku technik lub serwisant witryn pełniący dyżur domowy jest w stanie rozwiązać incydent szybko i samodzielnie.

Naturalnie w rzeczywistości nie zawsze jest to możliwe. Czasami rozwiązanie wymaga zaangażowania większego zespołu, specjalistycznej wiedzy czy bardziej zaawansowanych umiejętności. Dlatego każda organizacja zatrudniająca więcej niż dwóch specjalistów ds. technicznych potrzebuje planu oraz zasad eskalacji incydentów.

Na czym polega eskalacja incydentu?

Z eskalacją incydentu mamy do czynienia, gdy pracownik nie jest w stanie samodzielnie rozwiązać incydentu i musi przekazać zadanie innemu pracownikowi, który ma większe doświadczenie lub większą wiedzę.

Czym są zasady eskalacji?

Zasady eskalacji określają sposób, w jaki takie przekazanie zadań odbywa się w Twojej organizacji. Wskazują one, kogo należy powiadomić, gdy napłynie alert o incydencie, do kogo powinien być eskalowany incydent, jeśli pierwsza osoba reagująca jest niedostępna, a kto powinien go przejąć, jeśli taka osoba nie jest w stanie samodzielnie rozwiązać problemu. Określają również sposób przekazywania zadań (przez dział obsługi, bezpośrednio między technikami, przez narzędzie do zarządzania incydentami).

Na pierwszy rzut oka te pytania wydają się proste, jednak im większa organizacja, tym bardziej złożony staje się ekosystem technologiczny, a w konsekwencji więcej kwestii wymaga uszczegółowienia. Na przykład przy wskazywaniu osoby, która powinna być powiadamiana w razie napłynięcia alertu o incydencie, odpowiedź może się różnić nie tylko w zależności od tego, kto pełni dyżur domowy lub jest dostępny, ale także od poziomów ważności, czasu trwania incydentu itp.

W niektórych firmach niezależnie od poziomu ważności incydentu powiadamiana może być najpierw jedna osoba pełniąca dyżur domowy. Z kolei w innych firmach dobrym rozwiązaniem może być powiadamianie młodszego programisty o incydentach o poziomie ważności 3, natomiast o incydentach o poziomie ważności 1 — powiadamianie bardziej doświadczonej osoby lub zespołu specjalistów.

Podobnie w niektórych firmach zadanie eskalowania incydentu w razie potrzeby może spoczywać na pierwszej osobie reagującej. W innych z kolei eskalacja do starszego programisty lub zespołu specjalistów może być wyzwalana automatycznie po upływie określonego czasu trwania incydentu lub rozszerzeniu zakresu jego skutków na większą liczbę systemów bądź użytkowników.

Zasady eskalacji powinny regulować nie tylko sposób eskalacji incydentów oraz obsadę personalną poszczególnych poziomów, ale także kwestię ewentualnych różnic występujących w zależności od rodzaju incydentu, poziomu jego ważności, czasu trwania oraz zakresu.

Procesy eskalacji incydentów

W firmach przestrzegających najlepszych praktyk ITSM dział obsługi stanowi zazwyczaj ośrodek eskalacji incydentów. Jeśli pierwsza osoba reagująca nie jest w stanie rozwiązać incydentu, zwraca go do działu obsługi, gdzie zgłoszenie jest eskalowane do odpowiedniej kolejnej linii obrony. Za pomocą Jira Service Management osoby reagujące mogą eskalować incydenty w ramach zgłoszenia incydentu. Osoby reagujące mają dostęp do przepływów pracy, co usprawnia proces rozwiązywania incydentów, i mogą wdrażać automatyzacje lub dostosowywać działania w zależności od potrzeb. Wyznaczenie poziomu ważności pozwala skierować osoby reagujące do właściwego przepływ pracy.

Inne firmy, takie jak Google, wyznaczają serwisanta witryn odpowiedzialnego za incydenty i właśnie ta osoba zajmuje się wszelkimi niezbędnymi eskalacjami (a także zamraża nowe wydania w przypadku gdy incydent przybliża zespół do przekroczenia dopuszczalnych progów przestoju zdefiniowanych w umowach SLA/SLO).

W jeszcze innych firmach pierwszą osobą reagującą może być programista lub menedżer ds. incydentów bądź może funkcjonować wiele punktów kontaktu (zwłaszcza, gdy napływa alert o incydencie o wysokim poziomie ważności), a eskalacja odbywa się bezpośrednio między tymi zespołami zgodnie ze wstępnie zdefiniowanymi procesami.

Bez względu na to, czy proces obejmuje dział obsługi, wsparcie serwisanta witryn czy automatyczne operacje wykonywane w systemach śledzenia incydentów, zasady eskalacji zazwyczaj przewidują jedną z trzech ścieżek.

Eskalacja hierarchiczna

O eskalacji hierarchicznej mówimy, gdy incydent przekazywany jest zespołowi lub osobie, w zależności od poziomu doświadczenia lub stażu takiej osoby w organizacji.

Przykładowo pierwszą osobą reagującą pełniącą dyżur domowy może być młodszy programista, który jest nowy w zespole. Jeśli nie jest on w stanie rozwiązać problemu, przekazuje go starszemu programiście stojącemu wyżej w hierarchii organizacji. Jeśli osoba ta także nie jest w stanie rozwiązać problemu, ponownie przekazuje go do jeszcze bardziej doświadczonego programisty i tak dalej, aż do rozwiązania problemu.

Eskalacja funkcjonalna

Z eskalacją funkcjonalną mamy do czynienia, gdy incydent przekazuje się zespołowi lub osobie posiadającym najlepsze kompetencje do jego rozwiązania, biorąc pod uwagę posiadane umiejętności czy znajomość systemów, a nie starszeństwo.

Przykładowo pierwszą osobą reagującą pełniącą dyżur domowy może być młodszy programista z zespołu, który zajmuje się back endem produktu X. Jeśli osoba ta uzna, że problem leży w integracji z produktem Y, może eskalować incydent do innego młodszego programisty w zespole produktu Y.

Eskalacja automatyczna

Jeśli zespoły korzystają z takiej platformy, jak Opsgenie, można również skonfigurować reguły, zgodnie z którymi system będzie automatycznie eskalował incydent, jeśli podstawowa osoba pełniąca dyżur domowy nie potwierdzi lub nie zamknie alertu.

Niektóre zespoły mogą preferować jedną metodę eskalacji od innej, jednak metody te nie wykluczają się wzajemnie i wiele zespołów korzysta z kombinacji eskalacji hierarchicznej, funkcjonalnej i automatycznej.

Macierz eskalacji

Macierz eskalacji to dokument lub system, który określa, kiedy powinna nastąpić eskalacja i kto powinien zajmować się incydentami na poszczególnych poziomach eskalacji.

Termin ten stosowany jest w wielu branżach. Zespoły ds. zasobów ludzkich wykorzystują macierz eskalacji do obsługi wewnętrznych zgłoszeń. Centra obsługi telefonicznej stosują macierz eskalacji w odniesieniu do zgłoszeń serwisowych klientów. Z kolei zespoły IT i DevOps mogą stosować co najmniej jedną taką macierz do określania sposobów eskalacji incydentów i sytuacji, w których taka eskalacja jest konieczna.

Poziom szczegółowości macierzy różni się znacznie w zależności od firmy. Niektóre organizacje stawiają na prostą tabelę hierarchiczną, zgodnie z którą w razie potrzeby każdy programista eskaluje incydent do osoby o wyższych kompetencjach. W innych organizacjach mogą funkcjonować macierze właściwe dla konkretnych sytuacji, które informują programistów, z jakimi zespołami powinni kontaktować się w przypadku różnych rodzajów incydentów i różnych poziomów ich ważności. Jak w przypadku większości zagadnień z dziedziny zarządzania incydentami, tutaj również nie ma jednego uniwersalnego sposobu na opracowanie macierzy dla swojej organizacji.

Dobre praktyki przy opracowywaniu zasad eskalacji

Traktuj zasady eskalacji jak wytyczne, a nie sztywny zestaw reguł

Twoje zespoły, podobnie jak sama technologia, nie są statyczne. Google sugeruje, że jeśli serwisant witryn uważa, że dany przypadek wymaga odmiennej strategii eskalacji, należy dać mu swobodę podjęcia takiej decyzji według własnego osądu. Nie chodzi przecież o opracowanie sztywnych reguł, tylko o stworzenie wytycznych, które będą się sprawdzać w większości sytuacji.

Regularnie weryfikuj harmonogram dyżurów domowych

Czy w harmonogramie są jakieś luki? Czy dyżury domowe są obsadzone właściwymi osobami? Czy na drugim i trzecim poziomie dyżurów domowych masz odpowiednie osoby? Harmonogramy dyżurów domowych powinny współgrać z zasadami eskalacji, aby umożliwić szybsze zarządzanie incydentami.

Ustaw inteligentne progi dla eskalacji

Nie każdy incydent jest równie ważny, co oznacza, że nie do każdego incydentu można i należy stosować te same zasady eskalacji.

Być może drobne incydenty mogą zaczekać z powiadomieniem technika pełniącego dyżur domowy do godzin jego pracy. Z kolei w przypadku poważnych incydentów prawdopodobnie konieczne będzie zaangażowanie tego technika bez względu na porę dnia. W przypadku wielu incydentów technik będzie musiał ustalić, czy powinien zająć się w pierwszej kolejności i/lub czy powinien od razu eskalować jeden incydent do drugiego technika.

Trzeba zachować równowagę między zapewnieniem maksymalnej dostępności systemów, wypełnieniem zobowiązań wynikających z umów SLA i realizacją celów SLO a ryzykiem wypalenia, przepracowania i zmęczenia alertami techników czy też pozbawienia ich snu.

Opracuj przejrzyste procesy eskalacji

Czy programista dokonujący eskalacji powinien skontaktować się z odpowiednim zespołem lub odpowiednią osobą osobiście czy za pośrednictwem działu pomocy? Czy programista powinien użyć konkretnego systemu? Jak śledzić eskalację? Jakie obowiązki musi wykonać pierwsza osoba reagująca, aby się upewnić, że incydent został odebrany przez kolejną osobę?

Odpowiedzi na te pytania należy wyraźnie wskazać w zasadach i przekazać wszystkim programistom pełniącym dyżury domowe, aby eskalacje przebiegały sprawnie, a incydenty były rozwiązywane szybciej.

Dowiedz się, jak Jira Service Management może poprawić praktykę zarządzania incydentami, oferując oparte na współpracy rozwiązanie do eskalacji incydentów, które przyspiesza rozwiązywanie problemów.

Następny
narzędzia