Czym jest zarządzanie incydentami?

Rodzaje procesów zarządzania incydentami

Różne rodzaje firm skłaniają się ku różnym typom procesów zarządzania incydentami. Nie ma jednego procesu, który sprawdziłby się idealnie we wszystkich firmach, dlatego prawdopodobnie w różnych firmach będziesz spotykać się z odmiennymi podejściami.

Wiele zespołów wykorzystuje bardziej tradycyjne procesy zarządzania incydentami w stylu IT, takie jak te, które opisano w certyfikacjach ITIL. Inne zespoły skłaniają się raczej do procedur zarządzania incydentami stosowanych przez serwisantów witryn internetowych lub zespoły DevOps.

Proces zarządzania incydentami IT

Proces zarządzania incydentami pomaga zespołom IT w analizowaniu, rejestrowaniu i rozwiązywaniu zakłóceń lub przerw w dostawie usług. Przewidziany w ITIL przepływ pracy związany z zarządzaniem incydentami ma na celu ograniczenie przestojów i zminimalizowanie wpływu incydentów na produktywność pracowników. Korzystając z szablonów do zarządzania incydentami, można opracować powtarzalny przepływ pracy związany z zarządzaniem incydentami, który pozwoli zespołowi rejestrować, diagnozować i rozwiązywać incydenty, a jednocześnie prowadzić rejestr własnych działań.

Podejście ITIL stosowane jest głównie przez zespoły IT odpowiedzialne za świadczenie usług wewnątrzfirmowych. Zazwyczaj zespoły czerpią z zasad ITIL — które uwzględniają niemal każdy rodzaj incydentu, problemu i procesu, z jakim mogą mieć do czynienia zespoły IT — to, co jest im potrzebne, pozostawiając resztę. Podejście ITIL sprawdza się doskonale, gdy zespoły muszą skoncentrować się na kultywowaniu kultury aktywnego rozwiązywania problemów. Zalecane procesy ułatwiają zespołom spójne monitorowanie incydentów oraz działań, poprawiają jakość raportowania i analizy, a w konsekwencji pozwalają uzyskać lepiej działającą usługę i dają zespołowi możliwość skutecznej pracy.

Kroki w procesie zarządzania incydentami IT

Identyfikacja i rejestracja incydentu

Informacja o incydencie może pochodzić z różnych źródeł: od pracownika, klienta, dostawcy, z systemów monitorujących. Jednak niezależnie od źródła, dwa pierwsze etapy są proste: ktoś dostrzega incydent, a następnie ktoś go rejestruje. 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

Do każdego incydentu przypisz logiczną, intuicyjną kategorię (a w razie potrzeby także podkategorię). Pomoże to przeanalizować dane pod kątem trendów oraz wzorców, co stanowi krytyczny element skutecznego procesu zarządzania problemami i zapobiegania incydentom w przyszłości.

Ustawianie priorytetów

W przypadku każdego incydentu należy określić priorytet. Zacznij od oceny jego wpływu na działalność, ustalenia liczby osób, które odczują skutki incydentu, ustalenia właściwych umów SLA, a także potencjalnych skutków incydentu dla finansów, bezpieczeństwa oraz zgodności z przepisami. Aby ustalić względny priorytet incydentu, porównaj go ze wszystkimi innymi otwartymi incydentami.

Odpowiedz

• Wstępna diagnoza: Najlepiej, jeśli zespół wsparcia w pierwszej linii może obsłużyć incydenty na wszystkich etapach — od zdiagnozowania po zamknięcie. Jeśli jednak jest to niemożliwe, kolejnym krokiem będzie zarejestrowanie wszystkich istotnych informacji i eskalowanie incydentu do zespołu kolejnego poziomu.
• Eskalacja: Kolejny zespół przejmuje zarejestrowane dane i przeprowadza dalszą diagnostykę, a jeśli ten kolejny zespół nie jest w stanie zdiagnozować incydentu, jest on eskalowany do zespołu kolejnego poziomu.
• Komunikacja: zespół regularnie przekazuje aktualne informacje wewnętrznym i zewnętrznym interesariuszom, których dotyczy incydent.
• Badanie i diagnostyka: trwa do czasu rozpoznania charakteru incydentu. Czasami zespoły angażują zasoby z zewnątrz lub członków innych działów w celu konsultacji i uzyskania pomocy przy rozwiązaniu.
• Rozwiązanie i przywrócenie: na tym etapie zespół opracowuje diagnozę i podejmuje działania konieczne do rozwiązania incydentu. Przywracanie odnosi się po prostu do czasu, jaki może zająć pełne przywrócenie sprawności, ponieważ niektóre poprawki (np. poprawki błędów) mogą wymagać przetestowania i wdrożenia już po ustaleniu właściwego rozwiązania.
• Zamknięcie: jeśli doszło do eskalacji incydentu, ostatecznie jest on przekazywany do działu obsługi celem 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ąć.

Incydenty, problemy i zmiany: czym się różnią?

Można wskazać wiele różnych rodzajów zgłoszeń, z jakimi zazwyczaj spotykają się zespoły IT. Poniżej sklasyfikowaliśmy te zgłoszenia, aby zastosować do nich odpowiednie techniki zarządzania.

