Reagowanie na zdarzenia

Kluczowe wnioski: Proces reagowania na incydenty w Atlassian obejmuje dziesięć kroków — wykrycie, zgłoszenie, rozpoczęcie komunikacji, ocenę, wysłanie wstępnej wiadomości, eskalację, delegowanie, wysłanie wiadomości uzupełniającej, przegląd, rozwiązanie. Jest prowadzony przez menedżera ds. incydentów od momentu zarejestrowania zgłoszenia aż do zakończenia wpływu na działalność firmy.

• Czym jest: To powtarzalne porady strategiczne oparte na zgłoszeniu incydentu w Jirze jako źródle rzetelnych informacji, dedykowanym kanale czatu i mostku wideo, współdzielonym dokumencie dotyczącym stanu incydentu, poziomach istotności decydujących o tym, kto zostanie powiadomiony, oraz stronie Statuspage do komunikacji wewnętrznej i zewnętrznej.

• Dlaczego ma znaczenie: Jasna struktura dowodzenia, nazwane kanały oraz udokumentowana oś czasu pozwalają koordynować reakcję w sytuacjach stresowych i stanowią podstawę do przeprowadzenia analizy post-mortem.

• Jak Jira Service Management pomaga: zapewnia zapisy incydentów, obsługę eskalacji i alertów dla osób pełniących dyżur domowy, integrację czatu i wideo oraz łącza do strony Statuspage i analiz post-mortem, dzięki czemu cały proces przebiega na jednej platformie.

W poniższych sekcjach opisano proces reagowania na incydenty stosowany w Atlassian. Menedżer ds. incydentu postępuje zgodnie z poniższą sekwencją kroków, aby poprowadzić incydent od momentu wykrycia do rozwiązania. Każdy z poniższych kroków stanowi osobną sekcję. Razem tworzą one porady strategiczne, z których korzystają nasi menedżerowie ds. incydentów.

Wykrywanie

Pracownicy Twojej firmy mogą dowiedzieć się o incydentach na wiele sposobów. Mogą zostać powiadomieni za pośrednictwem systemu monitorowania, zgłoszeń klientów lub dzięki własnym obserwacjom. Niezależnie od tego, jak dojdzie do incydentu, pierwszym krokiem podejmowanym przez zespół jest zarejestrowanie zgłoszenia incydentu (w naszym przypadku zgłoszenia Jiry). 

Korzystamy z łatwego do zapamiętania, krótkiego adresu URL, który umożliwia szybkie przekierowanie członków zespołu Atlassian do wewnętrznego portalu Jira Service Management. Członkowie zespołu Atlassian mogą sprawdzić, czy incydent jest już w toku, wyświetlając pulpit Jiry lub makro Jiry w Confluence. Zespoły, np. nasz zespół wsparcia klienta, mają pulpity skonfigurowane w znanych lokalizacjach, aby monitorować trwające incydenty.

W przypadku każdego zdarzenia wypełniamy poniższe pola:

Po utworzeniu zdarzenia identyfikator zdarzenia jest używany we wszystkich wiadomościach wewnątrz przedsiębiorstwa dotyczących tego zdarzenia.

Klienci często zgłaszają sprawy do działu wsparcia dotyczące incydentów, które mają na nich wpływ. Gdy nasze zespoły wsparcia klienta ustalą, że wszystkie te sprawy dotyczą tego samego incydentu, oznaczają je kluczem zgłoszenia tego incydentu, aby śledzić wpływ na klientów oraz łatwiej kontaktować się z osobami, których dotyczy incydent, gdy zostanie on rozwiązany.

Utwórz nowe zdarzenie

Po utworzeniu zgłoszenia zdarzenia, ale przed przypisaniem go do kierownika ds. zdarzeń, zdarzenie ma status nowe. Jest to status początkowy w naszym przepływie zadań dotyczących zdarzeń, czyli systemie Jira.

Dysponujemy usługą, która wykorzystuje elementy webhook w celu uruchomienia alertu wraz z wezwaniem, gdy zostanie utworzone nowe, ważne zdarzenie. Powoduje to powiadomienie dyżurującego kierownika ds. zdarzeń zajmującego się wybraną usługą. Przykładowo w przypadku zdarzenia dotyczącego usługi Bitbucket zostanie wezwany kierownik ds. zdarzeń związanych z usługą Bitbucket. Mamy również dostęp go zbiorczego harmonogramu wszystkich kierowników ds. najważniejszych zdarzeń (dyżurujący kierownicy ds. zdarzeń; ang. incident manager on call, IMOC).

