인시던트의 심각도 수준 파악

SEV 수준의 핵심 가치는 팀 시간을 절약한다는 것입니다. 심각도 수준이 마련되어 있고 각 수준을 해결하기 위한 명확한 로드맵을 갖춘 팀은 바로 문제 해결을 시작할 수 있습니다. 심각도 수준이 마련되어 있지 않은 팀은 인시던트의 중요성이 얼마나 높은지, 누가 처리해야 하는지, 어떻게 처리해야 하는지 알아내느라 주요 인시던트의 중요한 초기 시간을 낭비할 가능성이 높습니다.

인시던트가 심각할수록 인시던트 해결과 커뮤니케이션 계획뿐만 아니라 명확한 SEV 수준과 우선 순위도 미리 계획하여 시간을 최대한 절약하는 것이 중요합니다.

언뜻 보기에 인시던트 심각도는 인시던트 우선 순위와 같아 보일 수 있습니다. 결국 심각한 결과를 초래하는 심각한 인시던트는 덜 심각한 인시던트보다 먼저 처리해야 하기 때문입니다.

하지만 대부분의 비즈니스에서는 이것보다 더 복잡합니다.

심각도는 영향을 측정한 것입니다. 인시던트가 사용자에게 미치는 영향은 어느 정도인지, 전체 시스템이 중단되는지, 중요한 작업을 완료하지 못하게 되는지, 또는 단순히 성가시고 작업이 더 어려워지는 정도인지에 대해 질문하면 됩니다.

반면에 우선 순위는 긴급성을 측정한 것입니다. 이 이슈를 얼마나 빨리 해결해야 하는지, 어떤 이슈를 먼저 해결해야 하는지에 대해 질문해야 합니다.

두 측정값이 완벽하게 정렬될 때도 있습니다. 회사 전체를 중단시키는 심각도가 높은 인시던트는 DevOps 및 IT 팀이 집중해야 할 우선 순위가 가장 높은 인시던트이기도 할 것입니다.

하지만 우선 순위와 심각도가 일치하지 않을 때도 있습니다. 예를 들어, 웹사이트 홈페이지의 헤드라인에 오타가 있다고 가정해 보겠습니다. 웹사이트의 기능에 실제로 영향을 미치지 않기 때문에 심각도가 낮은 이슈입니다. 사용자는 필요한 모든 작업을 계속 수행할 수 있고 직원들은 해야 하는 일을 계속 할 수 있습니다.

그러나 비즈니스는 브랜드 표준과 관련된 이유, 또는 혼란을 유발하거나 단순히 안 좋게 보인다는 이유로 이 이슈의 수정을 우선 순위가 높은 것으로 볼 수 있습니다. 따라서 이 인시던트는 심각도가 낮고 우선 순위가 높을 수 있습니다.

마찬가지로, 앱 비정상 종료의 원인이 되는 인시던트가 있다고 가정해 보겠습니다. 사용자가 해야 하는 작업을 수행하지 못하도록 만들기 때문에 심각도가 높습니다. 하지만 인시던트가 0.05%의 사용자에게만 영향을 준다고 가정해 보겠습니다. 일반적으로 시스템 충돌이 발생했다고 하면 모두가 문제를 해결해야 하는 상황이지만, 더 큰 영향을 미치는 다른 인시던트가 있는 경우 이와 같은 이슈는 가장 높은 우선 순위가 아닐 수 있습니다.

두 측정값 모두 인시던트 관리에서 중요하지만 그 둘이 정렬되는 경우와 그렇지 않은 경우를 파악해야 합니다. 심각도가 높다고 해서 자동으로 우선 순위의 목록의 맨 위에 올라가는 것이 않으며, 높은 우선 순위라고 해서 항상 시스템이 다운되었다는 것도 아닙니다.

우선 순위는 심각도보다 실행에 옮기기 쉽기 때문에, 우리가 사용하는 기본 측정값은 우선 순위입니다. 또한 심각도는 우선 순위를 결정하는 핵심 요소인 경우가 많으므로, 인시던트 핸드북에 자체 인시던트 관리 관행에 대한 명확한 정의를 마련해 두었습니다.

모든 인시던트가 똑같은 것은 아니며 모든 조직이 같은 방식으로 인시던트를 처리하지 않습니다. 심각도 수준과 관련 프로세스 및 기대치를 설정할 때는 인시던트의 영향 외에도 다음을 고려해야 합니다.

• 기술 팀의 규모
• 대기 일정
• 하루 중 서비스 사용량이 많은 시간대와 적은 시간대
• 인시던트 발생 빈도

그 이유는 무엇일까요? 이러한 각 요소가 SEV 수준을 정의하는 방식에 영향을 줄 수 있기 때문입니다.

예를 들어, 특정 시간대에 현지 시장에 서비스를 제공하는 어떤 앱은 오전 2시와 오전 7시 간의 사용량 차이가 클 수 있습니다. 그렇다면 오전 3시에 시스템 전체가 중단되는 경우 사용량이 많은 시간대의 시스템 중단과 SEV 수준이 같을까요?

또는 소규모 팀이 있는 스타트업인데 보통 SEV 3 인시던트라고 간주할 만한 인시던트가 많은 경우라면 어떨까요? 계속하여 SEV 3으로 지정하고 한 번에 3개의 인시던트가 발생했을 때 팀이 어떤 인시던트의 우선 순위가 높은지 파악하도록 해야 할까요? 아니면 고객이 직접 사용하는 시스템의 일부 기능 손실, 성능 이슈, 그리고 시스템의 사용성에 영향을 미치지는 않지만 결국에는 해결해야 하는 버그와 같은 사소한 문제를 구별하기 위해 인시던트를 SEV 3, 4, 심지어는 5까지도 더 나누어야 할까요?

여기서 중요한 것은 비즈니스, 팀, 그리고 적합한 SEV 수준 및 우선 순위 수준의 정의를 파악하는 것입니다.

알맞은 팀이 즉시 협력하여 해결을 시작할 수 있도록 인시던트를 에스컬레이션하는 인시던트 관리 솔루션을 갖춰야 합니다.

알림 및 대기 일정, 공동 작업 커뮤니케이션, 강력한 보고 및 분석 기능을 포함한 Jira Service Management의 모든 인시던트 관리 기능이 팀에서 인시던트에 대응하고 해결하며 인시던트를 통해 학습하도록 지원하는 방법을 알아보세요.