에스컬레이션 정책이란 무엇입니까?

주요 내용: 에스컬레이션 정책은 인시던트 알림이 발생할 때 누구에게 알릴지, 첫 번째 대응자가 부재중이거나 해결할 수 없는 경우 인시던트를 누구에게 전달할지, 그리고 이러한 전달이 어떻게 이루어지는지를 정의하며, 이는 일반적으로 심각도, 지속 시간 및 범위에 따라 달라집니다.

• 정의: 에스컬레이션 매트릭스에 주로 기록되는 문서화된 경로로, 계층적(직급별), 기능적(전문성별), 자동(규칙에 따라, 시간 내에 알림을 확인하지 않은 경우)의 세 가지 에스컬레이션 유형을 사용합니다.

• 이것이 중요한 이유: 이 정책이 없으면 사람들이 누구에게 연락할지 파악하는 동안 인시던트가 지연되지만, 정책을 갖추면 적절한 대응자가 몇 분 안에 참여하게 되며 잘못된 문제로 호출되는 사람이 없습니다.

• Jira Service Management가 도움이 되는 방법: 대기 중 담당자 일정 관리 및 알림 기능을 통해 팀은 서비스 및 심각도별로 에스컬레이션 규칙을 정의하고, 확인되지 않은 알림을 자동 에스컬레이션하며, 모든 핸드오프가 추적되도록 인시던트 레코드 내에서 에스컬레이션할 수 있습니다.

에스컬레이션 정책은 인시던트에 대해 처음 알림을 받은 사람이 혼자서 처리할 수 없을 때 발생하는 상황에 대한 문서화된 계획입니다. 여기에는 누구에게 먼저 알릴지, 담당자가 부재중이거나 해결할 수 없는 경우 누가 인계받을지, 인계가 얼마나 빨리 이루어질지, 어떤 채널을 통해 이루어질지 등이 포함됩니다. 이 정책은 대기 중 담당자 일정과 함께 적용됩니다. 일정은 누가 대기 중인지 알려주고, 정책은 담당자들 사이에서 인시던트가 어떻게 이동하는지 알려줍니다.

가장 좋은 경우는 대기 중 엔지니어가 스스로 인시던트를 해결하는 것입니다. 그러나 해결에 더 큰 팀, 전문 지식 또는 더 숙련된 기술이 필요한 경우가 수시로 발생하며 기술 직원을 여러 명 두고 있는 조직에는 에스컬레이션 계획이 필요합니다. 이 가이드에서는 에스컬레이션 유형, 에스컬레이션 매트릭스, 효과적인 정책 작성을 위한 모범 사례를 다룹니다.

인시던트 에스컬레이션이란 무엇입니까?

인시던트 에스컬레이션은 직원이 직접 인시던트를 해결할 수 없어 더 숙련되거나 전문적인 직원에게 작업을 넘겨야 할 때 발생합니다.

에스컬레이션 정책이란 무엇입니까?

질문은 간단해 보일 수 있지만, 조직이 커지고 기술 에코시스템이 복잡해질수록 답변에는 더 많은 세부 정보가 필요합니다. 예를 들어, 인시던트 알림이 수신될 때 누구에게 알려야 할지 결정하는 경우, 대기 중 담당자나 연락 가능한 사람이 누구인지뿐만 아니라 심각도 수준, 인시던트 지속 시간 등에 따라 답변이 달라질 수 있습니다. 

어떤 회사에서는 인시던트 심각도에 관계없이 한 명의 대기 중 담당자가 가장 먼저 알림을 받을 수 있으며, 다른 회사에서는 인시던트가 심각도 3인 경우 후임 개발자에게 알림을 보내고, 심각도 1인 경우 선임 개발자나 전문 팀에 알리는 것이 합리적인 조치일 수 있습니다.

마찬가지로, 어떤 회사는 필요할 때 인시던트를 에스컬레이션하기 위해 첫 번째 대응자에게 의존할 수 있습니다. 인시던트가 일정 시간을 초과하거나 더 많은 시스템 또는 사용자에게 영향을 미치기 시작하면 선임 개발자 또는 전문 팀으로 자동 에스컬레이션을 트리거하는 회사도 있습니다.

