주요 인시던트 관리 프로세스를 실행하는 방법

큰 영향을 미치는 인시던트 관리 및 해결

주요 인시던트 관리(Atlassian에서는 간단하게 인시던트 관리라고도 함)는 DevOps 및 IT 운영 팀이 예기치 않은 이벤트나 서비스 중단에 대응하고 서비스를 운영 상태로 복원하는 데 사용하는 프로세스입니다.

주요 인시던트란 무엇입니까?

그렇다면 어떤 것이 주요 인시던트로 간주될까요? 주요 인시던트는 긴급한 수준의 중단 또는 서비스 손실입니다.

긴급한 수준의 정의는 조직마다 다릅니다. Atlassian에는 3개의 심각도 수준이 있으며 상위 2개(심각도 1 및 심각도 2)가 모두 주요 인시던트로 간주됩니다.

모든 Atlassian 고객에 대해 고객 대상 서비스가 중단된 경우는 심각도 1 인시던트에 해당합니다. 동일한 서비스지만 일부 고객에 대해서만 중단된 경우는 심각도 2로 간주됩니다. 둘 다 주요 인시던트에 해당하며 인시던트 관리 팀의 즉각적인 대응이 필요합니다.

필수 작업을 방해하지 않는 이슈는 심각도 3으로 간주되며 주요 인시던트는 아닙니다.

주요 인시던트 관리 프로세스의 정의

인시던트 수명 주기(인시던트 관리 프로세스라고도 함)는 인시던트를 식별하고, 해결하고, 파악하고, 반복되지 않도록 하기 위해 취하는 경로입니다.

인시던트 관리 프로세스는 회사마다 다르지만, 어떤 팀이든 성공의 비결은 주요 인시던트가 발생하기 전에 심각도 수준, 우선 순위, 역할 및 프로세스를 명확하게 정의하고 전달하는 것입니다.

우선 순위, 역할 및 프로세스에 대한 공통된 이해를 달성하기 위해, 주요 인시던트 관리 프로세스를 시작하거나 다시 검토하는 모든 팀은 다음과 같은 질문에 대한 답변을 명확히 파악하는 것부터 시작해야 합니다.

• 우리 회사/제품에서 주요 인시던트로 간주되는 것은 무엇인가?
• 인시던트의 심각도와 우선 순위 수준을 어떻게 정의하는가? 한 번에 두 개 이상의 주요 인시던트가 발생하면 어떤 것부터 먼저 해결해야 하는지 어떻게 알 수 있는가?
• 주요 인시던트를 해결하는 책임자는 누구인가? 팀원은 어떤 역할을 맡을 것인가? 역할을 어떻게 정의하고 전달할 것인가?
• 주요 인시던트 발생 시 팀은 어떤 프로세스를 따를 것인가? 인시던트 유형에 따라 두 개 이상의 프로세스가 있는가?
• 내부 및 외부 이해 관계자와 얼마나 자주 커뮤니케이션할 것인가? 우리의 커뮤니케이션 계획은 무엇인가?
• 주요 인시던트에 대한 대기 일정은 어떻게 구성될 것인가? 오전 2시에 발생하는 인시던트는 누가 담당할 것인가? 주말이나 연휴 기간 동안에는 누가 책임을 지는가?
• 알림 피로를 방지하면서 주요 인시던트의 신속한 해결을 우선시하려면 대기 중 인시던트 관리자에게 언제, 어떻게 알려야 하는가?

Atlassian의 주요 인시던트 관리 프로세스

Atlassian의 인시던트 관리 프로세스에는 감지, 새 인시던트 제기, 커뮤니케이션 열기, 평가, 초기 커뮤니케이션 보내기, 에스컬레이션, 위임, 후속 커뮤니케이션 보내기, 검토 및 해결이 포함됩니다.

감지

먼저 Atlassian의 기술, 고객의 신고 또는 직원을 통해 인시던트를 감지합니다. 누가 인시던트를 감지했든(이슈를 알아차린 기술자 또는 불만스러운 고객으로부터 전화를 받은 고객 서비스 담당자) 모두가 시스템에 인시던트를 로그하고 심각도 수준을 식별할 책임이 있습니다.

인시던트가 팀에 도달할 무렵에는 이미 심각도 1, 2 또는 3이 지정되어 있습니다. 심각도 1과 2는 주요 인시던트로 간주되며, 심각도 3은 영향이 낮은 인시던트를 의미합니다.

새 인시던트 제기

인시던트 티켓이 만들어지면 해당 서비스를 담당하는 대기 중 전문가에게 알림이 전송됩니다.

