인시던트에 대응

감지

회사의 직원들은 여러 방식으로 인시던트를 인지할 수 있습니다. 모니터링이나 고객 보고서를 통해, 또는 직접 관찰하여 인시던트에 대해 알게 될 수 있습니다. 그러나 인시던트 발생 시 팀에서 가장 먼저 취할 조치는 인시던트 티켓 로그(Atlassian에서는 Jira 이슈)입니다.

새 인시던트 제출

인시던트 이슈가 생성되었지만 아직 인시던트 관리자(IM)에게 할당되기 전이면 해당 인시던트는 신규 상태입니다. 이는 Jira 인시던트 워크플로우의 초기 상태입니다.

Atlassian에는 새로운 주요 인시던트가 생성되면 Jira 웹훅을 사용하여 호출 알림을 트리거하는 서비스가 있습니다. 이 기능을 사용하여 선택된 서비스를 기준으로 대기 중인 IM에게 알림을 보냅니다. 예를 들어, Bitbucket과 관련된 인시던트가 생성되면 Bitbucket 인시던트 관리자를 호출합니다. 또한, 사용 가능한 '대기 중인 인시던트 관리자'(IMOC)로 알려진 전 세계 주요 인시던트 관리자로 구성된 광범위한 명단도 있습니다.

호출 알림에는 인시던트 관리자가 어디에서 인시던트 관리를 시작할지(Jira 이슈), 전체적으로 무엇이 잘못되었는지, 얼마나 심각한지를 파악할 수 있도록 인시던트의 이슈 키, 심각도, 요약이 포함됩니다.

커뮤니케이션 열기

IM은 온라인에 접속한 후 가장 먼저 자신에게 인시던트 이슈를 할당하고, 이슈를 해결 중 상태로 전환합니다. Jira 이슈 담당자 필드에는 현재 IM이 누군인지도 표시됩니다. 긴급 상황 대응 시 담당자를 명확하게 알리는 것은 매우 중요하며, 따라서 이 필드를 정확하게 입력해야 합니다.

그런 다음 IM은 인시던트 팀의 커뮤니케이션 채널을 설정합니다. 이 시점에서 목표는 잘 알려진 위치로 모든 인시던트 팀 커뮤니케이션을 설정하고 집중시키는 것입니다. 일반적으로 세 개의 팀 커뮤니케이션 방법이 사용되며, 각 방법은 모든 인시던트에 대해 Jira 이슈의 필드로 표시됩니다.

• 채팅방은 Slack 또는 다른 메시징 서비스에서 사용됩니다. 팀은 채팅방에서 커뮤니케이션하고 타임스탬프가 기록되고 보존되는 방식으로 관찰한 내용, 링크 및 스크린샷을 공유할 수 있습니다. 채팅 채널의 이름을 이슈 키와 동일하게 지정하여(예: HOT-1234) 관여해야 하는 담당자가 대화에 쉽게 참여할 수 있도록 하세요.
• 영상 채팅은 Skype, Blue Jeans 등의 컨퍼런스 앱에서 사용됩니다. 모두 같은 위치에서 일하고 있다면 실제 회의실에 팀을 소집하세요. Atlassian의 경험에 따르면 직접 얼굴을 맞대는 오프라인 회의가 팀이 우왕좌왕하지 않고 일을 더 신속하게 처리하는 데 도움이 됩니다.
• Confluence 페이지는 '인시던트 상태 페이지'입니다. 사람들이 동시에 동일한 페이지를 편집하면 실시간으로 수집되는 정보를 확인할 수 있습니다. 이는 변경(예를 들어 누가 무엇을 언제, 어떻게, 왜 변경했는지, 취소 방법은 무엇인지 등이 표시된 표), 여러 개의 작업 스트림 또는 연장된 타임라인을 추적하는 데 매우 유용한 방법입니다. 인시던트 상태 문서는 복잡하거나 연장된 인시던트 처리 중에 정보를 확인하는 소스로서 매우 유용합니다.