Powiadomienie wraz z wezwaniem zawiera identyfikator zgłoszenia zdarzenia, informację o wadze zdarzenia i streszczenie, dzięki któremu kierownik ds. zdarzeń wie, z którego punktu rozpocząć zarządzanie zdarzeniem (zgłoszenie w systemie Jira), co jest nie tak i jak poważna jest sytuacja.

Otwórz komentarze

Pierwszą rzeczą, którą zajmuje się menedżer ds. incydentu, gdy będzie online, jest przypisanie sobie zgłoszenia incydentu i zmianę jego stanu na Naprawianie. Pole osoby przypisanej do zgłoszenia w Jirze również pokazuje, kto jest aktualnym menedżerem ds. incydentu. Podczas reagowania na sytuacje awaryjne bardzo ważne jest, aby jasno określić, kto jest odpowiedzialny, dlatego dość rygorystycznie podchodzimy do kwestii zapewnienia prawidłowych informacji w tym polu. 

Następnie menedżer ds. incydentu konfiguruje kanały komunikacji zespołu ds. incydentu. Celem na tym etapie jest zapewnienie, aby cała komunikacja zespołu ds. incydentu była prowadzona w dobrze znanych miejscach i skupiała się właśnie tam. Zazwyczaj korzystamy z trzech metod komunikacji zespołowej, z których każda jest reprezentowana przez pole w zgłoszeniu Jiry, dla każdego incydentu:

• Pokój czatu w aplikacji Slack lub innym komunikatorze. Umożliwia rejestrowaną z zastosowaniem znaczników czasowych komunikację pomiędzy członkami zespołu, dzielenie się obserwacjami, łączami i zrzutami ekranu. Nadanie kanałowi czatu takiej samej nazwy jak klucz zgłoszenia (np. HOT-1234) ułatwia dołączenie do konwersacji wymaganym osobom. 

• Czat wideo w aplikacji umożliwiającej odbywanie konferencji, np. Skype, Blue Jeans itp. lub zebranie, jeśli wszyscy pracują w tym samym miejscu. Według naszych obserwacji komunikacja bezpośrednia pomaga zespołom pracować szybciej i sprawniej.

• Strona w oprogramowaniu Confluence określana jako „dokument o stanie zdarzenia”. Podczas jednoczesnej edycji tej samej strony można zobaczyć, jakie informacje są gromadzone w czasie rzeczywistym. Jest to doskonała metoda śledzenia zmian (np. tabela zawierająca informacje o tym, kto co zmienił, kiedy, jak, dlaczego i jak przywrócić poprzedni stan), kilku strumieni zadań i rozbudowanych osi czasu. Dokument o stanie zdarzenia jest wyjątkowo przydatny, ponieważ jest źródłem prawdziwych informacji podczas przetwarzania zdarzeń złożonych lub rozłożonych w czasie.

Z naszych doświadczeń wynika, że podczas incydentu najlepiej sprawdza się jednoczesne korzystanie z czatu wideo i pokojów czatu, ponieważ każde z tych rozwiązań jest zoptymalizowane pod kątem innych potrzeb. Czat wideo doskonale sprawdza się w szybkim budowaniu wspólnego obrazu incydentu dzięki dyskusji grupowej, natomiast czat tekstowy świetnie nadaje się do prowadzenia rejestrowanej chronologicznie dokumentacji incydentu, udostępniania łączy do pulpitów, zrzutów ekranu i innych adresów URL.

Wspomniane metody mogą także służyć do zapisywania ważnych obserwacji, zmian i decyzji podejmowanych podczas nierejestrowanych rozmów. Zarządzający incydentami lub dowolna osoba w zespole ds. incydentów realizuje to działanie, po prostu notując obserwacje, zmiany i decyzje w wyznaczonym pokoju czatu w czasie rzeczywistym. To nic, że wygląda to tak, jakby ludzie mówili do siebie. Te notatki są niezwykle cenne podczas analizy post-mortem, gdy zespoły muszą zrekonstruować oś czasu incydentu i starają się dociec, jaka była jego przyczyna. 

