Najlepsze praktyki i porady dotyczące reagowania na incydenty

1. Zawsze przygotowuj niezbędnik

„Niezbędnik” dla osób reagujących na incydenty zawiera wszystkie krytyczne informacje, do których zespół musi uzyskać dostęp w jak najkrótszym czasie. Choć najprawdopodobniej przybierze on formę dokumentu cyfrowego, dużą pomocą jest udostępnienie osobom reagującym na incydent jednego scentralizowanego punktu wyjścia.

W takim miejscu można umieścić różne pomoce:

• Plany reagowania na incydenty
• Listy kontaktów
• Harmonogramy dyżurów
• Zasady eskalacji
• Łącza do narzędzi konferencyjnych
• Kody dostępu
• Dokumenty z zasadami
• Dokumentacja techniczna i wykazy procedur

2. Nie stroń od wykazów procedur

Wykazy procedur zawierają opis kroków, jakie należy podjąć w konkretnej sytuacji. Są one szczególnie istotne w przypadku zespołów pełniących rotacyjnie dyżury domowe, w których natychmiastowy dostęp do specjalisty w zakresie systemu może być niemożliwy. Dobrze prowadzony zbiór wykazów procedur pozwala zespołom szybciej reagować i tworzyć wspólną bazę wiedzy na temat praktyk dotyczących reagowania na incydenty.

3. Unikaj chaosu, dbaj o stabilność

Inżynieria chaosu to praktyka polegająca na eksperymentowaniu z systemami poprzez celowe wywoływanie awarii, aby poznać możliwości budowania lepszych systemów. Przykładem takiego rozwiązania jest Chaos Monkey. Narzędzie Chaos Monkey opracowane początkowo przez zespół serwisu Netflix testuje odporność sieci przez celowe wymuszanie przejścia systemów produkcyjnych w tryb offline.

4. Wybiegaj myślą poza centra operacji sieciowych

Dawniej centra operacji sieciowych (NOC) pełniły funkcję centrów monitorowania i obsługi alertów dla systemów IT działających na dużą skalę. Nowoczesne narzędzia do zarządzania incydentami pozwalają w znacznym stopniu usprawnić ten proces. Dzięki automatyzacji przepływów pracy związanych z dostarczaniem alertów w oparciu o zdefiniowane rodzaje alertów, harmonogramy zespołów i zasady eskalacji, można wyeliminować ryzyko wystąpienia błędu ludzkiego i/lub opóźnień.

5. Jednocz zamiast dzielić

Nie ma nic gorszego niż ciągły strumień alertów napływających z wielu narzędzi do monitorowania. Scentralizowanie przepływu alertów przy użyciu jednego narzędzia pozwala zespołom lepiej filtrować fałszywe alarmy, aby móc szybko skoncentrować się na tym, co naprawdę wymaga uwagi.

6. Pamiętaj: wiedza to potęga

Alert podstawowy informuje o wystąpieniu problemu, ale nie zawsze wskazuje, na czym ten problem polega. Prowadzi to do niepotrzebnych opóźnień, ponieważ zespoły muszą sprawdzić i ustalić jego przyczynę. Połączenie alertów ze szczegółami technicznymi, które doprowadziły do ich wyzwolenia pozwala przyspieszyć rozpoczęcie procesu naprawy.

7. Ustaw alerty dla swoich alertów

Łacińskie powiedzenie „quis custodiet ipsos custodes” (kto pilnuje strażników?) jest wyrazem uniwersalnego problemu. Narzędzia do monitorowania stosowane przez zespołu programistyczne i IT są równie podatne na incydenty i przestoje, jak systemy, do ochrony których zostały przeznaczone. Całościowe podejście do procesów obsługi alertów pozwala zapewnić ciągłą kontrolę stanu obydwu systemów oraz narzędzi przeznaczonych do ich monitorowania.

8. Zatrzymaj krwotok