영상 채팅과 채팅방은 서로 다른 일에 최적화되어 있기 때문에 인시던트 처리 중에 두 방법을 모두 사용하는 것이 가장 좋습니다. 영상 채팅은 그룹 토론을 통해 인시던트에 대한 개념을 빠르게 생성하고 공유할 수 있는 장점이 있고, 문자 채팅은 인시던트를 타임스탬프별로 기록하고 대시보드, 스크린샷, 기타 URL의 링크를 공유할 수 있는 장점이 있습니다.

또한, 이러한 방법을 사용하여 중요한 관찰 내용, 변경, 기록되지 않은 대화에서 이루어진 의사 결정을 기록할 수 있습니다. IM 또는 인시던트 팀원은 실시간으로 관찰 내용, 변경, 의사 결정을 전용 채팅방에 기록하여 간단하게 이러한 작업을 할 수 있습니다. 직원들이 혼잣말을 하는 것 같이 보여도 괜찮습니다! 기록은 팀이 인시던트 타임라인을 재구성하고 인시던트의 원인을 파악해야 하는 사후 검토 과정 중에 매우 유용하게 사용됩니다.

대부분의 채팅 시스템에는 채팅방 주제 기능이 있으며, IM이 다음과 같은 인시던트에 대한 정보와 유용한 링크로 채팅방 주제를 업데이트합니다.

• 인시던트 요약 및 심각도
• 각 역할을 수행하는 담당자(IM부터 시작)
• 인시던트 이슈, 영상 채팅방, 인시던트 상태 문서의 링크

이를 통해 인시던트의 이슈 키가 있는 사람이라면 누구나 채팅에 참여하고 인시던트 처리 과정을 따라갈 수 있습니다. 채팅 채널 이름은 인시던트 이슈 키(예: HOT-1234)에 따라 지정하는 것을 기억하세요.

마지막으로, IM은 고유 개인 채팅 상태를 현재 관리 중인 인시던트의 이슈 키로 설정할 수 있습니다. 그러면 동료들은 해당 IM이 현재 인시던트를 관리하고 있다는 것을 알 수 있습니다.

펑가

인시던트 팀의 커뮤니케이션 채널이 설정된 후에는, 팀에서 인시던트에 대해 알릴 내용과 해당 인시던트를 해결할 담당자를 결정할 수 있도록 인시던트를 평가해야 합니다.

IM은 팀에 다음을 질문해야 합니다.

• 내부 또는 외부 고객에게 어떤 영향을 미치는가?
• 고객이 어떤 이슈를 겪고 있는가?
• 얼마나 많은 고객이 영향을 받는가(일부 또는 전체)?
• 언제 시작되었는가?
• 고객이 얼마나 많은 지원 사례를 열었는가?
• Twitter, 보안 또는 데이터 유실과 같은 다른 요인이 있는가?

이제 인시던트의 일정에 평가한 내용을 추가합니다. 참여하는 직원들이 빠르게 따라올 수 있도록 팀에서 관찰한 사항을 기록하세요. 이는 나중에 사후 검토 프로세스에서도 중요하게 사용됩니다. 인시던트가 시작된 시간이 변경 작업(예: Bamboo 배포)과 일치하는지 여부를 기록합니다. 어쩌면 해당 변경을 롤백하여 인시던트를 해결할 수도 있습니다.

인시던트의 영향과 팀에서 인시던트 해결에 소요될 것으로 예상하는 작업량에 따라 이슈에 다음 심각도 수준 중 하나를 할당합니다.

초기 커뮤니케이션 보내기

인시던트가 실제 발생한 것이라는 합리적 의심이 드는 경우 최대한 신속하게 내부 및 외부에 알립니다. 처음에 내부에 알리는 목적은 단일 위치에서 인시던트 대응에 집중하고 혼란을 줄이는 것입니다. 외부에 알리는 목적은 현재 문제가 발생했으며 신속하게 대처하고 있음을 고객에게 알리는 것입니다. 인시던트에 대해 신속하고 정확하게 알림으로써 직원과 고객의 신뢰를 구축할 수 있습니다.

