Prowadzenie procesu zarządzania poważnym incydentami

Zarządzanie incydentami o dużym wpływie i ich rozwiązywanie

Zarządzanie poważnymi incydentami (w Atlassian często nazywane po prostu zarządzaniem incydentami) jest procesem stosowanym przez zespoły DevOps i ds. eksploatacji IT w celu reagowania na nieplanowane zdarzenie lub przerwę w świadczeniu usługi i przywracania jej do stanu funkcjonalnego.

Czym jest poważny incydent?

Co zatem może stanowić poważny incydent? Poważnym incydentem będzie krytyczna awaria lub utrata dostępu do usługi.

Definicja poziomu krytyczności różni się w zależności od organizacji. W Atlassian posługujemy się trzema poziomami ważności, a dwa najwyższe (SEV 1 i SEV 2) są traktowane jako poważne incydenty.

Jeśli usługa zorientowana na klienta nie działa u wszystkich klientów Atlassian, mamy do czynienia z incydentem o poziomie SEV 1. Jeśli ta sama usługa nie działa jedynie u części klientów, jest to poziom SEV 2. Obydwa te poziomy oznaczają poważny incydent i wymagają natychmiastowej reakcji naszych zespołów ds. zarządzania incydentami.

Każdy problem, który nie przeszkadza w wykonywaniu podstawowych zadań, otrzymuje poziom ważności 3 i nie jest uznawany za poważny incydent.

Definiowanie procesu zarządzania poważnymi incydentami

Cykl życia incydentu (czasami nazywany również procesem zarządzania incydentem) jest ścieżką realizowaną w celu zidentyfikowania, rozwiązania i zrozumienia incydentów oraz zapobiegania ich powtórnemu wystąpieniu.

Procesy zarządzania incydentami różnią się w zależności od firmy, ale kluczem do sukcesu każdego zespołu jest jasne zdefiniowanie i zakomunikowanie poziomów ważności, priorytetów, ról i procesów z wyprzedzeniem — zanim jeszcze dojdzie do poważnego incydentu.

Aby wszyscy w jednakowy sposób pojmowali priorytety, role i procesy, każdy zespół, który opracowuje lub rewiduje swój proces zarządzania poważnymi incydentami, powinien zacząć od udzielenia przejrzystych odpowiedzi między innymi na następujące pytania:

• Co stanowi poważny incydent dla naszej firmy lub naszego produktu?
• Jak zdefiniujemy poziomy ważności i poziomy priorytetów incydentów? Jeśli jednocześnie wydarzy się więcej niż jeden poważny incydent, skąd będziemy wiedzieć, którym zająć się w pierwszej kolejności?
• Kto jest odpowiedzialny za zajmowanie się poważnymi incydentami? Jakie role będą mieli członkowie zespołu? W jaki sposób te role zostaną zdefiniowane i zakomunikowane?
• Jaki proces będą stosować zespoły w przypadku poważnego incydentu? Czy istnieje więcej niż jeden proces w zależności od rodzaju incydentu?
• Jak często będziemy komunikować się z interesariuszami — zarówno wewnętrznymi, jak i zewnętrznymi? Jaki jest nasz plan komunikacji?
• Jak będzie wyglądał nasz harmonogram dyżurów domowych w przypadku poważnych incydentów? Kto jest odpowiedzialny za incydent o 2 nad ranem albo w weekend? A w czasie urlopu?
• Kiedy i w jaki sposób powinniśmy powiadamiać naszego menedżera ds. incydentów pełniącego dyżur domowy, aby nadać priorytet szybkiemu rozwiązywaniu poważnych incydentów, ale jednocześnie uniknąć niewrażliwości na alerty?

Proces zarządzania poważnymi incydentami w Atlassian

W Atlassian proces zarządzania incydentami obejmuje wykrycie i zgłoszenie nowego incydentu, rozpoczęcie komunikacji, przeprowadzenie oceny, wysłanie wstępnych komunikatów, eskalację, delegację, wysłanie komunikatów uzupełniających, przegląd i rozwiązanie.

Wykrycie

Najpierw incydent zostaje wykryty przez naszą technologię, pracowników lub klientów, którzy przesyłają zgłoszenia. Osoba, która wykryje incydent (np. technik, który zauważy problem, lub pracownik działu obsługi klienta, który otrzyma telefon od sfrustrowanego klienta), ma obowiązek zarejestrować incydent w naszym systemie i określić poziom jego ważności.

Zanim incydent trafi do naszych zespołów, ma już ustalony poziom ważności SEV 1, 2 lub 3. Incydenty o poziomach ważności SEV 1 i 2 traktujemy jako poważne incydenty, a incydenty o poziomie SEV 3 są uznawane za incydenty o mniejszym znaczeniu.

Zgłoszenie nowego incydentu

