Gestione degli imprevisti per i team high velocity
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.
Gestione degli imprevisti per i team high velocity
Accelera il flusso di informazioni tra i team operativi e di sviluppo per fornire una risposta adeguata ed eseguire il ripristino dei sistemi in caso di imprevisti con 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 |
|
| 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?
A prima vista, la gravità di un imprevisto sembra equivalere alla sua priorità. Dopotutto, un imprevisto grave con conseguenze disastrose dovrebbe essere affrontato prima di un imprevisto meno grave, giusto?
Ma la verità è che per la maggior parte delle aziende non è così semplice.
La gravità è un indice dell'impatto. Qual è l'impatto di un imprevisto sugli utenti? Mette a repentaglio l'intero sistema? Impedisce di completare un'attività fondamentale? O semplicemente infastidisce gli utenti e rende più complesse le attività?
La priorità, invece, è un indice dell'urgenza. Con quale urgenza dobbiamo risolvere questo problema? Quale problema deve essere risolto per primo?
A volte, gravità e priorità sono perfettamente allineate. Un imprevisto di elevata gravità che colpisce l'intera azienda è probabilmente la massima priorità su cui devono concentrarsi i team DevOps e IT.
Altre volte, invece, non sono allineate. Ad esempio: supponiamo che ci sia un errore di battitura nel titolo della home page del tuo sito Web. Si tratta di un problema di bassa gravità perché in realtà non influisce sul funzionamento del sito Web, gli utenti possono comunque continuare le loro attività e i dipendenti hanno comunque a disposizione tutto ciò di cui hanno bisogno.
Ma l'azienda potrebbe vedere la correzione come priorità assoluta per motivi di standard del marchio o perché causa confusione o semplicemente perché ne compromette l'immagine. Quindi questo imprevisto potrebbe essere di bassa gravità e di alta priorità.
Allo stesso modo, supponiamo che si sia verificato un imprevisto che sta causando l'arresto anomalo della tua app: è di gravità elevata perché impedisce agli utenti di portare avanti le loro attività, ma è anche vero che sta interessando solo lo 0,05% degli utenti. In presenza di altri imprevisti con un impatto maggiore, un problema come questo potrebbe non essere della massima priorità, anche se generalmente frasi come "il sistema si sta bloccando" mettono tutti in allerta.
Entrambi gli indici, priorità e gravità, sono importanti nella gestione degli imprevisti, ma è fondamentale riconoscere quando sono allineati e quando non lo sono. Una gravità elevata non si traduce automaticamente in una priorità assoluta, così come un'alta priorità non equivale a un danno irreparabile.
Poiché la priorità è più perseguibile della gravità, è l'indice principale che utilizziamo. E poiché la gravità è spesso un fattore chiave che determina la priorità, nel nostro manuale degli imprevisti abbiamo fornito definizioni chiare per la nostra prassi di gestione degli imprevisti.
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. | ||
È essenziale disporre di una soluzione di gestione degli imprevisti per l'escalation degli stessi, in modo che i team di competenza possano immediatamente scremarli e avviarne la risoluzione.
Scopri come tutte le funzionalità di gestione degli imprevisti di Jira Service Management, tra cui avvisi e pianificazione su chiamata, comunicazione collaborativa e solide funzionalità di reporting e analisi, consentono ai team di rispondere, risolvere e imparare dagli imprevisti.
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 tutorialModelli ed esempi di comunicazione degli imprevisti
Quando si risponde a un imprevisto, i modelli di comunicazione hanno un valore inestimabile. Scopri i modelli utilizzati dai nostri team e altri esempi di imprevisti comuni.
Read this article