Większość systemów czatu posiada funkcję tematu pokoju . Kierownik ds. zarządzania zdarzeniami aktualizuje temat pokoju, podając informacje o zdarzeniu i użyteczne linki, m.in.:

• Streszczenie zdarzenia i jego wagę.

• Kto pełni jaka rolę, począwszy od kierownika ds. zarządzania zdarzeniami.

• Łącza do zgłoszenia zdarzenia, pokoju czatu wideo i dokumentu o stanie zdarzenia.

Dzięki temu każda osoba z kluczem zgłoszenia danego incydentu może dołączyć do czatu i zapoznać się z sytuacją. (Należy pamiętać, że nazwa kanału czatu została utworzona na podstawie identyfikatora zgłoszenia incydentu, np. HOT-1234).

Na koniec zarządzający incydentami umieszcza w statusie swojego czatu klucz zgłoszenia incydentu, którym zarządza. Dzięki temu jego współpracownicy wiedzą, że zajmuje się incydentem. 

Oceń

Po skonfigurowaniu kanałów komunikacji pomiędzy członkami zespołu ds. incydentów należy ocenić incydent, aby zespół mógł zdecydować, co powiedzieć o incydencie i kto ma się zająć jego rozwiązaniem. 

Opracowaliśmy poniższy zestaw pytań, które mogą zadać swoim zespołom zarządzający incydentami: 

• Jakie są skutki dla klientów (wewnętrznych lub zewnętrznych)?

• Co widzą klienci?

• Ilu klientów dotyczy problem (niektórych, wszystkich)?

• Kiedy zaczęło się zdarzenie?

• Ile zgłoszeń do pomocy technicznej otrzymano od klientów?

• Czy istnieją inne czynniki, np. Twitter, zabezpieczenia lub utrata danych?

Teraz jest dobry moment, aby zacząć dodawać wpisy na osi czasu incydentu. Zapisz obserwacje zespołu, aby nowe osoby mogły się szybko zorientować w sytuacji. Będzie to również ważne na późniejszych etapach procesu analizy post-mortem. Upewnij się, czy czas rozpoczęcia incydentu pokrywa się ze zmianą (na przykład wdrożeniem w Bamboo), aby w razie potrzeby można było wycofać tę zmianę i potencjalnie rozwiązać incydent.

Na podstawie skutków incydentu i nakładu pracy koniecznej według naszych zespołów do rozwiązania incydentu przypisujemy zgłoszeniu jeden z następujących poziomów istotności: 

Po ustaleniu skutków zdarzenia, należy dostosować lub potwierdzić poziom ważności zgłoszenia zdarzenia i przekazać tę informację do zespołu. Jak wynika z naszych doświadczeń, określanie poziomów w liczbach jest bardzo przydatne z punktu widzenia komunikacji.

W firmie Atlassian zdarzenia o poziomie ważności 3 są przekazywane do zespołów ds. dostarczania usług w celu rozwiązania w godzinach pracy; zdarzenia o poziomie 1 i 2 wymagają wezwania członków zespołu w celu natychmiastowego rozwiązania. Różnica w reagowaniu na zdarzenia o wadze 1 i 2 jest subtelniejsza i zależy od usługi, jakiej dotyczy.

Tabelę poziomów istotności należy udokumentować i uzyskać akceptację wszystkich zespołów, aby zapewnić spójność reagowania na incydenty na podstawie skutków odczuwanych przez klientów.

Wyślij początkowe komentarze

Mając uzasadnioną pewność, że zdarzenie jest prawdziwe, należy jak najszybciej poinformować o nim klientów wewnętrznych i zewnętrznych. Celem początkowej komunikacji wewnętrznej jest zwrócenie uwagi na reagowanie na zdarzenie w jednym miejscu i uniknięcie nieporozumień. Celem komunikacji zewnętrznej jest poinformowanie klientów o swojej wiedzy na temat zdarzenia i pilnym poszukiwaniu przyczyn. Szybka i dokładna komunikacja na temat zdarzeń pomaga budować zaufanie wśród personelu i klientów.

