Przyszłość zarządzania incydentami IT, reagowania na nie i zapobiegania im

Cofnij się o pięć lat i zapytaj zespół IT, kto jest odpowiedzialny za zarządzanie incydentami. Praktycznie w każdym przypadku usłyszysz odpowiedź „my”.

Zadaj to samo pytanie teraz, a prawdopodobnie rozmówca wspomni nie tylko o zespołach IT, ale także DevOps, SecOps i architektonicznych. Wiele organizacji powoli zwraca się w stronę koncepcji „odpowiadasz za to, co tworzysz”.

Wyraźną zaletą tego podejścia jest fakt, że odciąża zespoły IT i przyspiesza czas reakcji, przenosząc odpowiedzialność na osoby, które najlepiej znają kod. Pozwala to zminimalizować czas przestojów i zmaksymalizować produktywność zespołu. Zachęca również do tworzenia kodu dobrej jakości. (Jeśli to Ty jesteś osobą, która wstaje o 3 nad ranem z powodu błędu, istnieje szansa, że przy następnym wdrażaniu kodu w środowisku produkcyjnym sprawdzisz go dwa lub trzy razy, aby nie musieć ponownie wstawać o 3).

Trudnością w przypadku tego podejścia jest fakt, że organizacje mimo wszystko potrzebują pewnej centralizacji. Kierownictwo musi mieć dostęp do raportów i dokumentacji. Interesariusze w firmie chcą otrzymywać aktualne informacje. Chcą obserwować wskaźniki dotyczące incydentów, takie jak średni czas rozwiązywania lub potwierdzenia. Oczekują precyzyjnych aktualności na temat incydentów, raportów z analiz post-mortem incydentów i działań naprawczych.

Dla wielu firm, które z powodzeniem kroczą w kierunku decentralizacji, odpowiedzią na to wyzwanie jest technologia zapewniająca decentralizację i autonomię zespołu w celu sprawnego rozwiązywania incydentów, a jednocześnie centralizację informacji, aby cała firma była na bieżąco.

Podobnie jak w przypadku każdej innej dużej zmiany, która może zakłócić przepływy pracy i spowodować nieprzewidziane konsekwencje, dobrym rozwiązaniem stosowanym przez wiele organizacji jest decentralizacja małymi krokami.

Organizacje rozpoczynają od zidentyfikowania zespołu, który jest dobrze przystosowany kulturowo do takiej zmiany i zarządza aplikacją lub produktem niskiego ryzyka. Następnie przenoszą odpowiedzialność za zarządzanie incydentami związanymi z tą konkretną aplikacją lub tym produktem na wspomniany zespół. Szkolą członków, wprowadzają harmonogram dyżurów domowych i śledzą postępy, zadając następujące pytania:

• Czy udało się skrócić czasy odzyskiwania?
• Jakie bariery kulturowe napotyka zespół?
• Jakie narzędzia musiał wdrożyć zespół IT?
• Jakie procesy zespół musiał zakomunikować?
• Czy aktualizacje systemu wychodzące z tego zespołu są lepsze?
• Czy liczba incydentów spadła?
• Jakie wnioski możemy wyciągnąć z tego wstępnego testu, jeśli zdecydujemy się wdrożyć taką decentralizację w innych zespołach?

Takie testowe przypadki dostarczają podstaw do podjęcia decyzji o ewentualnym wdrożeniu ram postępowania „odpowiadasz za to, co tworzysz” w całej firmie, a w przypadku decyzji pozytywnej, pomagają ustalić sposób skutecznego wdrażania w zespołach.

Ten krok w kierunku decentralizacji wymaga również zwiększenia stopnia współpracy między zespołami. Jeśli zespół DevOps zostanie zaangażowany w proces zarządzania incydentami, jego członkowie będą potrzebowali miejsca przy stole na spotkaniach w ramach procesu zarządzania incydentami zespołu IT. Jeśli z kolei zespół IT nadal pomaga kierować praktykami zarządzania incydentami, jego członkowie muszą uczestniczyć w analizach post-mortem przeprowadzanych przez inne zespoły.

Każdy zespół wnosi w proces zarządzania incydentami własne mocne strony. W przypadku zespołów IT jest to umiejętność opracowywania praktyk i dokumentacji oraz przestrzegania wytycznych. Zespoły DevOps są dobre w zmianach i zdobywaniu wiedzy. Zespoły SecOps pozwalają wnieść spojrzenie z perspektywy bezpieczeństwa.

