Close

Zarządzanie incydentami dla dynamicznych zespołów

Zmieniająca się rola zarządzania incydentami i problemami

W ciągu ostatnich dziesięciu lat zarządzanie incydentami znacznie się zmieniło.

Wytyczne ITIL zostały zaktualizowane. Zespoły IT zaczęły dzielić się obowiązkami w myśl koncepcji DevOps i SecOps. Postępująca złożoność systemów doprowadziła do opracowania bardziej skomplikowanych rozwiązań z zakresu zarządzania incydentami. Wiele firm zaczyna stosować analizy post-mortem bez wskazywania winnych oraz nowe sposoby pomiaru wydajności.

Zarządzanie incydentami stale się zmienia i ewoluuje, podobnie jak zarządzanie problemami, a także zależności między tymi dwoma praktykami.

Czym jest problem i czym różni się od incydentu?

Według ITIL problem jest problem jest „przyczyną lub potencjalną przyczyną co najmniej jednego incydentu”.

Natomiast incydent to pojedyncze nieplanowane zdarzenie, które powoduje zakłócenia w świadczeniu usługi.

Innymi słowy, incydenty to paskudne epizody, które pracownicy pełniący dyżur domowy zazwyczaj starają się rozwiązać możliwie jak najszybciej i najbardziej wyczerpująco. Natomiast problemy są główną przyczyną tych zdarzeń.

Problem może doprowadzić do wystąpienia jednego incydentu lub wielu incydentów. Z kolei przyczyną incydentu może być jeden problem, a czasami wiele problemów.

Kolumna serwerów, w której jeden się przewrócił, powodując problemy

Incydentem była na przykład pięciogodzinna awaria, która w 2016 roku kosztowała Delta Airlines 150 mln USD. Problemami, które doprowadziły do tego incydentu były przerwa w dostawie zasilania do centrum operacyjnego i przypuszczalnie brak planu awaryjnego na wypadek utraty zasilania.

Podobnie incydentem była 12-godzinna awaria sklepu z aplikacjami, która kosztowała firmę Apple około 25 mln USD. Co było problemem w tym przypadku? Błąd związany z systemem DNS.

Gdybyśmy chcieli przenieść te pojęcia poza obszar technologii, pójście do lekarza z powodu migreny byłoby incydentem. A przyczyna migreny — alergie, problemy ze wzrokiem lub stres — byłaby problemem.

Zarządzanie incydentami a zarządzanie problemami

Oczywiście problemy i incydenty są ze sobą nierozerwalnie związane. Jedno prowadzi do drugiego, a zespoły muszą zwracać uwagę na obydwa elementy.

Zgodnie z najnowszymi wytycznymi ITIL w tradycyjnych zespołach IT konieczne jest zarządzanie zarówno problemami, jak i incydentami, jednak procesy te są rozłączne. Zarządzanie problemami jest praktyką polegającą na zapobieganiu incydentom lub ograniczaniu ich wpływu. Zarządzanie incydentami koncentruje się na rozwiązywaniu incydentów w czasie rzeczywistym.

Zaletą podejścia ITIL jest to, że priorytetowo traktuje podstawowe cele zarówno zarządzania problemami, jak i zarządzania incydentami. Rozdzielenie tych praktyk i nadanie im równej wagi w wytycznych jest przypuszczalnie próbą uniknięcia powszechnego problemu polegającego na ciągłym gaszeniu pożarów związanych z incydentami przez zespoły IT bez usuwania ich głównej przyczyny.

Jeśli głównym celem menedżera ds. incydentów jest szybkie rozwiązywanie incydentów, a głównym celem menedżera ds. problemów jest zapobieganie, połączenie tych ról może oznaczać, że priorytet jednego z tych celów — a obydwa z nich są kluczowe dla organizacji — może zostać obniżony kosztem drugiego.

Wadą takiego podejścia jest fakt, że rozdzielenie tych dwóch praktyk — które w rzeczywistości są ze sobą ściśle powiązane — może prowadzić do luk w wiedzy i załamania komunikacji między procesami rozwiązywania incydentów i analizy mającej na celu ustalenie ich głównej przyczyny.

DevOps i zmieniające się role zarządzania problemami i incydentami

Jak zwykle, bazujący na współpracy ruch DevOps zaciera granice wyznaczane przez tradycyjne myślenie o IT, postrzegając zarządzanie problemami i incydentami nie jako dwie odrębne praktyki, ale jako dwie zachodzące na siebie części tego samego procesu.

Diagram ITIL z odrębnymi kołami zarządzania problemami i incydentami oraz diagram DevOps, w którym koła zarządzania problemami i incydentami częściowo się pokrywają

Ta zmiana wynika nie tylko z faktu, że te praktyki są dwiema stronami tego samego medalu — zapobiegania incydentom i ich rozwiązywania — ale także z podejścia DevOps, w którym zazwyczaj deklaruje się, że:

  • Incydenty często mają więcej niż jedną główną przyczynę.
  • Analizy post-mortem powinny przebiegać bez wskazywania winnych i uwzględniać każdy zespół, który został dotknięty skutkami incydentu.
  • Współpraca jest podstawą ciągłego doskonalenia.

Nakładanie się obszarów zarządzania problemami i incydentami można powiązać również z dostrzegalną w całej branży zmianą w kierunku podejścia opartego na zasadzie „odpowiadasz za to, co tworzysz”. Gdy zespoły zajmujące się tworzeniem systemów stają się odpowiedzialne za rozwiązywanie incydentów dotyczących tych systemów, logiczne jest, że te same zespoły będą odpowiadać również za przeprowadzanie analiz post-mortem, wykonywanie wszystkich prac detektywistycznych w celu ustalenia głównej przyczyny incydentu oraz opracowanie zaleceń, które pozwolą uniknąć wystąpienia podobnych incydentów w przyszłości lub ograniczyć ich skutki.

Pomostem łączącym zarządzanie problemami oraz incydentami jest tutaj analiza post-mortem bez wskazywania winnych, w ramach której po uporaniu się z najpilniejszymi zadaniami menedżerowie ds. incydentów zamieniają się w detektywów i podejmują zadanie związane z zarządzaniem problemami oraz zapobieganiem im.

Najważniejszym wyzwaniem, przed którym stają zespoły DevOps zacierające granice między tymi dwoma praktykami, jest zadbanie o to, aby zarządzanie problemami — które choć mniej pilne, jest niezwykle wartościowe z perspektywy celów długoterminowych — nie zostało uznane za mniej priorytetowe w obliczu naglącej sytuacji związanej z zarządzaniem incydentami.

Oczywiście, połączenie zarządzania incydentami i zarządzania problemami często jest łatwiejsze w teorii niż w praktyce, ale jest niezbędne do znalezienia i rozwiązania pierwotnej przyczyny. Odkryj, jak rozwiązanie do zarządzania incydentami Jira Service Management daje zespołom elastyczność pracy zespołowej: rejestruj kontekst i twórz rozbudowane osie czasu podczas rozstrzygania incydentów i wykorzystaj to, aby pomóc zespołom lepiej zarządzać problemami.

Up Next
ChatOps