W celu wewnętrznej i zewnętrznej komunikacji używamy narzędzia Statuspage. Dysponujemy oddzielnymi stronami przedstawiającymi informacje o statusie zdarzenia dla personelu przedsiębiorstwa i dla zewnętrznych klientów. Więcej informacji na temat obu tych rodzajów komunikacji pojawi się później, jednak na tę chwilę ważne jest, aby jak najszybciej rozpocząć komunikację. W tym celu korzystamy z poniższych szablonów:

Oprócz utworzenia zdarzenia w narzędziu Statuspage, wysyłamy wiadomość e-mail do odbiorców na liście dystrybucyjnej na potrzeby komunikacji w sprawie zdarzenia, na której znajdują się nasi kierownicy ds. inżynierii, kierownicy ds. poważnych zdarzeń i inni zainteresowani członkowie personelu. Wiadomość e-mail ma taką samą treść jak treść zdarzenia w wewnętrznym narzędziu Statuspage. Na wiadomość e-mail można odpowiedzieć i przesłać pytania, natomiast komunikacja za pośrednictwem narzędzia Statuspage jest raczej jednostronna.

Należy pamiętać, że we wszystkich wewnętrznych komunikatach dotyczących incydentu zawsze podajemy klucz zgłoszenia Jiry, dzięki czemu pracownicy wiedzą, do którego pokoju czatu powinni dołączyć, aby zadać dodatkowe pytania.

Przekaż

Masz kontrolę nad zdarzeniem, nawiązano komunikację zespołową, dokonano oceny sytuacji i poinformowano personel oraz klientów o przetwarzaniu zdarzenia. Co dalej?

Pierwszymi osobami, które udzielą odpowiedzi, mogą być osoby potrzebne w celu rozwiązania zdarzenia, jednak znacznie częściej konieczne jest zaangażowanie innych zespołów poprzez ich wezwanie. Nazywamy to eskalowaniem.

Kluczowym systemem w tym kroku jest narzędzie do tworzenia harmonogramów i powiadamiania na stronach, np. OpsGenie. System OpsGenie i podobne pozwalają definiować grafiki na wezwanie, aby dowolny zespół mógł ustalić dyżury osób, z którymi można się będzie skontaktować w nagłym wypadku. Jest to lepsze rozwiązanie od sytuacji, gdy przez cały czas potrzebna jest konkretna osoba („Daj znów Tomka”), ponieważ osoby nie zawsze będą dostępne (czasem wybierają urlopy, zmieniają pracę lub są przemęczone, jeśli zbyt często się do nich dzwoni). Jest również lepsze niż „najwyższe starania” na żądanie, ponieważ wiadomo, które osoby są odpowiedzialne za udzielanie odpowiedzi.

Należy zawsze dołączać identyfikator zgłoszenia zdarzenia w systemie Jira do powiadomienia o zdarzeniu na stronie. Kluczową kwestią jest, aby osoba, która otrzyma powiadomienie mogła dołączyć do pokoju na temat zdarzenia, używając tego identyfikatora.

Deleguj

Po przekazaniu zgłoszenia innej osobie, gdy pojawi się ona online kierownik ds. zdarzenia wyznacza rolę tej osobie. Jeśli osoba będzie wiedziała, czego się od niej wymaga w związku z pełnioną rolą, będzie mogła pracować szybko i efektywnie jako członek zespołu ds. zdarzenia.

Role wykorzystywane w przedsiębiorstwie Atlassian:

• Zarządzający incydentami, opisany na stronie Informacje ogólne.

• Lider techniczny, starszy specjalista ds. udzielania odpowiedzi w sprawach technicznych. Odpowiedzialny za opracowywanie teorii na temat tego, co się zepsuło i dlaczego. decyduje o zmianach i zarządza zespołem technicznym. Współpracuje blisko z kierownikiem ds. zdarzenia.

• Kierownik ds. komunikacji, osoba posiadająca wiedzę na temat komunikacji publicznych; może być pracownikiem działu obsługi klienta lub PR. Odpowiedzialna za opracowywanie i wysyłanie wewnętrznej i zewnętrznej komunikacji na temat zdarzenia.

Temat pokoju zawiera informacje na temat tego, kto aktualnie pełni jaką rolę. Jeśli role się zmieniają podczas zdarzenia, dane są aktualizowane.

