빠른 속도의 팀을 위한 인시던트 관리
인시던트의 심각도 수준 파악
더 빠른 해결을 위해 인시던트를 파악하고 우선 순위를 지정
인시던트 관리에는 세 가지 중요한 사실이 있습니다.
첫 번째는 인시던트란 불가피하며, 특히 끊임없이 성장하고 혁신하는 회사의 경우 더욱 그렇다는 것입니다.
두 번째는 정상적인 비즈니스 운영을 위해서는 강력한 인시던트 관리 관행이 필수적이라는 것입니다(그리고 관행이 약한 경우 직원의 시간 및 만족도와 비즈니스 수익 모두에서 비즈니스에 큰 타격을 입힘).
세 번째는 모든 인시던트가 똑같지는 않다는 것입니다. 하나의 데이터베이스에서 데이터를 잃는 것은 모든 데이터베이스에서 데이터를 잃는 것과 다릅니다 20%의 사용자에게 영향을 미치는 서비스 중단을 처리하는 것은 90% 또는 100%의 사용자에게 영향을 미치는 서비스 중단을 처리하는 것과는 완전히 다른 문제입니다. 사용량이 많은 시간대의 시스템 중단을 처리하는 것은 대부분의 고객이 잠든 시간에 처리하는 것보다 스트레스를 훨씬 많이 받게 됩니다. 서류상으로는 똑같아 보이는 2개의 인시던트라도 자세히 살펴보면 각각 다릅니다.
빠른 속도의 팀을 위한 인시던트 관리
Jira Service Management로 인시던트 발생 시 대응하고 시스템을 복원하기 위해 운영 팀과 개발 팀 간의 정보 흐름을 가속화하세요.
이것이 바로 강력한 인시던트 관리 프로그램을 갖춘 회사에서 인시던트 심각도 수준이 잘 정의되어 있고 인시던트 발생 시 우선 순위를 정하는 명확한 모범 사례를 마련해 놓는 이유입니다.
심각도 수준이란 무엇입니까?
인시던트 심각도 수준은 인시던트가 비즈니스에 미치는 영향을 측정한 것입니다. 일반적으로 심각도 숫자가 낮을수록 인시던트의 영향이 큰 것입니다.
예를 들어, Atlassian에서는 SEV(심각도) 1 인시던트를 “매우 큰 영향을 미치는 중요 인시던트”라고 정의합니다. 여기에는 고객 데이터 손실, 보안 침해 또는 고객이 직접 사용하는 서비스가 모든 고객을 대상으로 중단된 경우가 포함될 수 있습니다.
SEV 2 인시던트는 “심각한 영향을 미치는 주요 인시던트”로, 고객이 직접 사용하는 서비스가 일부 고객을 대상으로 중단되거나 시스템 안의 중요 기능이 작동하지 않는 경우가 포함됩니다.
그리고 SEV 3 인시던트는 시스템 결함으로 인해 고객에게 약간의 불편을 유발하는 것과 같이 “적은 영향을 미치는 경미한 인시던트”입니다.
Atlassian의 경우 SEV 3 인시던트는 낮이나 근무 시간에 처리할 수 있는 인시던트이며, SEV 1 및 SEV 2 인시던트는 시간에 관계없이 즉시 문제를 해결할 수 있도록 대기 중 담당자에게 알림을 생성합니다.
| 심각도 | 설명 | 예 |
|---|---|---|
| 1 | 매우 큰 영향을 미치는 심각한 인시던트 |
|
| 2 | 심각한 영향을 미치는 중요 인시던트 |
|
| 3 | 적은 영향을 미치는 경미한 인시던트 |
|
심각도 수준은 인시던트의 영향을 빠르게 파악하고 IT 및 DevOps 팀의 우선 순위를 지정하는 데 유용합니다.
SEV 수준이 잘 정의될수록 팀이 같은 정보를 공유하고 인시던트 발생 시 빠르고 적절하게 대응할 가능성이 높아집니다. 심각도 수준이 잘 정의되어 있지 않으면 소중한 시간을 인시던트 해결에 할애하는 것이 아니라 인시던트의 긴급성을 정의하고 설명하는 데 낭비하기 쉽습니다.
심각도 수준은 언제, 어디에서 유용하게 사용됩니까?
SEV 수준의 핵심 가치는 팀 시간을 절약한다는 것입니다. 심각도 수준이 마련되어 있고 각 수준을 해결하기 위한 명확한 로드맵을 갖춘 팀은 바로 문제 해결을 시작할 수 있습니다. 심각도 수준이 마련되어 있지 않은 팀은 인시던트의 중요성이 얼마나 높은지, 누가 처리해야 하는지, 어떻게 처리해야 하는지 알아내느라 주요 인시던트의 중요한 초기 시간을 낭비할 가능성이 높습니다.
인시던트가 심각할수록 인시던트 해결과 커뮤니케이션 계획뿐만 아니라 명확한 SEV 수준과 우선 순위도 미리 계획하여 시간을 최대한 절약하는 것이 중요합니다.
심각도와 우선 순위는 어떻게 다릅니까?
언뜻 보기에 인시던트 심각도는 인시던트 우선 순위와 같아 보일 수 있습니다. 결국 심각한 결과를 초래하는 심각한 인시던트는 덜 심각한 인시던트보다 먼저 처리해야 하기 때문입니다.
하지만 대부분의 비즈니스에서는 이것보다 더 복잡합니다.
심각도는 영향을 측정한 것입니다. 인시던트가 사용자에게 미치는 영향은 어느 정도인지, 전체 시스템이 중단되는지, 중요한 작업을 완료하지 못하게 되는지, 또는 단순히 성가시고 작업이 더 어려워지는 정도인지에 대해 질문하면 됩니다.
반면에 우선 순위는 긴급성을 측정한 것입니다. 이 이슈를 얼마나 빨리 해결해야 하는지, 어떤 이슈를 먼저 해결해야 하는지에 대해 질문해야 합니다.
두 측정값이 완벽하게 정렬될 때도 있습니다. 회사 전체를 중단시키는 심각도가 높은 인시던트는 DevOps 및 IT 팀이 집중해야 할 우선 순위가 가장 높은 인시던트이기도 할 것입니다.
하지만 우선 순위와 심각도가 일치하지 않을 때도 있습니다. 예를 들어, 웹사이트 홈페이지의 헤드라인에 오타가 있다고 가정해 보겠습니다. 웹사이트의 기능에 실제로 영향을 미치지 않기 때문에 심각도가 낮은 이슈입니다. 사용자는 필요한 모든 작업을 계속 수행할 수 있고 직원들은 해야 하는 일을 계속 할 수 있습니다.
그러나 비즈니스는 브랜드 표준과 관련된 이유, 또는 혼란을 유발하거나 단순히 안 좋게 보인다는 이유로 이 이슈의 수정을 우선 순위가 높은 것으로 볼 수 있습니다. 따라서 이 인시던트는 심각도가 낮고 우선 순위가 높을 수 있습니다.
마찬가지로, 앱 비정상 종료의 원인이 되는 인시던트가 있다고 가정해 보겠습니다. 사용자가 해야 하는 작업을 수행하지 못하도록 만들기 때문에 심각도가 높습니다. 하지만 인시던트가 0.05%의 사용자에게만 영향을 준다고 가정해 보겠습니다. 일반적으로 시스템 충돌이 발생했다고 하면 모두가 문제를 해결해야 하는 상황이지만, 더 큰 영향을 미치는 다른 인시던트가 있는 경우 이와 같은 이슈는 가장 높은 우선 순위가 아닐 수 있습니다.
두 측정값 모두 인시던트 관리에서 중요하지만 그 둘이 정렬되는 경우와 그렇지 않은 경우를 파악해야 합니다. 심각도가 높다고 해서 자동으로 우선 순위의 목록의 맨 위에 올라가는 것이 않으며, 높은 우선 순위라고 해서 항상 시스템이 다운되었다는 것도 아닙니다.
우선 순위는 심각도보다 실행에 옮기기 쉽기 때문에, 우리가 사용하는 기본 측정값은 우선 순위입니다. 또한 심각도는 우선 순위를 결정하는 핵심 요소인 경우가 많으므로, 인시던트 핸드북에 자체 인시던트 관리 관행에 대한 명확한 정의를 마련해 두었습니다.
조직의 인시던트 심각도 수준 정의
모든 인시던트가 똑같은 것은 아니며 모든 조직이 같은 방식으로 인시던트를 처리하지 않습니다. 심각도 수준과 관련 프로세스 및 기대치를 설정할 때는 인시던트의 영향 외에도 다음을 고려해야 합니다.
- 기술 팀의 규모
- 대기 일정
- 하루 중 서비스 사용량이 많은 시간대와 적은 시간대
- 인시던트 발생 빈도
그 이유는 무엇일까요? 이러한 각 요소가 SEV 수준을 정의하는 방식에 영향을 줄 수 있기 때문입니다.
예를 들어, 특정 시간대에 현지 시장에 서비스를 제공하는 어떤 앱은 오전 2시와 오전 7시 간의 사용량 차이가 클 수 있습니다. 그렇다면 오전 3시에 시스템 전체가 중단되는 경우 사용량이 많은 시간대의 시스템 중단과 SEV 수준이 같을까요?
또는 소규모 팀이 있는 스타트업인데 보통 SEV 3 인시던트라고 간주할 만한 인시던트가 많은 경우라면 어떨까요? 계속하여 SEV 3으로 지정하고 한 번에 3개의 인시던트가 발생했을 때 팀이 어떤 인시던트의 우선 순위가 높은지 파악하도록 해야 할까요? 아니면 고객이 직접 사용하는 시스템의 일부 기능 손실, 성능 이슈, 그리고 시스템의 사용성에 영향을 미치지는 않지만 결국에는 해결해야 하는 버그와 같은 사소한 문제를 구별하기 위해 인시던트를 SEV 3, 4, 심지어는 5까지도 더 나누어야 할까요?
여기서 중요한 것은 비즈니스, 팀, 그리고 적합한 SEV 수준 및 우선 순위 수준의 정의를 파악하는 것입니다.
| Atlassian 티어 3 | 티어 4 | 티어 5 | |
|---|---|---|---|
| 심각도 1 | 매우 큰 영향을 미치는 중요 인시던트입니다. | ||
| 심각도 2 | 심각한 영향을 미치는 주요 인시던트입니다. | ||
| 심각도 3 | 적은 영향을 미치는 경미한 인시던트입니다. 예를 들어, 시스템 버그로 인해 고객에게 경미한 불편을 끼치는 경우입니다. | 빨리 해결하지 않으면 주요 인시던트가 될 가능성이 있는 인시던트입니다. | |
| 심각도 4 | 고객에게는 성가시는 일이지만 전체 시스템 기능에는 영향을 미치지 않는 지원 요청입니다. | 제품 사용성에 영향을 주지만 중단을 유발하지는 않는 경미한 인시던트입니다. | |
| 심각도 5 | 제품 사용성에 영향을 주지 않는 버그 또는 지원 이슈입니다. | ||
알맞은 팀이 즉시 협력하여 해결을 시작할 수 있도록 인시던트를 에스컬레이션하는 인시던트 관리 솔루션을 갖춰야 합니다.
알림 및 대기 일정, 공동 작업 커뮤니케이션, 강력한 보고 및 분석 기능을 포함한 Jira Service Management의 모든 인시던트 관리 기능이 팀에서 인시던트에 대응하고 해결하며 인시던트를 통해 학습하도록 지원하는 방법을 알아보세요.