인시던트에 대해 내부 및 외부에 알릴 때 Statuspage를 사용합니다. 내부 직원과 외부 고객에 대해 별도의 상태 페이지가 사용됩니다. 각 상태 페이지의 사용에 대한 내용은 뒤에서 다룰 예정입니다. 여기에서는 최대한 신속하게 알리는 것이 중요합니다. 신속한 알림을 위해 다음 템플릿을 따릅니다.

에스컬레이션

인시던트 관리를 맡고, 팀 커뮤니케이션을 설정하고, 상황을 평가하고, 직원과 고객에게 인시던트가 현재 진행 중임을 알렸습니다. 그럼 이제 무엇을 해야 할까요?

첫 번째 대응 직원은 인시던트를 해결하기 위해 필요한 모든 사람들입니다. 그러나 종종 인시던트를 해결하기 위해 다른 팀을 호출해야 하는 경우가 있습니다. 이를 가리켜 에스컬레이션이라고 합니다.

이 단계에 필요한 핵심 시스템은 OpsGenie와 같은 대기 직원 호출 및 알림 도구입니다. OpsGenie 또는 비슷한 시스템을 사용하면 대기 직원 명단을 정의할 수 있어, 특정 팀에서 긴급 상황 시 연락 가능한 순환 근무조를 지정해 둘 수 있습니다. 이는 항상 특정 개인에게 의존하는 것보다 훨씬 효율적입니다. 휴가를 갈 수도 있고, 직무를 변경할 수도 있고, 지나치게 자주 호출하는 경우 에너지가 소진될 수도 있기 때문에 특정 개인에게 항상 인시던트 대응을 맡기는 것은 바람직하지 않습니다. 또한, 대응 담당자를 명확하게 식별할 수 있으므로 '최선의 노력' 조건으로 대기하는 것보다 효율적입니다.

인시던트에 대한 호출 알림에 항상 인시던트의 Jira 이슈 키를 포함하세요. 알림을 받는 사람이 인시던트의 채팅방에 참여할 때 이 키가 필요합니다.

위임

다른 직원에게 인시던트를 에스컬레이션하고 이 직원이 온라인에 접속하면 IM은 그들에게 역할을 위임합니다. 위임받은 직원은 해당 역할에 필요한 사항을 이해한 후에 인시던트 팀의 일원으로 신속하고 효율적으로 작업할 수 있습니다.

Atlassian에서는 다음 역할을 사용하고 있습니다.

• 인시던트 관리자 - 개요 페이지의 설명을 참조하세요.
• 기술 리더 - 기술 관련 선임 대응 직원입니다. 문제와 그 이유에 대한 이론을 개발하고, 변경에 관한 의사결정을 수행하며, 기술팀을 운영하는 일을 담당합니다. IM과 긴밀하게 협업합니다.
• 커뮤니케이션 관리자 - 대중 커뮤니케이션에 능숙한 담당자로, 보통 고객 지원팀 또는 홍보팀에서 차출됩니다. 인시던트에 대한 내부 및 외부 커뮤니케이션을 작성하고 보내는 일을 담당합니다.

채팅방 주제를 통해 현재 누가 어떤 역할을 담당하는지 알릴 수 있으며, 인시던트 처리 중에 역할이 변경되면 채팅방 주제도 바로 업데이트합니다.

또한, IM은 인시던트에 필요하면 역할을 새로 생성하거나 위임할 수도 있습니다. 예를 들어, 여러 개의 작업 스트림을 진행하는 경우 기술 리더를 여러 명 지정하거나, 내부 및 외부 커뮤니케이션 관리자를 별도로 지정할 수 있습니다.

복잡하거나 규모가 큰 인시던트라면 IM 작업의 무결성을 지원하기 위해 자격을 갖춘 다른 인시던트 관리자를 지정하는 것이 좋습니다. 이렇게 지정한 인시던트 관리자는 특정 작업을 집중적으로 처리하여 일정을 준수하는 것과 같은 IM의 부담을 덜어줄 수 있습니다.

후속 커뮤니케이션 보내기

초기 커뮤니케이션을 보낸 후 인시던트 팀이 가동을 시작하면 인시던트와 관련된 직원과 고객에게 업데이트 소식을 알려주어야 합니다.