Kierownik ds. zdarzenia może też obmyślać i przydzielać role, jeśli wymaga tego zdarzenie, na przykład kilku liderów technicznych, jeśli realizowany jest więcej niż jeden strumień zadań, lub oddzielnych kierowników ds. komunikacji z klientami wewnętrznymi i zewnętrznymi.

W przypadku skomplikowanych lub rozległych incydentów zaleca się zaangażowanie dodatkowego wykwalifikowanego menedżera ds. incydentu, który będzie pełnił funkcję kontrolną wobec głównego menedżera. Może on skupić się na konkretnych zadaniach, które odciążą menedżera ds. incydentu, takich jak prowadzenie osi czasu.

Wyślij komentarze podsumowujące

Zostały już wysłane początkowe wiadomości, ale gdy zespół ds. incydentu rozpocznie działania, należy na bieżąco informować pracowników i klientów o przebiegu incydentu.

Informowanie pracowników wewnętrznych jest istotne, ponieważ zapewnia dostęp do spójnej i prawdziwej wiedzy na temat incydentu. Gdy coś dzieje się nie tak, informacje na temat incydentu są skąpe, szczególnie na początkowych etapach. Jeśli nie wskaże się wiarygodnego źródła informacji na temat incydentu oraz podejmowanych w związku z nim działań, pracownicy zaczną wyciągać własne wnioski. 

W przypadku komunikacji wewnętrznej postępujemy zgodnie z poniższym schematem:

• Komunikujemy się za pośrednictwem wewnętrznego narzędzia Statuspage i poczty e-mail, jak opisano w sekcji „Komunikacja początkowa” powyżej.

