Understanding incident severity levels

The core value of SEV levels is that they save teams time. A team with severity levels and a clear roadmap for addressing each level is a team that can dive straight into a fix. A team without severity levels is likely to spend the first crucial minutes of a major incident figuring out how important it is, who should handle it, and how to handle it.

The more critical the incident, the more important it is to save as much time as possible by planning ahead not only with incident resolution and communication plans, but also clear SEV levels and priorities.

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.

Not all incidents are created equal and not all organizations handle them the same way. When setting severity levels and the processes and expectations around them, in addition to the impact of an incident, you’ll need to factor in:

• The size of your tech team
• On-call schedules
• High- and low-traffic times of day for your service
• The frequency of incidents

Why? Because each of these things might impact how you define SEV levels.

For example, an app that services local markets in a single time zone might have a big gap in use between 2 a.m. and 7 a.m. So, if your whole system goes down at 3 a.m., is it the same SEV level as a system outage during peak hours?

Or what about a startup with a small team and a lot of what we might consider SEV 3 incidents? Should they stick with a SEV 3 label and let the team work out which incidents take priority when three happen at once? Or should they split them out further into SEV 3, 4, or even 5 to distinguish between a partial loss of functionality in a customer-facing system, performance issues, and something even more minor, like a bug that doesn’t impact the usability of the system but does eventually need to be fixed?

The vital thing here is understanding your business, your team, and what kind of SEV-level and priority-level definitions work for you.

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.