Atlassian에서 보내는 호출 알림에는 인시던트의 심각도 및 우선 순위에 대한 정보와 요약이 포함되어 있어, 최우선 순위의 인시던트인지 아니면 다른 인시던트가 진행 중인 경우 기다려도 되는지 한눈에 파악할 수 있습니다.

커뮤니케이션 열기

인시던트 관리자가 알림을 받으면 첫 번째로 해야 할 일은 인시던트 해결이 진행 중이라는 사실을 알리는 것입니다. 인시던트의 상태를 해결 중으로 변경하고 팀의 커뮤니케이션 채널을 설정합니다.

팀이 원하는 방식으로 계속 소통할 수 있도록 인시던트 대응 프로세스 전반에 걸쳐 유연한 커뮤니케이션 채널을 제공하는 것은 매우 중요합니다. Jira Service Management는 포함 가능한 상태 위젯, 전용 상태 페이지, 이메일, 채팅 도구, 소셜 미디어, SMS와 같은 여러 커뮤니케이션 채널을 통합하여 가동 중지 시간을 최소화합니다.

평가

인시던트 관리자가 알림을 받았고 커뮤니케이션 채널이 열렸습니다. 다음 단계는 인시던트 자체를 평가하는 것입니다.

Atlassian 팀의 경우 이 프로세스는 팀이 답변해야 하는 일련의 질문으로 시작됩니다.

• Atlassian의 고객과 직원에게 미치는 영향은 무엇인가?
• 고객이 어떤 이슈를 겪고 있는가?
• 영향을 받는 고객은 몇 명인가? (일부 또는 모든 고객)
• 인시던트는 언제 시작되었는가?
• 이 인시던트에 대해 열린 지원 사례는 몇 개인가?
• 심각도 수준 또는 우선 순위에 영향을 미치거나 인시던트에 접근하는 방식을 변경하는 다른 요인이 있는가? (예: 보안 문제, 소셜 미디어 PR 위기 등)

질문에 답변한 후에는 진단 및 제안된 해결 방법을 자신 있게 진행하거나, 필요에 따라 인시던트의 심각도 수준과 우선 순위 수준을 변경할 수 있습니다.

초기 커뮤니케이션 보내기

인시던트가 실제로 발생한 것을 확인한 후에는 고객 및 직원과의 커뮤니케이션이 최우선 과제가 됩니다. Atlassian의 핸드북에 따르면 다음과 같습니다.

"초기의 내부 커뮤니케이션은 단일 위치에서 인시던트 대응에 집중하고 혼란을 줄이는 것을 목표로 합니다. 외부 커뮤니케이션의 목적은 문제가 있음을 인식하고 신속하게 대처하고 있다는 사실을 고객에게 알리는 것입니다."

신속하고 정확한 커뮤니케이션은 고객의 신뢰를 쌓고 유지하는 데 도움이 됩니다.

Atlassian은 전략적인 인시던트 커뮤니케이션 계획을 갖추고 있으며 간단한 형식을 따르는 정기적인 상태 업데이트를 제공합니다. 또한 엔지니어링 리더십, 주요 인시던트 관리자 및 기타 주요 내부 직원을 포함하는 이해 관계자들에게 이메일을 보냅니다. 앞서 언급했듯이 이러한 모든 커뮤니케이션 방법은 Jira Service Management 내에서 사용자 지정할 수 있으며 모든 조직의 인시던트 대응 계획에 맞게 조정할 수 있습니다.

에스컬레이션

때로는 대기 중 팀에서 인시던트를 신속하게 해결할 수 있습니다. 그러나 빠르게 해결되지 않는 경우, 다음으로 해야 할 단계는 이 특정한 인시던트를 해결하는 데 더 적합한 다른 전문가나 전문가들의 팀에 이슈를 에스컬레이션하는 것입니다.

대응자는 Jira Service Management에서 관련 티켓을 그룹화하고 이슈에 공동 작업자를 추가하여 알림을 조정할 수 있습니다. 또한 대응자는 풍부한 인시던트 일정으로 모든 작업을 자동으로 기록하고 자동화 및 기술 자료 문서에 액세스하여 인시던트를 신속하게 조사하고 수정할 수 있습니다.

위임

이슈가 새로운 담당자에게 에스컬레이션되면 인시던트 관리자가 이들에게 역할을 위임합니다. Atlassian에서는 역할이 미리 설정되어 있으므로 팀원들은 자신에게 무엇을 수행해야 하는지 빠르게 파악할 수 있습니다.