Lekarz na izbie przyjęć wie, że jeśli skoncentruje się na próbie rozwiązania każdego przywiezionego przypadku, może spowodować większą szkodę. Dlatego skupia się na podjęciu szybkich czynności, które pozwolą ustabilizować pacjenta na tyle, aby można było przewieźć go na oddział. W branży technologicznej działania ograniczające skutki koncentrują się na wdrożeniu rozwiązań tymczasowych (odcięciu sieci, przejściu na starszą kompilację, ponownym uruchomieniu serwerów itp.), które pozwolą przynajmniej ograniczyć zakres incydentu, a najlepiej — przywrócić działanie systemów.

9. Nie działaj w pojedynkę

Kultura bohaterstwa w zespołach IT i DevOps już zamiera. Samotny inżynier pracujący w każdy wieczór i weekend jako jedyna osoba, która jest w stanie przywrócić działanie systemów, wyszedł już z mody. Zamiast tego, zespoły pracują tak, jak powinny — zespołowo. O wytrzymałości łańcucha decyduje jego najsłabsze ogniwo, dlatego ważna jest praca nad całym zespołem, a nie tylko jedną jego gwiazdą.

10. Zachowaj przejrzystość

Jeśli użytkownicy napotykają problemy w korzystaniu z usługi, często wiadomość o incydencie zostaje szybko upubliczniona. Aby uprzedzić taki przebieg sytuacji, zespoły powinny mieć opracowany plan komunikacji na wypadek incydentu. Celem jest budowanie zaufania wśród klientów przez publiczne potwierdzenie występowania problemu i zapewnienie ich, że trwają działania zmierzające do jego rozwiązania. Takie narzędzia jak Statuspage są doskonałym sposobem na rozpowszechnianie tych informacji.

11. Ucz się na błędach

Zdecydowana większość zespołów IT i DevOps stwierdzi, że mają czas na przyglądanie się wyłącznie „poważnym awariom”. Choć jest to dobry początek, w ten sposób łatwo jest przeoczyć mniejsze incydenty, które mogą przynosić długotrwałe skutki. Nie każdy incydent będzie wymagał długiego raportu, ale analiza post-mortem zawsze się przyda.

12. Znajdź główną przyczynę (nie ma głównej przyczyny!)

A może jest? Podczas analizy incydentu rzadko można wskazać jedną konkretną „główną” przyczynę. Często systemy są zbyt złożone i niezależne, aby można było wychwycić jedną główną przyczynę incydentu. Nawet jeśli główna przyczyna wydaje się oczywista (na przykład błąd polegający na przypadkowym naciśnięciu klawisza powodujący awarię systemu), zazwyczaj uzasadnione jest rozpoznania czynników zewnętrznych, które mogły sprzyjać wystąpieniu awarii (lub jej nie zapobiegły). Aby lepiej zrozumieć incydenty, należy szukać wielu głównych przyczyn.

13. Nie szukaj winnych

Celem każdej analizy post-mortem incydentu powinno być zrozumienie, co poszło nie tak i co można zrobić, aby uniknąć podobnych incydentów w przyszłości. Ważne, aby proces ten nie przerodził się w szukanie winnych. W zespołach, które koncentrują się na tym, „kto”, a nie „co”, emocje często uniemożliwiają rzetelną analizę pozwalającą zrozumieć, co właściwie się stało.

Jeszcze jedna rzecz

W nowoczesnych środowiskach zarządzania incydentami, jedyną stałą jest zmiana. Oznacza to, że systemy będą stale poddawane obciążeniom na nowe i różne sposoby. Zespoły, które to rozumieją, zdają sobie również sprawę, że awaria systemów nieuchronnie kiedyś nastąpi. Podejmowanie kroków w celu przygotowania się na takie awarie należy uznać za krytyczny element dążeń do sukcesu i nieodłączną część pracy zespołów technicznych.

Rozwiązanie do zarządzania incydentami, takie jak Jira Service Management, pomoże w realizacji każdego z tych 13 punktów — od zorganizowania harmonogramu dyżurów domowych i opracowania alertów po zjednoczenie zespołów w celu usprawnienia współpracy. do przeprowadzania analiz post-mortem.