빠른 속도의 팀을 위한 인시던트 관리
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.
빠른 속도의 팀을 위한 인시던트 관리
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?
언뜻 보기에 인시던트 심각도는 인시던트 우선 순위와 같아 보일 수 있습니다. 결국 심각한 결과를 초래하는 심각한 인시던트는 덜 심각한 인시던트보다 먼저 처리해야 하기 때문입니다.
하지만 대부분의 비즈니스에서는 이것보다 더 복잡합니다.
심각도는 영향을 측정한 것입니다. 인시던트가 사용자에게 미치는 영향은 어느 정도인지, 전체 시스템이 중단되는지, 중요한 작업을 완료하지 못하게 되는지, 또는 단순히 성가시고 작업이 더 어려워지는 정도인지에 대해 질문하면 됩니다.
반면에 우선 순위는 긴급성을 측정한 것입니다. 이 이슈를 얼마나 빨리 해결해야 하는지, 어떤 이슈를 먼저 해결해야 하는지에 대해 질문해야 합니다.
두 측정값이 완벽하게 정렬될 때도 있습니다. 회사 전체를 중단시키는 심각도가 높은 인시던트는 DevOps 및 IT 팀이 집중해야 할 우선 순위가 가장 높은 인시던트이기도 할 것입니다.
하지만 우선 순위와 심각도가 일치하지 않을 때도 있습니다. 예를 들어, 웹사이트 홈페이지의 헤드라인에 오타가 있다고 가정해 보겠습니다. 웹사이트의 기능에 실제로 영향을 미치지 않기 때문에 심각도가 낮은 이슈입니다. 사용자는 필요한 모든 작업을 계속 수행할 수 있고 직원들은 해야 하는 일을 계속 할 수 있습니다.
그러나 비즈니스는 브랜드 표준과 관련된 이유, 또는 혼란을 유발하거나 단순히 안 좋게 보인다는 이유로 이 이슈의 수정을 우선 순위가 높은 것으로 볼 수 있습니다. 따라서 이 인시던트는 심각도가 낮고 우선 순위가 높을 수 있습니다.
마찬가지로, 앱 비정상 종료의 원인이 되는 인시던트가 있다고 가정해 보겠습니다. 사용자가 해야 하는 작업을 수행하지 못하도록 만들기 때문에 심각도가 높습니다. 하지만 인시던트가 0.05%의 사용자에게만 영향을 준다고 가정해 보겠습니다. 일반적으로 시스템 충돌이 발생했다고 하면 모두가 문제를 해결해야 하는 상황이지만, 더 큰 영향을 미치는 다른 인시던트가 있는 경우 이와 같은 이슈는 가장 높은 우선 순위가 아닐 수 있습니다.
두 측정값 모두 인시던트 관리에서 중요하지만 그 둘이 정렬되는 경우와 그렇지 않은 경우를 파악해야 합니다. 심각도가 높다고 해서 자동으로 우선 순위의 목록의 맨 위에 올라가는 것이 않으며, 높은 우선 순위라고 해서 항상 시스템이 다운되었다는 것도 아닙니다.
우선 순위는 심각도보다 실행에 옮기기 쉽기 때문에, 우리가 사용하는 기본 측정값은 우선 순위입니다. 또한 심각도는 우선 순위를 결정하는 핵심 요소인 경우가 많으므로, 인시던트 핸드북에 자체 인시던트 관리 관행에 대한 명확한 정의를 마련해 두었습니다.
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. | ||
알맞은 팀이 즉시 협력하여 해결을 시작할 수 있도록 인시던트를 에스컬레이션하는 인시던트 관리 솔루션을 갖춰야 합니다.
알림 및 대기 일정, 공동 작업 커뮤니케이션, 강력한 보고 및 분석 기능을 포함한 Jira Service Management의 모든 인시던트 관리 기능이 팀에서 인시던트에 대응하고 해결하며 인시던트를 통해 학습하도록 지원하는 방법을 알아보세요.
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 tutorial인시던트 커뮤니케이션 템플릿 및 예제
인시던트에 대응할 때 커뮤니케이션 템플릿은 매우 중요합니다. Atlassian 팀에서 사용하는 템플릿과 일반적인 인시던트에 대한 더 많은 예시를 확인하세요.
Read this article