내부 직원에게 업데이트하는 것은 인시던트에 대해 공유되는 정보의 일관성을 유지하므로 중요합니다. 문제가 발생한 순간에는 문제에 관한 정보가 거의 부족하며, 특히 초기 단계에서는 더욱 그렇습니다. 무슨 문제가 발생했고 어떻게 대응하고 있는지 알려주는 신뢰할 수 있는 정보 출처를 설정하지 않으면 직원은 자체적으로 결론을 내리게 될 가능성이 높습니다.

내부 커뮤니케이션의 경우 Atlassian에서는 다음 패턴을 따르고 있습니다.

• 위에서 언급한 '초기 커뮤니케이션'에 설명된 대로 내부 Statuspage와 이메일을 통해 커뮤니케이션합니다.
• 인시던트 이름 및 이메일 주제 형식에 동일한 규칙을 사용합니다(<인시던트 이슈 키> - <심각도> - <인시던트 번호>).
• 현재 상태와 영향에 관해 한두 개의 문장으로 요약하는 것으로 시작합니다.
• '현재 상태' 섹션에는 2 ~ 4개의 글머리 기호를 사용합니다.
• '다음 단계' 섹션에도 2 ~ 4개의 글머리 기호를 사용합니다.
• 다음 번 커뮤니케이션을 언제, 어느 위치에서 보낼지 설명합니다.

Atlassian에서는 다음 확인 목록을 통해 커뮤니케이션의 완전성을 검토합니다.

• 고객에게 실제로 어떤 영향을 미치는가?
• 영향을 받는 내부 고객과 외부 고객의 수는 얼마나 되는가?
• 근본 원인을 파악했다면, 무엇인가?
• 복원을 위한 ETA가 있다면, 언제인가?
• 언제, 어느 위치에서 다음 번 업데이트를 수행할 것인가?

Atlassian은 불확실성을 줄이기 위해 인시던트 관리자가 내부 커뮤니케이션에서 알 수 없는 사항이 무엇인지 분명히 밝힐 것을 권장합니다. 예를 들어, 아직 근본 원인이 무엇인지 파악하지 못한 경우 그에 대한 언급을 생략하는 것보다는 "현재 근본 원인을 알 수 없습니다"라고 이야기하는 편이 훨씬 더 낫습니다.

외부 고객에게 업데이트 소식을 전달하는 것은 신뢰를 구축하는 데 도움이 되므로 매우 중요합니다. 인시던트의 영향을 받더라도 인시던트에 관련된 최신 정보의 업데이트가 전달되는 것을 아는 한 고객은 문제 없이 다른 일을 계속할 수 있습니다.

외부 커뮤니케이션에서는 이전에 Statuspage에서 연 인시던트를 업데이트하고 상태를 적절하게 전환하기만 하면 됩니다. 외부 고객은 인시던트의 기술적인 세부 사항에 관심이 없으므로, Atlassian은 업데이트를 '간결하고 긍정적으로' 전달하려고 합니다. 고객은 단지 인시던트가 아직 수정되지 않았는지, 그렇다면 언제쯤 수정되는지에만 관심이 있습니다. 보통 한두 개의 문장이면 충분합니다.

인시던트 커뮤니케이션은 복잡한 기술이며, 더 많이 경험할수록 더 능숙해질 것입니다. Atlassian은 인시던트 관리자 교육 중에 가상의 인시던트를 사용하여 역할극을 진행하고, 해당 인시던트의 커뮤니케이션 초안을 작성하고, 함께 교육받는 동료들 앞에서 발표하고 있습니다. 이는 실제로 업무를 수행하기 전에 관련 기술을 쌓을 수 있는 좋은 방법입니다.또한 직원과 고객에게 커뮤니케이션을 보내기 전에 다른 사람에게 사전 검토를 요청하고 '다른 의견'을 듣는 것도 좋은 방법입니다.

검토

모든 인시던트를 해결하는 하나의 규범이 되는 프로세스는 없습니다. 그런 프로세스가 있다면 해당 프로세스를 자동화하여 간단히 문제를 해결할 수 있었을 것입니다. 대신 Atlassian은 다양한 인시던트 대응 시나리오에 신속하게 대처하기 위해 다음 프로세스를 반복합니다.