W celu zacieśniania współpracy między zespołami firmy, które robią to naprawdę dobrze, otwarcie dzielą się informacjami, wzmacniają empatię i eliminują dociekanie winy w relacjach międzyzespołowych, wykorzystują narzędzia czatu do zapewnienia komunikacji między zespołami w trakcie incydentów i stawiają na przeglądy incydentów, w których każdy ma swoje miejsce przy stole.

W wytycznych ITIL zarządzanie incydentami zazwyczaj postrzegane jest jako praktyka odrębna od zapobiegania incydentom. Obydwie są ważnymi elementami układanki, jaką stanowi ITSM, jednak rzadko idą ze sobą w parze.

Problem z tym podejściem polega na tym, że przewiduje wyłącznie reaktywny charakter zarządzania incydentami. Pracownicy pełniący dyżury domowe mają za zadanie gasić pożary, a gdy tylko jeden zostaje ugaszony, przechodzą do kolejnego. Jedynym celem w tym procesie jest odzyskanie sprawności, czyli przywrócenie funkcjonalności systemu.

Jednak odzyskiwanie to nie wszystko. Z czasem coraz więcej zespołów IT uzmysławia to sobie i odpowiednio dostosowuje swoje działania, włączając zapobieganie w proces zarządzania incydentami i oceniając swoją wydajność na podstawie takich wskaźników, jak średni czas rozwiązywania, a nie średni czas przywracania.

Takie podejście często bywa nazywane zarządzaniem problemami, a jego celem jest zbliżenie do siebie obu procesów w celu zapewnienia, aby zespoły nie przeskakiwały do kolejnego pożaru tuż po ugaszeniu pierwszego, reagowały na incydent, przywracały działanie systemów po jego wystąpieniu i wyciągały z niego wnioski, a następnie stosowały te wnioski zarówno w odniesieniu do problemu, z którym się borykają, jak i w szerszej perspektywie, do systemów produktów i usług, którymi zarządzają.

Wiele korporacyjnych organizacji IT ma specjalną praktykę w zakresie zarządzania problemami. Zazwyczaj traktują ją jako odrębny proces przypisany do odrębnego zespołu. W Atlassian opowiadamy się za pójściem o krok dalej i stosujemy podejście mieszane, w którym zespoły ds. eksploatacji IT oraz programistyczne uwzględniają praktykę zarządzania problemami we własnych praktykach dotyczących incydentów. Pozwala to zyskać lepszy wgląd w incydent i zapewnić, że analiza incydentu zostanie przeprowadzona wkrótce po jego wystąpieniu.

W dłuższej perspektywie zapobieganie incydentom przynosi większe korzyści niż szybkie reagowanie na nie.

Jednym z wyzwań związanych z takim przejściem na współpracę między zespołami w zakresie zarządzania incydentami jest to, że niektóre zespoły bardziej swobodnie podchodzą do procesu i dokumentacji.

Jest to jeden z tych obszarów, w których zespoły IT mogą zapewnić nadzór i wnieść istotną wartość, nawet jeśli inne zespoły podejmują się zarządzania własnymi produktami. W końcu nikt nie chce zajmować się poważnym incydentem o 3 nad ranem, gdy jeszcze nie zdołał się rozbudzić, bez solidnego planu.

Podczas kompletowania zespołów na potrzeby procesu zarządzania incydentami przedstawiciele działu IT mogą pomóc w udzieleniu odpowiedzi na podstawowe pytania, które będą decydowały o kształcie planu. Przykładowo:

• Jak wygląda wasza reakcja na incydent?
• Jakich wartości będziecie przestrzegać?
• Jak zareagujecie w razie incydentu?
• Gdzie znajdują się niezbędne informacje na temat obsługiwanych systemów krytycznych? Jeśli znajdują się w wielu systemach, jak można je zebrać, aby ułatwić dostęp do nich ekspertom pełniącym dyżury domowe?
• Czy wasz proces i dokumentacja są przystosowane do współpracy, a zespół ma wpływ na ich kształt?

To przejście w kierunku decentralizacji, współpracy i łączenia zarządzania incydentami i problemami wymaga czegoś więcej niż tylko zmiany przydziału obowiązków i włączenia specjalisty IT w analizy post-mortem przeprowadzane przez zespół DevOps. Kluczem do sukcesu nie są tutaj technologie ani nawet procesy. Jest nim zbudowanie kultury wewnętrznej sprzyjającej tym zmianom.

Jest to część, którą wiele firm stara się pomijać, choć stanowi podstawę udanej transformacji. Czym zatem charakteryzuje się kultura wspierająca zdecentralizowane, oparte na współpracy zarządzanie incydentami skoncentrowane na przyszłości?

W Atlassian uważamy, że jej podstawowe komponenty to: