Close

Zarządzanie incydentami dla dynamicznych zespołów

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

Dawniej obowiązek reagowania na incydenty technologiczne niemal zawsze spoczywał na zespole IT. Często zespół siedzący w centrum operacji sieciowych (NOC) monitorował systemy i reagował na awarie. Dostawca mógł opracowywać oprogramowanie, jednak jego wdrożenie i obsługa należały do obowiązków zespołu ds. eksploatacji IT klienta. Obecnie, w dobie powszechnych usług w chmurze, dostawca nie tylko tworzy oprogramowanie, ale także wdraża je i obsługuje.

Zarządzanie incydentami wciąż jednak pozostaje podstawową praktyką ITSM. A zespoły IT mają za sobą długą historię opracowywania wytycznych, zarządzania budżetami oraz przyjmowania na siebie pełnego ciężaru związanego z diagnozowaniem, naprawianiem i dokumentowaniem poważnych incydentów oraz zapobieganiem ich występowaniu.

Oczywiście, jak to bywa w dziedzinie technologii, przeszłość nie musi być wyznacznikiem przyszłości — a obecnie praktyka zarządzania incydentami ulega zmianie. W coraz większym stopniu angażuje się w nią zespoły DevOps, SecOps i architektoniczne. Nowe technologie i wzajemnie połączone produkty zmieniły sposób, w jaki zarządzamy incydentami. Aby za tym nadążyć, zmieniają się również podejścia, praktyki oraz struktury zespołów.

Jak więc zmienia się zarządzanie incydentami i co to oznacza dla przyszłości naszych ról, produktów, procesów i zespołów?

Krok w stronę decentralizacji

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.

Powolna droga do decentralizacji

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.

Decentralizacja oznacza współpracę między zespołami

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.

Zmiana podejścia z reaktywnego na proaktywne

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.

Utrzymanie kursu dzięki procesowi i dokumentacji

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?

Czy kultura Twojej firmy jest gotowa na zmianę?

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:

Otwartość i wymiana informacji

Jeśli zespoły nie wiedzą i nie mają możliwości dowiedzieć się, czym zajmują się inne zespoły, tracimy okazję do odkryć, które mogłyby doprowadzić do ulepszenia komunikacji, procesów oraz produktów.

Myślenie ukierunkowane na klienta

Gdy zadajemy takie pytania, jak „co jest naprawdę najlepsze dla klienta?”, czasami uzyskane odpowiedzi nie pasują do naszych obecnych praktyk. Potrzeba celowego skupienia na kliencie, aby zbliżyć się do takiego rodzaju komunikacji, procesu czy wydajności strukturalnej, który ostatecznie sprawi, że nasze produkty będą dla klientów lepsze.

Regularne kontrole kondycji

Jak radzi sobie każdy zespół? Jakie odczucia towarzyszą poszczególnym członkom zespołu? Co zespół może poprawić? Z czym sobie świetnie radzi? W Atlassian mamy porady strategiczne dla zespołów, które pomagają nam w ocenie kondycji naszych zespołów i wprowadzaniu w nich nowych sposobów pracy.

Empatia

Jeśli zespoły DevOps wytykają palcami zespoły IT, podczas gdy te drugie przewracają przysłowiowymi oczami na myśl o luźniejszym podejściu DevOps, nie jest to przepis na współpracę. Wzmacnianie empatii oraz więzi międzyzespołowych jest niezwykle istotne, jeśli chcemy, aby zespoły komunikowały się ze sobą, współpracowały i razem tworzyły innowacje.

Wzmocnienie pozycji

Zespoły powinny mieć możliwość szybkiego rozwiązywania problemów i niezależnego podejmowania decyzji, gdy tylko jest to możliwe. Członkowie zespołów powinni mieć poczucie, że mogą swobodnie zgłaszać swoje pytania, sugestie lub wątpliwości, niezależnie od ich pozycji w zespole czy doświadczenia.

Jeśli młodsi programiści mają poczucie, że wolno im zabierać głos na spotkaniach i sygnalizować błędy — nawet jeśli za dany fragment kodu odpowiada ktoś bardziej doświadczony — otwiera się przestrzeń dla nowych, innowacyjnych pomysłów, doskonalenia procesów i wyłapywania błędów, zanim trafią do ostatecznej wersji kodu.