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

Every incident must be prioritized. Start by assessing its impact on the business, the number of people who will be impacted, any applicable SLAs, as well as the potential financial, security, and compliance implications of the incident. Compare this incident to all other open incidents to determine its relative priority. As a best practice, define your severity and priority levels before an incident happens, making it simpler for incident managers to gauge priority quickly.

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ąć.

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.

Increasingly the software you rely on for life and work is not being hosted on a server in the same physical location as you. It’s likely a web-accessed application deployed in a data center for thousands or millions of users around the globe. For teams tasked with running these services, agility and speed are paramount. Any downtime has the potential to affect thousands of organizations, not just one.

An advantage of the “you build it, you run it” approach is that it offers the flexibility agile teams need, but it can also obscure who is responsible for what and when. DevOps teams can be comfortable—and successful—with less structured development processes. But it’s best to standardize on a core set of processes for incident management so there is no question how to respond in the heat of an incident, and so you can track issues and report how they’re resolved.

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.
• Alerting system: A tool such as Jira Service Management integrates with your monitoring system and manages on-call rotations and escalations.
• 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.