에스컬레이션 정책은 회사에서 인시던트를 어떻게, 누구에게 에스컬레이션하는지뿐만 아니라 인시던트 유형, SEV 수준, 기간 및 인시던트 범위에 따라 미묘한 차이가 있는지 여부도 다뤄야 합니다.

인시던트 에스컬레이션 프로세스

ITSM 모범 사례를 따르는 회사의 경우 일반적으로 서비스 데스크는 인시던트 에스컬레이션의 중심에 있습니다. 첫 번째 대응자가 인시던트를 해결할 수 없는 경우 서비스 데스크로 돌아가 문제를 적절한 다음 방어선으로 에스컬레이션합니다. 대응자는 Jira Service Management를 사용하여 인시던트 티켓 내에서 인시던트를 에스컬레이션할 수 있습니다. 대응자는 문제 해결 프로세스를 안내하는 워크플로에 액세스하고 필요에 따라 자동화를 시행하거나 작업을 사용자 지정할 수 있습니다. 심각도 수준을 지정하면 대응자를 적절한 워크플로로 안내할 수 있습니다.

Google과 같은 기타 회사에서는 SRE를 인시던트를 담당자로 두고 있으며, 이 담당자는 필요한 에스컬레이션을 수행할 책임이 있습니다(그리고 인시던트로 인해 팀이 SLA/SLO에 따라 허용되는 가동 중지 시간 임계값을 초과하는 경우 새 릴리스를 동결).

다른 회사의 경우, 최초 대응자는 개발자 또는 인시던트 관리자이거나 여러 최초 연락 지점이 있을 수 있으며(특히 심각도가 높은 인시던트에 대한 알림이 들어오는 경우) 해당 팀 내에서 또는 팀 간에 직접 사전 정의된 프로세스를 통해 에스컬레이션이 발생할 수 있습니다.

프로세스가 서비스 데스크를 통해 진행되든, SRE에 의해 진행되든, 인시던트 추적 시스템 내에서 자동으로 수행되든 관계없이 일반적으로 에스컬레이션 정책이 따르는 세 가지 경로가 있습니다.

계층적 에스컬레이션

계층적 에스컬레이션은 조직 내에서 갖춘 경험의 수준 또는 직급에 따라 팀이나 개인에게 인시던트를 전달하는 것입니다. 

예를 들어, 대기 중인 첫 번째 대응자는 팀에 새로 합류한 후임 개발자일 수 있습니다. 후임 개발자가 문제를 해결할 수 없는 경우 조직의 계층에 따라 이 문제를 선임 개발자에게 전달합니다. 선임 개발자도 해결할 수 없는 경우 문제는 상급 선임 개발자에게 전달되며, 문제가 해결될 때까지 조직의 계층 위로 전달됩니다.

기능적 에스컬레이션

기능적 에스컬레이션은 직급이 아니라 기술 또는 시스템 지식을 기반으로 인시던트를 해결할 수 있는 가장 적합한 팀이나 담당자에게 인시던트를 전달하는 것입니다. 

예를 들어, 대기 중인 첫 번째 대응자는 제품 X의 백엔드에 중점을 둔 팀의 후임 개발자일 수 있습니다. 핵심 문제가 제품 Y와의 통합에서 비롯된 것으로 보이는 경우 인시던트를 제품 Y 팀의 다른 후임 개발자에게 에스컬레이션할 수 있습니다.

자동 에스컬레이션

Opsgenie와 같은 플랫폼을 사용하는 팀의 경우 주요 대기 중 담당자가 알림을 확인하지 않거나 종료하지 않는 경우 인시던트를 자동으로 에스컬레이션하도록 시스템에 지시하는 규칙을 설정할 수도 있습니다.

어떤 팀에서는 특정 에스컬레이션 방법을 다른 방법보다 선호할 수 있지만, 이 방법은 상호 배타적이지 않으며 많은 팀에서는 계층적, 기능적, 자동 에스컬레이션을 혼합하여 사용합니다.

에스컬레이션 행렬

에스컬레이션 행렬은 에스컬레이션이 이루어져야 하는 시기와 각 에스컬레이션 수준에서 인시던트를 처리해야 하는 담당자를 정의하는 문서 또는 시스템입니다. 