Po utworzeniu zgłoszenia incydentu do pełniącego dyżur domowy specjalisty odpowiedzialnego za daną usługę jest wysyłane powiadomienie.

Alerty wysyłane w Atlassian zawierają informacje na temat poziomu ważności i priorytetu incydentu, a także jego krótki opis, aby na pierwszy rzut oka można było stwierdzić, czy jest to incydent o najwyższym priorytecie, czy coś, co może poczekać, jeśli akurat inny incydent jest w toku.

Rozpoczęcie komunikacji

Pierwszym krokiem menedżera ds. incydentów po otrzymaniu alertu jest powiadomienie, że trwają prace nad rozwiązaniem incydentu. Menedżer zmienia status incydentu na Naprawianie i konfiguruje kanały komunikacyjne dla zespołu.

Konieczne jest oferowanie elastycznych kanałów komunikacji w całym procesie reagowania na incydenty, ponieważ dzięki temu zespoły utrzymują ze sobą kontakt, korzystając z preferowanej metody. Jira Service Management integruje wiele kanałów komunikacji, takich jak widget statusu przeznaczony do osadzania, dedykowana strona statusu, poczta e-mail, narzędzia czatu, media społecznościowe i SMS-y, pozwalając zminimalizować przestoje.

Ocena

Menedżer ds. incydentów został powiadomiony, a kanały komunikacji są uruchomione. Następny krok to ocena samego incydentu.

W przypadku naszych zespołów ten proces rozpoczyna się od zadania szeregu pytań, na które zespół musi odpowiedzieć:

• Jak incydent wpływa na klientów i pracowników Atlassian?
• Co widzą klienci?
• Ilu klientów dotyczy problem? (niektórych, wszystkich?)
• Kiedy rozpoczął się incydent?
• Ile zgłoszeń do działu wsparcia zostało utworzonych w związku z tym incydentem?
• Czy w grę wchodzą inne czynniki, które wpływają na poziom ważności lub priorytet incydentu bądź wymuszają zmianę podejścia do incydentu? (Np. kwestie bezpieczeństwa, kryzys PR w mediach społecznościowych itp.).

Gdy już odpowiemy na te pytania, możemy bez obaw przejść do diagnostyki i propozycji naprawy bądź zmienić poziom ważności i priorytet incydentu, jeśli zachodzi taka potrzeba.

Wysłanie komunikatów początkowych

Po zweryfikowaniu wystąpienia incydentu komunikacja z naszymi klientami i pracownikami staje się najwyższym priorytetem. Jak wspominamy w naszym podręczniku:

„Celem początkowej komunikacji wewnętrznej jest skoncentrowanie reakcji na incydent w jednym miejscu i wyeliminowanie nieporozumień. Celem komunikacji zewnętrznej jest poinformowanie klientów, że ma się świadomość wystąpienia problemu i trwają pilne prace nad jego rozwiązaniem”.

Szybka, precyzyjna komunikacja pomaga zbudować i utrzymać zaufanie klientów.

Mamy strategiczny plan informowania o incydentach i udostępniamy regularnie aktualności na temat statusu w prostym formacie. Wysyłamy również wiadomość e-mail do zdefiniowanej listy interesariuszy, która obejmuje nasze kierownictwo techniczne, menedżerów ds. poważnych incydentów i inny kluczowy personel wewnętrzny. Jak już wcześniej wspomniano, wszystkie te metody komunikacji można dostosować w ramach Jira Service Management oraz dopasować do planu reagowania na incydenty dowolnej organizacji.

Eskalacja

Czasami incydent zostaje szybko rozwiązany przez zespół pełniący dyżur domowy. Jednak w przypadku, gdy tak się nie stanie, kolejnym krokiem jest eskalacja zgłoszenia do kolejnego eksperta lub zespołu ekspertów, którzy są lepiej przygotowani do rozwiązania tego konkretnego incydentu.

W Jira Service Management osoby reagujące mogą grupować powiązane zgłoszenia i dodawać współpracowników do zgłoszenia w celu koordynowania alertów. Osoby reagujące mogą również automatycznie rejestrować wszystkie czynności w krótkim czasie od wystąpienia incydentu oraz korzystać z automatyzacji dostępu i artykułów z bazy wiedzy, aby szybko analizować incydenty i podejmować działania zaradcze.

Delegowanie

W przypadku eskalowania zgłoszenia do nowej osoby menedżer ds. incydentów deleguje do takiej osoby rolę. W Atlassian te role są wstępnie zdefiniowane, dzięki czemu członkowie zespołu błyskawicznie wiedzą, czego się od nich oczekuje.

