Zarządzanie incydentami dla dynamicznych zespołów
Zrozumienie poziomów ważności incydentów
Identyfikowanie incydentów i ustalanie ich priorytetów w celu szybszego rozwiązania
Istnieją trzy podstawowe prawdy dotyczące zarządzania incydentami.
Po pierwsze, incydenty są nieuniknione— szczególnie w przypadku firm, które stale się rozwijają i wprowadzają innowacje.
Po drugie, solidna praktyka zarządzania incydentami ma kluczowe znaczenie dla właściwego prowadzenia działalności (a źle opracowana praktyka wiąże się dla firmy z poważnymi kosztami, zarówno w kontekście czasu i zadowolenia pracowników, jak i przychodów).
Po trzecie, nie wszystkie incydenty są sobie równe. Utrata danych z jednej bazy danych to nie to samo, co utrata danych ze wszystkich baz danych. Usuwanie awarii, która wpływa na 20% użytkowników, to coś zupełnie innego niż walka z awarią, która dotyka 90%, a nawet 100% użytkowników. Usuwanie awarii w godzinach szczytu jest o wiele bardziej stresujące niż zajmowanie się nią, gdy większość klientów śpi. Nawet dwa incydenty, które na papierze wyglądają identycznie, są unikatowe, jeśli zagłębić się w ich szczegóły.
Zarządzanie incydentami dla dynamicznych zespołów
Przyspiesz przepływ informacji między zespołami operacyjnymi i programistycznymi, aby reagować i przywracać systemy w przypadku wystąpienia incydentów dzięki Jira Service Management.
Dlatego firmy ze skutecznymi programami zarządzania incydentami mają dobrze zdefiniowane poziomy ważności incydentów i przejrzyste najlepsze praktyki dotyczące ustalania priorytetów incydentów w miarę, jak się pojawiają.
Czym są poziomy ważności?
Poziomy ważności incydentów są miarą wpływu incydentu na działalność firmy. Zazwyczaj im niższa liczba używana do oznaczania poziomu ważności, tym większy jest wpływ incydentu.
Przykładowo w Atlassian definiujemy incydent o poziomie ważności (SEV) 1 jako „incydent krytyczny o bardzo dużym wpływie”. Takim incydentem może być utrata danych klientów, naruszenie zabezpieczeń lub całkowita niedostępność usługi zorientowanej na klienta u wszystkich klientów.
Incydentem o poziomie ważności 2 jest „poważny incydent o znacznym wpływie”, na przykład niedostępność usługi zorientowanej na klienta u części z nich lub awaria krytycznej funkcji w systemie.
Z kolei poziom ważności 3 zarezerwowano dla „drobnych incydentów o niewielkim wpływie”, takich jak usterka w systemie powodująca dla klientów małą niedogodność.
W Atlassian incydentami poziomu 3 można zajmować się w godzinach dziennych lub godzinach pracy, natomiast wystąpienie incydentu o poziomie ważności 1 lub 2 powoduje wygenerowanie alertu wysyłanego do osób pełniących dyżur domowy, aby zajęły się usunięciem błędu bez względu na porę dnia czy nocy.
| Ważność | Opis | Przykłady |
|---|---|---|
| 1 | Zdarzenie krytyczne o bardzo poważnych skutkach |
|
| 2 | Ważne zdarzenie o znaczących skutkach |
|
| 3 | Mało istotne zdarzenie o niewielkich skutkach |
|
Poziomy ważności są przydatnym sposobem szybkiego zrozumienia wpływu i ustalenia priorytetów dla zespołów DevOps i IT.
Im lepiej zdefiniowane poziomy ważności, tym większe prawdopodobieństwo, że zespół będzie na bieżąco i będzie w stanie szybko i we właściwy sposób zareagować na incydenty, gdy do nich dojdzie. Brak dobrze zdefiniowanych poziomów ważności grozi marnowaniem cennego czasu na definiowanie i objaśnianie, jak pilny jest incydent, zamiast przystąpienia do jego rozwiązywania.
Kiedy i gdzie można wykorzystać poziomy ważności?
Podstawową zaletą poziomów ważności jest to, że oszczędzają czas zespołów. Zespół mający określone poziomy ważności i precyzyjne wytyczne dotyczące postępowania z incydentami na poszczególnych poziomach może od razu przystąpić do naprawy. Zespół bez zdefiniowanych poziomów ważności prawdopodobnie będzie musiał poświęcić pierwsze cenne minuty poważnego incydentu na ustalenie, na ile ważny jest ten incydent, kto powinien się nim zająć oraz jak należy się nim zająć.
Im bardziej krytyczny jest incydent, tym ważniejsza jest maksymalna oszczędność czasu poprzez opracowanie z wyprzedzeniem nie tylko sposobów rozwiązywania incydentów oraz planów komunikacji, ale także przejrzystych poziomów ważności i priorytetów.
Czym różni się ważność od priorytetu?
Na pierwszy rzut oka ważność incydentu wydaje się być tym samym co priorytet incydentu. Każdy przecież przyzna, że poważny incydent o tragicznych konsekwencjach powinien zostać obsłużony przed tym mniej poważnym.
Jednak w praktyce w większości firm sytuacja jest bardziej skomplikowana.
Ważność jest miarą wpływu. Jak incydent wpływa na użytkowników? Czy to paraliżuje cały ich system? Uniemożliwia im wykonanie ważnego zadania? A może po prostu ich drażni i utrudnia wykonanie zadań?
Z drugiej strony priorytet jest miarą pilności. Jak szybko musimy rozwiązać ten problem? Który problem należy rozwiązać najpierw?
Czasami te dwie miary dokładnie się pokrywają. Incydent o dużej ważności, który paraliżuje całą firmę, prawdopodobnie ma również najwyższy priorytet dla zespołów DevOps i IT.
Jednak niekiedy priorytet i ważność nie są tożsame. Na przykład: załóżmy, że w nagłówku na stronie głównej witryny znajduje się literówka. Jest to problem o małym poziomie ważności, ponieważ w rzeczywistości nie wpływa na działanie witryny. Użytkownicy nadal mogą w pełni korzystać ze wszystkich funkcji. Pracownicy nadal mogą wykonywać swoją pracę.
Jednak firma może uznać, że poprawka ma wysoki priorytet ze względu na standardy marki lub dlatego, że powoduje zamieszanie lub po prostu dlatego, że negatywnie wpływa na wizerunek. Właśnie taki incydent może mieć niską ważność, ale wysoki priorytet.
Podobnie jest np. w przypadku incydentu, który powoduje awarię aplikacji. Ma on wysoką ważność, ponieważ uniemożliwia użytkownikom korzystanie z potrzebnych funkcji. Dodajmy, że incydent dotyczy zaledwie 0,05% użytkowników. Jeśli istnieją inne incydenty o szerszym wpływie, problem tego typu może nie mieć najwyższego priorytetu, mimo że zazwyczaj hasło „awaria systemu” oznaczałyby pełną mobilizację.
Obie miary są istotne w zarządzaniu incydentami, ale trzeba umieć rozpoznać, jak ich wagi mają się do siebie. Wysoka ważność nie powoduje automatycznie przesunięcia czegoś na szczyt listy priorytetów, a wysoki priorytet nie zawsze oznacza, że system nie działa.
Ponieważ priorytet wymaga działania w większym stopniu niż ważność, jest on podstawową miarą, której używamy. Ponieważ ważność jest często kluczowym czynnikiem decydującym o priorytecie, w naszym podręczniku incydentów ustaliliśmy jasne definicje na potrzeby naszej własnej praktyki zarządzania incydentami.
Definiowanie poziomów ważności incydentów w organizacji
Nie wszystkie incydenty są jednakowe i nie wszystkie organizacje zajmują się nimi w taki sam sposób. Podczas ustalania poziomów ważności oraz procesów i oczekiwań z nimi związanych należy wziąć pod uwagę nie tylko wpływ incydentu, ale również następujące czynniki:
- Wielkość zespołu technicznego
- Harmonogramy dyżurów
- Godziny małego i dużego natężenia ruchu w usłudze w ciągu dnia
- Częstotliwość incydentów
Dlaczego? Ponieważ każda z tych rzeczy może wpłynąć na sposób definiowania poziomów ważności.
Przykładowo aplikacja, która obsługuje rynki lokalne w pojedynczej strefie czasowej, może notować duży spadek liczby użytkowników w godzinach od 02:00 do 07:00. Jeśli zatem cały system ulegnie awarii o godzinie 03:00, to czy poziom ważności incydentu będzie równie wysoki jak w godzinach szczytu?
A co w przypadku start-upu z małym zespołem, który boryka się z dużą liczbą incydentów o 3 poziomie ważności? Czy zespół powinien pozostać przy tym poziomie i samodzielnie ustalać priorytety w przypadku równoczesnego wystąpienia więcej niż jednego incydentu? A może powinien podzielić incydenty na poziomy ważności 3, 4, a nawet 5, aby wprowadzić rozróżnienie między częściową utratą funkcjonalności systemu używanego przez klientów, problemami z wydajnością, a nawet jeszcze drobniejszymi problemami, takimi jak błędy, które nie wpływają na funkcjonalność systemu, ale w końcu i tak trzeba je usunąć?
Najważniejsze jest zrozumienie funkcjonowania firmy i zespołu oraz ustalenie, który rodzaj systemu definiowania poziomów ważności i priorytetów sprawdzi się najlepiej w danym przypadku.
| 3-poziomowy (Atlassian) | 4-poziomowy | 5-poziomowy | |
|---|---|---|---|
| Ważność 1 | Incydent krytyczny o bardzo poważnych skutkach. | ||
| Ważność 2 | Poważny incydent o znaczących skutkach. | ||
| Ważność 3 | Drobny incydent o niewielkich skutkach. Przykład: błąd systemu, który powoduje małą niedogodność dla klientów. | Incydent, który może przerodzić się w poważny incydent, jeśli nie zostanie szybko rozwiązany. | |
| Ważność 4 | Wniosek o wsparcie w związku z problemem, który irytuje klienta, ale nie wpływa na ogólne funkcjonowanie systemu. | Drobny incydent, który wpływa na użyteczność produktu, ale nie powoduje przerwy w jego działaniu. | |
| Ważność 5 | Błędy lub problemy, które nie wpływają na użyteczność produktu. | ||
Zasadnicze znaczenie ma posiadanie rozwiązania do zarządzania incydentami w celu eskalacji incydentów, aby odpowiednie zespoły mogły natychmiast zebrać się i rozpocząć rozwiązywanie problemu.
Dowiedz się, w jaki sposób wszystkie funkcje zarządzania incydentami Jira Service Management, w tym obsługa alertów i harmonogram dyżurów domowych, wspólna komunikacja oraz niezawodne funkcje raportowania i analizowania, umożliwiają zespołom reagowanie na incydenty, rozstrzyganie ich i uczenie się na ich podstawie.
Poznaj proces informowania o incydentach za pomocą Statuspage
W tym samouczku pokażemy, jak wykorzystać szablony dotyczące incydentów do skutecznej komunikacji w trakcie awarii. Ich elastyczny charakter pozwala na dostosowanie ich do różnego rodzaju przerw w dostawie usług.
Przeczytaj ten samouczekSzablony i przykłady informowania o incydentach
Podczas reagowania na incydent szablony komunikatów są nieocenione. Pobierz szablony, z których korzysta nasz zespół, a także inne przykłady dotyczące częstych incydentów.
Przeczytaj ten artykuł