• Zastosuj tę samą konwencję do formatowania nazwy incydentu i tematu wiadomości e-mail (

• Zacznij od podsumowania stanu zdarzenia i jego skutków w 1-2 zdaniach.

• Sekcja „Bieżący status” powinna zawierać 2-4 punkty.

• Sekcja „Kolejne kroki” powinna zawierać 2-4 punkty.

• Napisz, gdzie i kiedy zostaną przesłane kolejne komunikaty.

Poniższa lista kontrolna służy nam do oceny kompletności komunikacji: 

• Jakie są faktyczne skutki dla klientów?

• Ilu klientów wewnątrz i na zewnątrz przedsiębiorstwa dotyczy zdarzenie?

• Jeśli główna przyczyna jest znana, co to jest?

• Czy znany jest szacowany czas przyjazdu w celu przywrócenia usługi, ile on wynosi?

• Kiedy i gdzie zostanie przeprowadzona kolejna aktualizacja?

Zachęcamy kierowników ds. zdarzeń do wyraźnego komunikowania niewiadomych wewnątrz przedsiębiorstwa. Pomaga to zredukować niepewność. Na przykład, jeśli nie znasz jeszcze głównej przyczyny, znacznie lepiej jest powiedzieć „główna przyczyna jest jeszcze nieznana” niż nie powiedzieć nic na ten temat.

Informowanie zewnętrznych klientów jest ważne, ponieważ pomaga budować zaufanie. Choć incydent może ich dotyczyć, będą mogli zająć się innymi sprawami pod warunkiem, że będą informowani na bieżąco.

W przypadku komunikacji zewnętrznej po prostu aktualizujemy incydent, który wcześniej został utworzony na zewnętrznej stronie Statuspage, zmieniając jego status w zależności od sytuacji. Staramy się, aby komunikaty były „krótkie i konkretne”, ponieważ klienci zewnętrzni nie są zainteresowani technicznymi szczegółami incydentu. Chcą jedynie wiedzieć, czy został już rozwiązany, a jeśli nie, to kiedy to nastąpi. Zazwyczaj wystarczą 1–2 zdania.

Przekazywanie informacji to sztuka, która wymaga praktyki. Podczas naszego szkolenia dla kierowników ds. zdarzeń przedstawiamy hipotetyczne zdarzenie, opracowujemy szkic komunikacji z nim związanej i odczytujemy ją pozostałym uczestnikom. Jest to dobry sposób na wyćwiczenie tej umiejętności przed podjęciem faktycznych działań. Zawsze warto również poprosić inną osobę o sprawdzenie tekstu, aby uzyskać drugą opinię przed jego wysłaniem.

Przeglądaj kod

Nie ma jednego, narzuconego procesu, który umożliwia rozwiązanie wszystkich incydentów. Gdyby był, po prostu byśmy go zautomatyzowali i mieli to z głowy. Zamiast tego przeprowadzamy iteracje następującego procesu, aby szybko dostosować się do różnych scenariuszy reagowania na incydenty: 

• Zaobserwować, co się dzieje. Podzielić się informacjami i potwierdzić je.

• Opracować teorie dotyczące przyczyn. 

• Opracować eksperymenty potwierdzające lub obalające te teorie. Przeprowadzić je.

• Powtórzyć.

Na przykład można zaobserwować wysoki współczynnik błędów w usłudze związanej z usterką, o której informację zamieścił w narzędziu Statuspage regionalny dostawca infrastruktury. Można teoretyzować, że usterka występuje wyłącznie w tym regionie, przełączyć się do innego regionu i zaobserwować rezultaty.

Największe wyzwania dla kierownika ds. zdarzenia w tym momencie dotyczą dyscypliny zespołu.

• Czy zespół komunikuje się efektywnie?

• Jakie są aktualne obserwacje, teorie i strumienie zadań?

• Czy podejmujemy efektywne decyzje?

• Czy wprowadzamy zmiany celowo i ostrożnie? Czy wiemy, jakie zmiany wprowadzamy? 

• Czy role są jasno określone? Czy ludzie wykonują swoje obowiązki? Czy konieczna jest eskalacja do większej liczby zespołów?

Niezależnie od sytuacji nie panikuj — to nie pomaga. Zachowaj spokój, a reszta zespołu pójdzie za Twoim przykładem.

Kierownik ds. zdarzenia musi zwracać uwagę na zmęczenie zespołu i planować jego przekazanie. Wyznaczony zespół może ryzykować wypalenie podczas rozwiązywania złożonych zdarzeń — kierownik ds. zdarzeń powinien pilnować, jak długo członkowie zespołu nie śpią i od jak dawna zajmują się zdarzeniem, a następnie zdecydować, kto przejmie ich role.

Rozwiąż

Zdarzenie uznaje się za rozwiązane, gdy bieżący lub bliski skutek biznesowy dobiegł końca. W tym momencie kończy się reagowanie kryzysowe, a zespół zajmuje się czyszczeniem i analizą.

Zadania obejmujące czyszczenie można łatwo podlinkować i śledzić jako łącza do zgłoszeń od zgłoszenia zdarzenia w systemie JIra.

W firmie Atlassian korzystamy z niestandardowych pól w systemie Jira w celu śledzenia godziny rozpoczęcia skutków, wykrycia i zakończenia skutków każdego zdarzenia. Pola te służą nam do obliczania czasu przywracania działania, czyli czasu, jaki upłynął pomiędzy rozpoczęciem i zakończeniem zdarzenia i czasu potrzebnego na wykrycie, czyli od rozpoczęcia zdarzenia do wykrycia. Rozkład czasu przywracania działania i czasu potrzebnego na wykrycie to często ważny wskaźnik biznesowy.

Po rozwiązaniu zdarzenia wysyłamy końcowe raporty do klientów wewnętrznych i zewnętrznych. Komunikacja wewnętrzna zawiera podsumowanie skutków zdarzenia, w tym liczbę rozpoczętych procedur świadczenia wsparcia i inne ważne parametry zdarzenia, jak również wyraźne powiadomienie o rozwiązaniu zdarzenia i zakończeniu wysyłania komunikatów w tej kwestii. Komunikacja z podmiotami zewnętrznymi jest zazwyczaj krótka. Klienci są informowani o tym, że usługa została przywrócona i zostanie przeprowadzona analiza.

Aby dowiedzieć się, w jaki sposób Jira Service Management pomaga zespołom realizować każdy etap procesu reagowania — od scentralizowania alertów i organizowania informowania o incydentach przez ujednolicenie zespołów w celu lepszej współpracy po przeprowadzanie analiz post-mortem incydentów w celu analizy głównych przyczyn — użyj poniższego przycisku. 

Uzyskaj podręcznik w formie drukowanej lub jako plik PDF

Udostępniamy limitowaną pulę drukowanych wersji naszego podręcznika zarządzania incydentami, który wysyłamy za darmo. Możesz również pobrać wersję PDF.

Pobierz podręcznik