Czasami poważne incydenty wymagają udziału jednego menedżera ds. incydentów i niewielkiego zespołu. Innym razem sytuacja może wymagać zaangażowania wielu liderów ds. technicznych, a nawet wielu menedżerów ds. incydentów. Początkowy menedżer ds. incydentów ma za zasadnie ustalić, czy istnieje taka potrzeba, i zaangażować odpowiednie osoby.

Wysyłanie komunikatów uzupełniających

W miarę postępu incydentu wysyła się kolejną partię komunikatów poza zespół techniczny, aby uspokoić klientów oraz pracowników, przekazać im bieżące informacje i podtrzymać ich zaufanie. Jest to łatwe, gdy współpracownicy mogą zarządzać alertami na różnych platformach komunikacyjnych, aby na bieżąco śledzić reakcję na incydenty.

Przejrzyj

Niestety nie ma jednego uniwersalnego sposobu rozwiązywania incydentów. Dlatego na tym etapie procesu:

• Obserwujemy, co się dzieje, dzielimy się spostrzeżeniami z zespołem i weryfikujemy je wspólnie.
• Opracowujemy teorie na temat przyczyn zaistniałych zdarzeń (i możliwości naprawy).
• Opracowujemy i przeprowadzamy eksperymenty, aby zweryfikować poprawność naszych teorii.
• Powtarzamy.

W trakcie całego tego procesu menedżer ds. incydentów uważnie śledzi sytuację. Czy poszczególni członkowie zespołu nie są zbyt obciążeni? Czy ktoś potrzebuje przerwy? Czy potrzebujemy świeżego spojrzenia? W razie potrzeby delegujemy prace do kolejnych osób.

Rozwiązanie

W naszym podręczniku zarządzania incydentami rozwiązanie zdefiniowano jako stan, „gdy bieżący lub bezpośredni wpływ na działalność dobiegł końca”.

Na tym etapie kończy się sytuacja awaryjna, a zespół przechodzi do usuwania szkód i analiz post-mortem.

Wpisy postmortem

Nasz cykl życia incydentu kończy się wraz z rozwiązaniem incydentu, jednak w Atlassian nie oznacza to końca procesu. Chcemy zrobić wszystko, co w naszej mocy, aby zapobiec ponownemu wystąpieniu incydentu. Dlatego kolejnym krokiem jest przeprowadzenie analizy post-mortem bez wskazywania winnych, która ma na celu ustalanie przyczyny incydentu i zmniejszenie ryzyka jego wystąpienia w przyszłości.

Użyj szablonów analizy post-mortem z Jira Service Management do łatwego tworzenia i eksportowania raportów post-mortem (z uwzględnieniem ram czasowych powiązanych incydentów) do aplikacji Confluence, aby osoby reagujące mogły kontynuować współpracę z zespołami interdyscyplinarnymi i śledzić dalsze działania, a także unikać podobnych incydentów w przyszłości.

Role i obowiązki

Role i obowiązki będą się różnić w zależności od kultury organizacji, wielkości zespołu, harmonogramów dyżurów domowych i innych czynników. Oto niektóre z typowych ról związanych z zarządzaniem poważnymi incydentami:

Menedżer ds. incydentów: osoba odpowiedzialna za nadzorowanie rozwiązywania incydentu.

Lider ds. technicznych: specjalista ds. technicznych wyższego szczebla, którego zadaniem jest ustalenie, co i dlaczego nie działa, określenie najlepszego sposobu działania i pokierowanie zespołem technicznym.

Menedżer ds. komunikacji: specjalista ds. komunikacji (często z zespołu PR lub obsługi klienta) odpowiedzialny za komunikację z klientami wewnętrznymi i zewnętrznymi dotkniętymi skutkami incydentu.

Lider ds. obsługi klienta: jest to osoba odpowiedzialna za terminowe i właściwe odpowiadanie na napływające zgłoszenia, połączenia telefoniczne oraz tweety.

Lider ds. mediów społecznościowych: specjalista ds. mediów społecznościowych odpowiedzialny za przekazywanie informacji na temat incydentu w kanałach mediów społecznościowych.

Inne często stosowane role to:

Analityk ds. głównych przyczyn lub menedżer ds. problemów: osoba, której obowiązki wykraczają poza zakres rozwiązywania incydentu i są związane z rozpoznawaniem głównej przyczyny oraz wszelkich zmian, które trzeba wprowadzić, aby uniknąć wystąpienia podobnego problemu w przyszłości.

Rada ds. badania poważnych incydentów: grupa odpowiedzialna za przeprowadzanie dochodzeń i zarządzanie zmianami.

Rozwiązanie do zarządzania incydentami, takie jak Jira Service Management, pomaga w realizacji każdego etapu procesu reagowania — od zorganizowania harmonogramu dyżurów domowych i opracowania alertów przez ujednolicenie zespołów w celu usprawnienia współpracy po przeprowadzanie analiz post-mortem incydentów.