Reagowanie na zdarzenia

W poniższych sekcjach opisano proces reagowania na zdarzenia w przedsiębiorstwie Atlassian. Kierownik ds. zdarzeń realizuje serię działań w celu doprowadzenia do usunięcia wykrytego zdarzenia.

Wykrywanie

Pracownicy Twojej firmy mogą dowiedzieć się o incydentach na wiele sposobów. Mogą zostać powiadomieni przez system monitorowania, za pośrednictwem zgłoszeń klientów, albo sami je zaobserwować. Niezależnie od tego, jak dojdzie do incydentu, pierwszym krokiem, który musi wykonać zespół, jest zarejestrowanie zgłoszenia incydentu (w naszym przypadku zgłoszenia Jira). 

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 są już podejmowane działania w związku z incydentem, spoglądając na pulpit Jira lub makro Jira w Confluence. Zespoły, np. nasz zespół obsługi 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 żądają rozpoczęcia procedur świadczenia wsparcia odnośnie do zdarzenia, które ich dotyczy. Gdy nasz zespół ds. obsługi klientów ustali, że wszystkie te przypadki dotyczą zdarzenia, nadają im etykietę wraz z identyfikatorem zgłoszenia zdarzenia, aby śledzić jego skutki dla klientów i ułatwić sobie wyszukiwanie klientów po rozwiązaniu zdarzenia, które ich dotyczy.

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ę zarządzający incydentami, gdy będzie online, jest przypisanie sobie zgłoszenia incydentu i zmianę jego stanu na Naprawianie. Pole osoby przypisanej do zgłoszenia w systemie Jira również zawiera imię nazwisko aktualnego zarządzającego incydentami. W sytuacji reagowania awaryjnego bardzo ważne jest, aby wiedzieć, kto odpowiada za proces, dlatego surowo przestrzegamy obowiązku podania prawidłowych informacji w tym polu. 

Następnie kierownik konfiguruje kanały komunikacji dla zespołu ds. zdarzenia. Na tym etapie celem jest rozpoczęcie komunikacji całego zespołu ds. zdarzenia i zwrócenie na nią uwagi w dobrze znanych miejscach. Zazwyczaj korzystamy z trzech metod komunikacji, a każdej z nich odpowiada pole w zgłoszeniu w systemie Jira, oddzielnie dla każdego zdarzenia:

• 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.

Przekonaliśmy się, że korzystanie z czatu wideo i pokoju funkcjonuje najlepiej podczas zdarzenia, ponieważ oba te rozwiązania sprawdzają się w różnych sytuacjach. Czat wideo jest doskonały do szybkiego tworzenia wspólnego wyobrażenia o zdarzeniu po przeprowadzeniu grupowej dyskusji, podczas gdy czat tekstowy można wykorzystać w celu dokumentowania zdarzenia przy użyciu znaczników czasowych, współdzielonych linków do pulpitów nawigacyjnych, zrzutów ekranowych 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.

Pozwala to dowolnej osobie posiadającej identyfikator zgłoszenia zdarzenia dołączyć do chatu i uzyskać najnowsze informacje na temat zdarzenia (Należy pamiętać, że nazwa kanału czatu zawiera identyfikator zgłoszenia zdarzenia, 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, żeby zacząć dodawać elementy do osi czasu zdarzenia. Rejestruj obserwacje zespołu, żeby ludzie do niego dołączający mogli uzyskać przydatne informacje. Będzie to również istotne w procesie przygotowywania analizy. Pamiętaj, aby zanotować, czy czas rozpoczęcia zdarzenia odpowiada zmianie (np. wdrożeniu narzędzia Bamboo), aby można było cofnąć zmianę, dążąc do rozwiązania zdarzenia.

Na podstawie skutków incydentu i ilości pracy koniecznej według naszych zespołów do rozwiązania incydentu, przypisujemy zgłoszeniu jeden z następujących poziomów ważnoś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.

Wykres poziomu ważności należy udokumentować i uzyskać akceptację wszystkich zespołów, aby zapewnić spójność reagowania na zdarzenia 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 zawsze dołączamy identyfikator zgłoszenia w systemie Jira do wszystkich wiadomości dotyczących zdarzenia wysyłanych wewnątrz przedsiębiorstwa, dlatego personel wie, do którego pokoju należy zajrzeć, aby uzyskać więcej informacji.

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 złożonych zdarzeń lub takich, które mają duży zasięg, warto wezwać drugiego wykwalifikowanego kierownika ds. zdarzeń w celu kontroli prawidłowości działań. Może on skupić się na konkretnych działaniach, odciążając głównego kierownika, np. pilnowania realizacji osi czasu.

Wyślij komentarze podsumowujące

Zostały już wysłane początkowe wiadomości, jednak po rozpoczęciu pracy przez zespół zajmujący się zdarzeniem należy poinformować personel i klientów o postępie działań.

Informowanie na bieżąco 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 z 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 o postępach jest ważne, ponieważ przyczynia się do budowania zaufania. Choć zdarzenie może ich dotyczyć, będą mogli zająć się innymi sprawami pod warunkiem, że będą informowani na bieżąco.

W przypadku komunikacji z klientami zewnętrznymi , po prostu aktualizujemy zdarzenie otwarte wcześniej w zewnętrznym narzędziu Statuspage, odpowiednio dostosowując jego status. Staramy się, aby aktualizacje były krótkie i zwięzłe, ponieważ klienci zewnętrzni nie są zainteresowani szczegółami technicznymi zdarzenia — chcą po prostu wiedzieć, czy problem został rozwiązany, a jeśli nie, kiedy to nastąpi. W zasadzie wystarczy 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?

Nieważne, co się dzieje, nie panikuj — to nie pomaga. Zachowaj spokój, a reszta zespołu będzie postępować według Twoich wskazówek.

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