주요 인시던트에는 한 명의 인시던트 관리자와 소규모 팀이 필요한 경우가 있습니다. 상황에 따라 여러 기술 리더나 여러 인시던트 관리자가 필요한 경우도 있습니다. 최초 인시던트 관리자는 어떤 경우에 해당하는지 파악하고 적절한 담당자를 참여시키는 임무를 맡습니다.

후속 커뮤니케이션 보내기

인시던트가 진행됨에 따라, 기술 팀 외부에 또다른 커뮤니케이션을 전달하면 고객과 직원을 진정시키고, 신뢰도를 유지하며 모두가 정보를 제공받을 수 있습니다. 이는 공동 작업자가 다양한 커뮤니케이션 플랫폼에서 알림을 관리하여 인시던트 대응에 대한 최신 정보를 파악할 수 있는 경우 쉽게 이루어집니다.

검토

하지만 인시던트 해결에 대한 천편일률적인 정답은 없습니다. 따라서 프로세스의 이 단계에 도달하면 시간을 내어 다음을 수행합니다.

• 일어나는 일을 관찰하고, 관찰 내용을 팀과 공유 및 확인
• 그 일이 발생한 이유 및 해결 방법에 대한 이론을 개발
• 이론을 증명하거나 반증하는 실험을 개발하고 실행
• 반복

인시던트 관리자는 이 프로세스 전반에 걸쳐 상황이 어떻게 진행되고 있는지 면밀히 주시합니다. 특정 팀원의 업무량이 과한지, 휴식이 필요한 팀원이 있는지, 신선한 관점이 필요한지 파악하여 필요에 따라 더 많은 위임이 이루어집니다.

해결

Atlassian의 인시던트 핸드북에서 해결은 “현재 발생했거나 임박한 비즈니스 영향이 종료된 시점”으로 정의됩니다.

이 시점에는 긴급 상황이 종료되었으며 팀은 정리 작업과 사후 검토를 진행합니다.

사후 검토

인시던트 수명 주기는 인시던트가 해결되면 종료되지만 Atlassian에서는 프로세스가 여기서 끝나지 않습니다. Atlassian에서는 인시던트가 반복되지 않도록 하기 위해서 최선의 노력을 기울입니다. 따라서 다음 단계는 인시던트의 원인을 파악하고 향후 위험을 완화하는 데 도움이 되도록 마련된 비난을 배제한 사후 검토입니다.

Jira Service Management를 사후 검토 템플릿과 함께 사용하면 사후 검토 보고서 및 관련 인시던트 타임라인을 쉽게 만들고 Confluence로 내보낼 수 있으므로 대응자는 계속해서 교차 기능 팀과 협업하여 후속 조치를 추적하고 향후의 비슷한 인시던트를 방지할 수 있습니다.

역할 및 책임

역할과 책임은 조직의 문화, 팀의 규모, 대기 일정 등에 따라 달라집니다. 일반적인 주요 인시던트 역할에는 다음이 포함됩니다.

인시던트 관리자: 인시던트 해결을 감독하는 책임자입니다.

기술 리더: 발생한 문제가 무엇인지와 그 이유를 파악하고, 최선의 조치를 결정하고, 기술 팀을 이끄는 임무를 맡은 선임 기술 전문가입니다.

커뮤니케이션 관리자: 인시던트의 영향을 받는 내부 및 외부 고객과의 커뮤니케이션을 담당하는 커뮤니케이션 전문가(주로 PR 또는 고객 지원 팀원)입니다.

고객 지원 리더: 인시던트에 대해 들어오는 티켓, 전화 통화 및 트윗에 적시에 적절하게 대응했는지 확인하는 담당자입니다.

소셜 미디어 리더: 소셜 채널에서 인시던트에 대한 커뮤니케이션을 담당하는 소셜 미디어 전문가입니다.

그 외의 일반적인 역할에는 다음이 포함됩니다.

근본 원인 분석가 또는 문제 관리자: 인시던트의 해결 범위를 넘어 근본 원인 및 향후 문제 발생을 방지하기 위해 수행해야 할 변경 사항을 식별하는 담당자입니다.

주요 인시던트 조사 위원회: 조사 및 변경 관리를 담당하는 그룹입니다.

Jira Service Management와 같은 인시던트 관리 솔루션은 대기 일정을 구성하고 알림을 제공하는 것부터 더 나은 협업을 위한 팀 통합과 인시던트 사후 검토 실행에 이르기까지 대응 프로세스의 각 단계에서 도움이 될 것입니다.