• Wniosek o usługę — formalny wniosek o udostępnienie czegoś, na przykład nowego laptopa, składany przez klienta.
• Incydent — nieplanowana przerwa w świadczeniu usługi IT lub obniżenie jakości usługi, na przykład niedziałająca witryna internetowa.
• Problem — problem oznaczał główną przyczynę leżącą u podstaw incydentu, na przykład nieprawidłową konfigurację serwera. Problemy chcesz na bieżąco monitorować, aby nie przerodziły się w rozległe incydenty.
• Zmiana — podejmowane działanie, które może mieć charakter standardowy, normalny lub awaryjny. Zmiana standardowa ma ustanowioną procedurą. Zmiana normalna często jest poważniejsza i wymaga procesu zatwierdzenia. Zmiana awaryjna jest wprowadzana doraźnie, a w idealnej sytuacji przed udostępnieniem zostaje przetestowana.

Proces zarządzania incydentami DevOps i SRE

W zarządzaniu incydentami według podejścia DevOps lub SRE zespół, który tworzy usługę jednocześnie dba o jej poprawne działanie, a w razie usterki odpowiada za jej naprawę. Wraz z rozwojem dostępnych przez cały czas usług chmurowych, aplikacji sieciowych z dostępem globalnym, mikrousług i oprogramowania udostępnianego jako usługa podejście to zyskało na popularności.

Coraz częściej oprogramowanie, z którego korzystasz na co dzień i w pracy nie jest hostowane na serwerze w Twojej lokalizacji geograficznej. Najprawdopodobniej jest to aplikacja udostępniana za pośrednictwem przeglądarki wdrożona w centrum danych i dostępna dla milionów użytkowników na całym świecie. Dla zespołów odpowiedzialnych za obsługę tych usług zwinność i prędkość mają niebagatelne znaczenie. Każda przerwa w dostarczaniu usługi może potencjalnie dotknąć tysięcy organizacji, a nie tylko jednej.

Zaletą podejścia opartego na zasadzie „odpowiadasz za to, co tworzysz” jest zapewnienie zespołom Agile tak potrzebnej im elastyczności, jednak może ono również wprowadzać wątpliwości w zakresie przydziału obowiązków i terminów realizacji zadań. Zespoły DevOps mogą działać wygodnie i skutecznie, z wykorzystaniem mniej ustrukturyzowanych procesów tworzenia oprogramowania. Jednak najlepszym rozwiązaniem jest wdrożenie podstawowego zestawu procesów zarządzania incydentami, aby w gorączce towarzyszącej wystąpieniu incydentu nie było wątpliwości co do sposobu reagowania, a zespół miał możliwość monitorowania zgłoszeń i raportowania sposobów ich rozwiązywania.

Trzy przekonania zespołów DevOps zarządzających incydentami

• Dyżury domowe należy pełnić na zmianę: zamiast wyznaczania konkretnych członków zespołu, którzy będą specjalizowali się w dyżurach domowych, członkowie zespołów DevOps zazwyczaj na zmianę biorą na siebie ryzyko nocnej pobudki związanej z koniecznością zareagowania na incydent.
• Inżynier, który opracował usługę, najlepiej potrafi ją naprawić: to centralna koncepcja, na której opiera się zasada „odpowiadasz za to, co tworzysz”, zakładająca, że osoby najlepiej zaznajomione z usługą (jej twórcy) dysponują najlepszym zapleczem do usuwania związanych z nią awarii.
• Usługi należy tworzyć szybko, zachowując przy tym odpowiedzialność: gdy inżynierowie wiedzą, że wraz z innymi członkami swoich zespołów będą uczestniczyć w usuwaniu awarii, dokładają wszelkich starań, aby wdrażać wysokiej jakości kod.

Takie podejście pozwala skrócić czasy reakcji i przyspieszyć przekazywanie informacji zwrotnych do zespołów, które muszą wiedzieć, jak opracować niezawodną usługę.

W podręczniku Atlassian dotyczącym incydentów nakreśliliśmy podejście do zarządzania incydentami bardzo przyjazne dla zespołów DevOps.

Narzędzia do zarządzania incydentami

Do zarządzania incydentami nie wystarczy po prostu narzędzie, konieczna jest odpowiednia mieszanka narzędzi, praktyk oraz ludzi. Poniżej przedstawiamy kilka najczęściej stosowanych kategorii narzędzi pozwalających skutecznie zarządzać incydentami:

• Monitorowanie incydentów: każdy incydent powinien być monitorowany i udokumentowany, aby można było rozpoznawać trendy i dokonywać porównań w czasie.
• Pokój na czacie: kanał służący do komunikacji tekstowej w czasie rzeczywistym jest niezbędny do diagnozowania i usuwania incydentów w ramach pracy zespołowej. Stanowi on bogaty zbiór danych do późniejszej analizy reakcji.
• Wideoczat: wideoczat stanowi uzupełnienie czatu tekstowego w przypadku wielu incydentów, ułatwiając zespołowi omówienie wniosków i odpowiednie nakreślenie strategii.
• System powiadamiania: narzędzie, np. OpsGenie, zintegrowane z systemem monitorowania i służące do zarządzania rotacjami dyżurów domowych i eskalacjami.
• Narzędzie do tworzenia dokumentacji: za pomocą narzędzia takiego jak Confluence można rejestrować dokumenty dotyczące stanów incydentów oraz przeprowadzać analizy post-mortem.
• Strona z informacjami o statusie: do informowania interesariuszy w przedsiębiorstwie oraz klientów o statusie incydentu, aby wszyscy byli na bieżąco.