• 일어나는 일을 관찰합니다. 관찰한 내용을 공유하고 확인합니다.
• 그 일이 발생한 이유에 대한 이론을 개발합니다.
• 이러한 이론이 옳은 것을 입증하거나 틀린 것을 입증하는 실험을 개발합니다. 실험을 실시합니다.
• 반복합니다.

예를 들어, 서비스에서 해당 지역의 인프라 제공자가 Statuspage에 게시한 결함에 상응하는 오류의 발생 비율이 높다는 사실을 알게 되었을 수 있습니다. 그러면 결함이 이 지역에서만 일어난다는 이론을 가정한 다음 다른 지역에서 장애 복구 작업을 수행하고 결과를 관찰해 볼 수 있습니다.

이때 IM의 가장 큰 과제는 다음과 같은 팀의 규율을 유지하는 것입니다.

• 팀이 효율적으로 커뮤니케이션하는가?
• 현재 관찰한 내용, 이론, 작업 스트림은 무엇인가?
• 효과적인 커뮤니케이션을 수행하는가?
• 계획적이고 신중하게 변경하는가? 수행하는 변경에 대해 우리가 실제로 알고 있는가?
• 역할이 분명한가? 각 개인이 맡은 일을 하고 있는가? 더 많은 팀에 에스컬레이션해야 하는가?

어떤 경우에도 당황하지 마세요. 이는 문제 해결에 도움이 되지 않습니다. 침착함을 유지하고 나머지 팀원이 이를 본받을 수 있게 하세요.

또한, IM은 팀의 피로도를 주시하고 팀의 업무 인계를 계획해야 합니다. 전담 팀을 운영하면 복잡한 인시던트를 해결할 때 에너지가 소진될 우려가 있습니다. IM은 팀원들이 얼마나 오랫동안 깨어 있는 상태인지, 얼마나 오랫동안 인시던트에 매달려 일하고 있는지 살펴보고 다음에 역할을 대신할 사람을 결정해야 합니다.

해결

현재 발생했거나 임박한 비즈니스 영향이 종료되면 인시던트가 해결된 것입니다. 해당 시점에 긴급 상황 대응이 종료되고 팀은 정리 작업 및 사후 검토 작업으로 전환합니다.

정리 작업은 인시던트의 Jira 이슈에서 이슈 링크 로 쉽게 연결하고 추적할 수 있습니다.

Atlassian에서는 Jira 커스텀 필드를 사용하여 모든 인시던트의 영향이 시작된 시간, 감지 시간, 영향이 종료된 시간을 추적합니다. 이러한 필드를 통해 복구까지 걸린 시간(TTR, 인시던트가 시작된 시간부터 종료된 시간까지)과 감지까지 걸린 시간(TTD, 인시던트가 시작된 시간부터 감지된 시간까지)을 계산합니다. 인시던트 TTD와 TTR의 배포는 중요한 비즈니스 지표로 자주 사용됩니다.

인시던트가 해결되면 최종 내부 및 외부 커뮤니케이션을 보냅니다. 내부 커뮤니케이션은 제출된 지원 사례 수 및 기타 중요한 인시던트 규모와 같은 인시던트의 영향 및 기간에 대한 개요를 포함해야 하며. 인시던트가 해결되었고 그에 관련된 추가 커뮤니케이션이 더 이상 전달되지 않음을 명시해야 합니다. 외부 커뮤니케이션은 보통 간략하게 작성하며, 고객에게 서비스가 복구되었고 사후 검토를 통한 후속 조치를 취할 예정임을 알리면 됩니다.

Jira Service Management가 알림 중앙 집중화 및 인시던트 커뮤니케이션 구성부터 근본 원인 분석을 위한 인시던트 사후 검토 실행으로 팀을 통합하여 더 나은 협업에 이르기까지 팀의 대응 프로세스의 각 단계를 지원하는 방법을 알아보려면 아래의 버튼을 클릭하세요.