이 용어는 여러 업계에서 사용됩니다. 인사 팀에서는 내부 문제에 대한 에스컬레이션 행렬, 콜 센터에는 고객 서비스 문제에 대한 에스컬레이션 행렬이 있을 수 있습니다. 또한 IT 및 DevOps 팀에는 엔지니어가 인시던트를 에스컬레이션하는 방법과 시기를 파악하는 데 도움이 되는 행렬이 여러 개 있을 수 있습니다. 

매트릭스의 세부적인 내용은 회사마다 크게 다릅니다. 어떤 조직에서는 각 개발자가 필요에 따라 더 높은 기술 수준을 가진 개발자에게 에스컬레이션하는 간단한 계층적 차트를 사용할 수 있으며, 다른 조직에서는 개발자에게 다양한 유형의 인시던트 또는 심각도 수준에 대해 어떤 팀에 문의해야 하는지 알려주는 상황별 매트릭스가 있을 수 있습니다. 대부분의 인시던트 관리와 마찬가지로 조직의 매트릭스를 개발하는 방법에 대한 만능 해결책은 없습니다.

에스컬레이션 정책 수립을 위한 모범 사례

에스컬레이션 정책을 엄격한 규칙이 아닌 가이드라인으로 취급

기술은 정적이지 않으며 팀도 마찬가지입니다. Google은 SRE가 특정 사례에 다른 에스컬레이션 전략이 필요하다고 생각하는 경우 판단을 내릴 자유를 제공하는 것이 좋다고 말합니다. 여기서의 요점은 유연하지 않은 규칙을 만드는 것이 아니라 대부분의 상황에 적용되는 가이드라인을 만드는 것입니다.

대기 중 담당자 일정에 대해 정기적으로 감사 진행

일정에 격차가 있습니까? 적절한 담당자가 대기 근무를 하고 있습니까? 두 번째 및 세 번째 대기 중 계층에 적절한 담당자가 있습니까? 신속한 인시던트 관리를 위해서는 대기 일정 및 에스컬레이션 정책이 함께 작용해야 합니다.

에스컬레이션에 대한 스마트 임계값 설정

인시던트는 다 똑같은 것이 아니므로, 모든 인시던트가 동일한 에스컬레이션 정책을 따를 수 있거나 따라야 하는 것은 아닙니다. 

경미한 인시던트의 경우 근무 시간 전까지는 대기 중 엔지니어에게 알리지 않는 것이 좋을 수 있습니다. 주요 인시던트라면 시간에 관계없이 해당 엔지니어가 필요할 수 있습니다. 인시던트가 여러 개인 경우, 엔지니어는 어떤 인시던트를 먼저 해결해야 하는지와 언제 특정 인시던트를 즉시 두 번째 엔지니어에게 에스컬레이션해야 하는지 알아야 합니다.   

여기에는 시스템의 가동 시간을 최대화하고 SLA 약속 및 SLO 목표를 충족하는지 확인하는 것과 엔지니어가 번아웃을 겪거나, 과로하거나, 수면 부족 및 알림 피로를 겪지 않도록 하는 것 사이의 균형이 포함됩니다.

에스컬레이션에 대한 명확한 프로세스 설정

에스컬레이션을 하는 개발자는 해당 팀이나 담당자에게 직접 연락해야 합니까, 아니면 지원 센터를 거쳐야 합니까? 개발자가 사용해야 하는 시스템이 있습니까? 에스컬레이션을 어떻게 추적합니까? 첫 번째 대응자는 다음 대응자가 인시던트를 받았는지 확인하는 데 어떤 책임이 있습니까?

에스컬레이션을 원활하게 진행하고 인시던트를 더 빠르게 해결하려면 정책에 따라 이러한 질문을 명확하게 해결하고 모든 대기 중 개발자에게 분명하게 전달해야 합니다.

Jira Service Management가 인시던트 에스컬레이션에 대한 협업 솔루션을 제공하여 보다 빠른 해결 방법을 제공함으로써 인시던트 관리 관행을 강화할 수 있는 방법에 대해 자세히 알아보세요.