Czym jest zarządzanie incydentami?

Zarządzanie incydentami jest procesem stosowanym przez zespoły programistyczne i operacyjne IT w celu reagowania na nieplanowane zdarzenie lub przerwę w świadczeniu usługi i przywracanie jej do stanu funkcjonalnego.

Zgodnie z definicją przyjętą w Atlassian incydent to zdarzenie powodujące zakłócenie działania lub obniżenie jakości usługi wymagające natychmiastowej reakcji. Zespoły stosujące praktyki ITIL lub ITSM mogą do opisu tej sytuacji używać pojęcia „poważny incydent”.

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

Zarządzanie incydentami jest jednym z najważniejszych procesów, które organizacja musi prawidłowo realizować. Przerwy w świadczeniu usług mogą być kosztowne dla firmy, dlatego zespoły potrzebują skutecznego sposobu szybkiego reagowania na te problemy i ich eliminowania. Zespoły wymagają niezawodnej metody ustalania priorytetów incydentów, szybszego uzyskiwania rozwiązania i zapewniania użytkownikom lepszej obsługi.

Stając w obliczu incydentu, zespoły potrzebują planu, który pomoże im:

• skutecznie reagować, aby szybko przywrócić normalne funkcjonowanie;
• przekazywać czytelne informacje klientom, interesariuszom, właścicielom usług oraz innym osobom w organizacji;
• skutecznie współpracować w zespole, aby szybciej rozwiązywać problem i eliminować bariery, które utrudniają odnalezienie właściwego rozwiązania;
• nieustannie doskonalić się, wyciągając wnioski z zaistniałych przerw w świadczeniu usług oraz wykorzystując je do ulepszania usług i dopracowywania procesów na przyszłość.

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, więc prawdopodobnie w różnych firmach spotykasz 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ę ku procesowi zarządzania incydentami bardziej zbliżonemu do praktyk inżynierii niezawodności lokalizacji (SRE) lub DevOps.

Proces zarządzania incydentami pomaga zespołom IT w badaniu, rejestrowaniu i rozwiązywaniu problemów związanych z zakłóceniami lub przerwami w świadczeniu usług. Przepływ pracy ITIL 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 zarządzania incydentami, który pozwoli zespołowi rejestrować, diagnozować i rozwiązywać incydenty, a jednocześnie prowadzić rejestr własnych działań.

Ramy ITIL są stosowane 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 którym 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ń, co poprawia jakość raportowania i analizy oraz może prowadzić do lepszej jakości usług i skuteczniejszego funkcjonowania zespołu.

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, pierwsze dwa kroki są proste: ktoś identyfikuje incydent, a następnie ktoś go rejestruje. Te dzienniki 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.

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

W przypadku każdego incydentu należy określić priorytet. Zacznij od oceny jego wpływu na działalność, określenia liczby osób, które odczują skutki incydentu, ustalenia właściwych umów SLA, a także potencjalnych konsekwencji dla finansów, bezpieczeństwa oraz zgodności z przepisami. Porównaj ten incydent z wszystkimi innymi otwartymi incydentami, aby określić jego względny priorytet. Najlepszą praktyką jest zdefiniowanie poziomów istotności i priorytetów przed wystąpieniem incydentu, aby ułatwić osobom zarządzającym incydentami szybkie ustalenie priorytetu. 

• Wstępna diagnoza: Najlepiej, jeśli zespół pierwszej linii wsparcia może obsłużyć incydent od momentu zdiagnozowania do zamknięcia. Jeśli jednak jest to niemożliwe, kolejnym krokiem będzie zarejestrowanie wszystkich istotnych informacji i eskalowanie incydentu do zespołu wyższego szczebla.
• Eskalacja: następny zespół przejmuje zarejestrowane dane i przeprowadza dalszą diagnostykę, a jeśli nie może on zdiagnozować incydentu, jest on eskalowany do kolejnego zespołu.
• Komunikacja: zespół regularnie udostępnia 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ązywaniu.
• Rozwiązanie i przywrócenie: Na tym etapie zespół ustala diagnozę i podejmuje działania konieczne do rozwiązania incydentu. Przywrócenie oznacza po prostu czas, jaki może zająć pełne przywrócenie normalnego działania, ponieważ niektóre wprowadzane korekty (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 centrum 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ąć.

W zarządzaniu incydentami według podejścia DevOps lub SRE zespół, który opracowuje usługę jednocześnie dba o jej poprawne działanie, a w razie usterki odpowiada za jej naprawę. Wraz z rozwojem zawsze dostępnych usług w chmurze, globalnie dostępnych aplikacji internetowych, mikrousług i oprogramowania jako usługi to podejście zyskało na popularności.

Coraz częściej oprogramowanie, z którego korzystasz w celach zawodowych i prywatnych, nie jest hostowane na serwerze znajdującym się w Twojej lokalizacji geograficznej. Prawdopodobnie jest to aplikacja dostępna przez Internet, wdrożona w centrum danych dla tysięcy lub milionów użytkowników na całym świecie. Dla zespołów odpowiedzialnych za obsługę tych usług najważniejsza jest elastyczność i szybkość działania. Każda przerwa w świadczeniu usług może mieć wpływ na tysiące organizacji, a nie tylko na jedną.

Zaletą podejścia opartego na zasadzie „odpowiadasz za to, co tworzysz” jest zapewnienie zespołom Agile tak potrzebnej elastyczności. Jednak może ono również wprowadzać niejasność co do podziału obowiązków i terminów realizacji zadań. Zespoły DevOps mogą czuć się bardziej komfortowo — i odnosić sukcesy — przy mniej ustrukturyzowanych procesach programistycznych. 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 oraz aby można było śledzić problemy i raportować sposób ich rozwiązywania.

• 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) są najbardziej kompetentne, aby usunąć awarię.
• 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, mają dodatkową motywację, aby wdrażać kod wysokiej jakości.

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 firmy Atlassian na temat zarządzania incydentami przedstawiamy bardzo przyjazne dla zespołów DevOps podejście do zarządzania incydentami.

Do zarządzania incydentami nie wystarczy po prostu narzędzie, konieczna jest odpowiednia mieszanka narzędzi, praktyk oraz ludzi. Przedstawiamy kilka najczęściej stosowanych kategorii narzędzi niezbędnych do skutecznego zarządzania incydentami:

• Monitorowanie incydentów: każdy incydent powinien być monitorowany i dokumentowany, aby można było identyfikować trendy i dokonywać porównań w czasie.
• Pokój czatu: Kanał służący do komunikacji tekstowej w czasie rzeczywistym jest niezbędny do diagnozowania i usuwania incydentów jako zespół. Zapewnia on bogaty zbiór danych do późniejszej analizy reakcji.
• Czat wideo: w przypadku wielu incydentów czat wideo stanowi uzupełnienie czatu tekstowego, umożliwiając zespołom omówienie ustaleń i zaplanowanie strategii reagowania.
• System powiadamiania: narzędzie, np. Jira Service Management, 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 statusu: informowanie o statusie zarówno wewnętrznych interesariuszy, jak i klientów za pośrednictwem Statuspage pomaga wszystkim być na bieżąco.