Close

Droga do lepszego zarządzania incydentami zaczyna się tutaj

Understanding incident severity levels

Identify and prioritize incidents for faster resolution

There are three cardinal truths of incident management.

The first is that incidents are inevitable—especially for companies that are constantly growing and innovating.

The second is that a strong incident management practice is vital to a healthy business (and a weak one costs businesses big in both employee time and satisfaction and business revenues).

The third is that not all incidents are created equal. Losing data from one database is not the same as losing data from all of your databases. Dealing with an outage that impacts 20% of your users is a whole different ballpark than dealing with an outage that impacts 90 or 100%. Handling a system outage during peak hours is a lot more stressful than handling one when most of your customers are asleep. Even two incidents that look identical on paper are unique under the surface.

Logo JSM

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.

This is why companies with robust incident management programs have well-defined incident severity levels and clear best practices for prioritizing incidents as they arise.

What are severity levels?

Incident severity levels are a measurement of the impact an incident has on the business. Typically, the lower the severity number, the more impactful the incident.

For example: At Atlassian, we define a SEV (severity) 1 incident as “a critical incident with very high impact.” This could include a customer data loss, a security breach, or when a client-facing service is down for all customers.

A SEV 2 incident is a “major incident with significant impact,” including when a client-facing service is down for a sub-set of customers or a critical function within a system is not functioning.

And a SEV 3 incident is “a minor incident with low impact,” such as a system glitch that is causing customers slight inconvenience.

At Atlassian, SEV 3 incidents can be handled during daytime/working hours, while SEV 1 and SEV 2 incidents generate an alert for on-call professionals for an immediate fix no matter the time of day.

Severity Description Examples
1 A critical incident with very high impact
  • A customer-facing service, like Jira Cloud, is down for all customers
  • Confidentiality or privacy is breached
  • Customer data loss
2 A major incident with significant impact
  • A customer-facing service is unavailable for a subset of customers
  • Core functionality (e.g. git push, issue create) is significantly impacted
3 A minor incident with low impact
  • A minor inconvenience to customers, workaround available
  • Usable performance degradation

Severity levels are useful for understanding impact quickly and setting priorities for the IT and DevOps teams.

The more well-defined your SEV levels are, the more likely it is that your team will be on the same page and able to react quickly and appropriately when incidents happen. Without well-defined severity levels, it’s easy to waste vital time defining and explaining an incident’s urgency instead of resolving it.

When and where are severity levels useful?

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.

How is severity different from priority?

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.

Defining incident severity levels for your organization

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.

Atlassian 3-tier 4-tier 5-tier
SEV 1

A critical incident with very high impact.

For example: A customer-facing service like Jira is down for all customers.

SEV 2

A major incident with significant impact.

For example: A customer-facing service is down for a sub-set of customers.

SEV 3 A minor incident with low impact.

For example: A system bug is creating a minor inconvenience to customers.

An incident with the potential to become a major incident if not quickly addressed.

For example: A partial loss of functionality for a small sub-set of customers.

SEV 4 A support request that’s irritating a customer but does not impact overall system function.

A minor incident that impact product usability but don’t bring it to a halt.

For example: Slower-than-average load times.

SEV 5

Bugs or support issues that don’t impact product usability.

For example: A logo is showing in the wrong place or partially obscuring the last letter in a headline.

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.