Incidentmanagement voor razendsnelle teams
Browse topics
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.
Incidentmanagement voor razendsnelle teams
Versnel met Jira Service Management de informatiestroom tussen operationele en ontwikkelingsteams om op incidenten te reageren wanneer ze zich voordoen en om systemen te herstellen.
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 |
|
| 2 | A major incident with significant impact |
|
| 3 | A minor incident with low impact |
|
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?
Op het eerste gezicht lijkt de ernst van het incident hetzelfde te zijn als incidentprioriteit. Een ernstig incident met ernstige gevolgen moet immers worden aangepakt vóór een minder ernstig incident, toch?
Maar de waarheid is dat het voor de meeste bedrijven ingewikkelder ligt dan dat.
Ernst is een maatstaf voor de impact. Hoeveel impact heeft een incident op gebruikers? Haalt het het hele systeem uit de lucht? Zorgt het ervoor dat ze hun hoofdtaken niet kunnen voltooien? Of is het alleen maar irritant en maakt het taken lastiger?
Prioriteit is daarentegen een meting van urgentie. Hoe snel moeten we deze issue oplossen? Welke issue moet als eerst worden opgelost?
Soms zijn de twee metingen perfect op elkaar afgestemd. Een incident met een hoge ernst waarbij het hele bedrijf wordt uitgeschakeld, heeft voor DevOps- en IT-teams waarschijnlijk ook de hoogste prioriteit.
Maar soms komen de prioriteit en de ernst niet overeen. Bijvoorbeeld: stel dat er een typefout staat in de kop op de startpagina van je website. Dit is een issue met een lage ernst omdat het niet echt van invloed is op de functie van de website. Gebruikers kunnen nog steeds doen wat ze moeten doen. Medewerkers kunnen nog steeds doen wat ze moeten doen.
Maar het bedrijf ziet de oplossing misschien als hoge prioriteit om de merkstandaarden hoog te houden, omdat het verwarring veroorzaakt of gewoon omdat ze er niet mooi uitzien. En dus kan dit incident van lage ernst en hoge prioriteit zijn.
Laten we ook zeggen dat er een incident is waardoor je app crasht. Dat is zeer ernstig omdat gebruikers niet kunnen doen wat ze moeten doen. Maar laten we ook zeggen dat het incident slechts 0,05% van je gebruikers treft. Als er andere incidenten zijn met een grotere impact, heeft een issue als dit misschien niet de hoogste prioriteit, ook al zouden de woorden 'systeem crasht' over het algemeen alle hens aan dek betekenen.
Beide metingen zijn belangrijk bij incidentmanagement, maar het is belangrijk om te herkennen wanneer ze op één lijn liggen en wanneer niet. Hoge ernst push iets niet automatisch naar de top van de prioriteitenlijst en hoge prioriteit betekent niet altijd dat een systeem uitvalt.
Omdat prioriteit uitvoerbaarder is dan ernst, is deze de primaire meting die we gebruiken. En omdat ernst vaak een sleutelfactor is die prioriteit bepaalt, hebben we duidelijke definities vastgelegd in onze Incidentgids voor onze eigen incidentmanagementwerkwijzen.
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. | ||
| SEV 2 | A major incident with significant impact. | ||
| 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. | |
| 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. | |
| SEV 5 | Bugs or support issues that don’t impact product usability. | ||
Het is essentieel om een oplossing voor incidentmanagement te hebben om incidenten te kunnen escaleren, zodat de juiste teams zich onmiddellijk op een oplossing kunnen storten.
Ontdek hoe teams met alle functies voor incidentbeheer van Jira Service Management, waaronder waarschuwingen en op-afroepplanning, samenwerkingscommunicatie en robuuste rapportage- en analysefuncties, kunnen reageren op incidenten, ze kunnen oplossen en er van kunnen leren.
Learn incident communication with Statuspage
In this tutorial, we’ll show you how to use incident templates to communicate effectively during outages. Adaptable to many types of service interruption.
Read this tutorialSjablonen en voorbeelden voor incidentcommunicatie
Bij het reageren op een incident zijn communicatiesjablonen van onschatbare waarde. Download de sjablonen die onze teams gebruiken, plus meer voorbeelden voor veelvoorkomende incidenten.
Read this article