인시던트 커뮤니케이션 모범 사례

IT 및 Ops 분야에서 인시던트는 항상 피할 수 없는 현실이었습니다. 오늘날 DevOps 및 고객 지원 팀도 인시던트 커뮤니케이션에 대한 집중 교육을 받고 있습니다.

인시던트 커뮤니케이션이란 서비스에 어떠한 유형의 중단 또는 성능 저하가 발생하고 있음을 사용자에게 알리는 프로세스입니다. 특히 연중무휴 24시간 가용성이 기대되는 웹 및 소프트웨어 서비스에서 중요합니다.

웹 규모의 인시던트 커뮤니케이션은 단순히 대량 이메일을 보내는 것보다 더 복잡합니다. 고려해야 할 대상과 메시징 및 대응 기대치에 대한 임계값이 다양합니다.

일부 가동 중지 시간은 불가피하게 발생하므로 미리 계획하고 팀이 준비되어 있는지 확인하는 것이 가장 좋습니다.

이 가이드는 인시던트 커뮤니케이션 모범 사례에 대한 가이드입니다. 다음 내용을 다룰 것입니다.

• 인시던트 커뮤니케이션이 중요한 이유

• 인시던트 커뮤니케이션을 준비하는 방법

• 인시던트 커뮤니케이션 전문가가 작업을 처리하는 방법

• 인시던트 발생 후 인시던트 커뮤니케이션이 끝나지 않는 이유

인시던트 커뮤니케이션: 누가 관심을 가집니까?

여러분의 고객과 동료가 중요하게 생각합니다. 따라서 관심을 가져야 합니다. 제대로 처리하지 않은 가동 중지 시간은 고객과 팀에게 상당히 나쁜 경험이 될 수 있으며 수익에도 영향을 미칠 수 있습니다. 일부 고객은 앞으로 더 좋지 않은 경험을 하게 될까 봐 걱정하며 경쟁업체로 떠날 수 있습니다. 결국 신뢰 부족으로 인해 미래 고객을 잃게 될 것입니다. 팀 사기는 떨어지고 생산성이 저하될 수 있으며, 입소문을 탄 긍정적인 추천도 사라지게 됩니다.

다행히 예기치 않은 가동 중지 시간이 고객 서비스의 악몽으로 이어질 필요는 없습니다. 고객과 소통하며 무슨 일이 일어나고 있는지, 문제 해결을 위해 무엇을 하고 있는지 꾸준히 전달하면 고객은 전체적인 상황을 이해하고 훨씬 덜 부정적인 반응을 보일 것입니다.

인시던트 커뮤니케이션 준비

적절한 준비는 성과 저하를 방지합니다. 이것이 전투에 임할 때 적절한 슬로건이라면 인시던트 커뮤니케이션 전략에도 적합합니다. 인시던트가 한창 진행 중일 때 인시던트 커뮤니케이션에 시간을 할애했다는 사실에 나중에는 스스로에게 고마울 것입니다.

인시던트로 간주하는 항목 정의

인시던트를 전달하기 전에 인시던트를 구성하는 요소부터 결정해야 합니다. 많은 웹 회사는 표준화된 4개 티어 심각도 정의 시스템을 사용합니다. 다음은 Atlassian의 자체적인 인시던트 핸드북에 담긴 심각도 정의에 대한 유익한 가이드입니다.

인시던트 심각도에 대한 임계값이 무엇이든 명확한 경계를 정하는 것이 중요합니다(이상적으로는 측정 가능한 메트릭을 중심으로). 인시던트를 심각도 1로 지정하는 경우 모든 팀원이 그 의미를 정확히 알 수 있어야 합니다.

심각도 시스템은 가동 중지 시간에 불가피하게 따라오는 부정적인 상황을 제거하는 데도 유용합니다.

어떤 시스템을 사용하든 보안 문제 또는 데이터 손실과 관련된 모든 인시던트에 대해 무관용 커뮤니케이션 계획을 사용하도록 권장합니다.

커뮤니케이션 솔루션, 채널 및 메시지 템플릿 미리 선택

전문 지원 팀과 사이트 신뢰성 엔지니어는 어떤 채널을 통해 커뮤니케이션할지 즉석에서 결정하지 않습니다. 그들은 미리 계획을 세웁니다.

인시던트 커뮤니케이션을 위한 6가지 주요 커뮤니케이션 채널이 있습니다.

• 전용 상태 페이지

• 포함된 상태

• 이메일

• 사내 채팅 도구

• 소셜 미디어

• SMS

전용 상태 페이지

팀은 전용 상태 페이지를 주요 인시던트 커뮤니케이션 솔루션으로 사용하는 것이 좋습니다. 직접 구축하든 Statuspage와 같은 호스팅 솔루션을 사용하든 인시던트 발생 시 고객과 동료에게 명확한 정보 출처를 제공하는 것이 중요합니다. Statuspage는 사용자에게 업데이트가 게시되는 즉시 확인할 수 있는 구독 옵션도 제공합니다. 따라서 문제를 해결하느라 바쁜 팀의 지원 부담이 줄어듭니다.

포함된 상태

또한 Statuspage를 사용하면 고객이 운영하는 모든 웹사이트에 상태 정보를 직접 손쉽게 포함시킬 수 있습니다. 대부분의 방문자는 상태 페이지를 찾기 전에 제공업체의 홈페이지 또는 지원 페이지를 확인할 가능성이 높습니다. 포함된 위젯(여기 예시)을 사용하면 인시던트가 진행 중인지 여부를 방문자에게 쉽게 알릴 수 있습니다. 방문자는 위젯을 클릭하여 상태 페이지로 이동할 수도 있습니다.

이메일

Statuspage 같은 제품의 이메일 업데이트를 원하는 대로 구독할 수 있는 옵션을 고객에게 제공할 수 있습니다. 이메일 도구에서 직접 보내든, 상태 페이지를 사용하여 이메일 전송을 트리거하든 인시던트 커뮤니케이션을 위해 신뢰할 수 있는 채널로 이메일을 보내세요.

채팅 도구

Jira Service Management 채팅을 사용하면 직원과 에이전트를 위해 컨텍스트 전환과 정보의 격차를 줄일 수 있습니다. Jira Service Management 채팅은 Slack 또는 Microsoft Teams의 대화와 티켓을 동기화합니다. 널리 사용되는 채팅 도구와 지원 간의 원활한 대화를 통해 문제에 대한 강력한 컨텍스트를 제공하여 문제를 신속하게 해결할 수 있습니다.

소셜 미디어

많은 팀이 인시던트 발생 시 Twitter와 같은 소셜 채널을 커뮤니케이션 수단으로 사용합니다. 이것을 전략 일부로 사용하는 것은 좋지만 유일한 커뮤니케이션 수단으로 의존해서는 안 됩니다.

SMS

SMS 메시지 또는 문자 메시지 수신은 종종 상대에게 연락할 수 있는 보다 즉각적인 방법이며, 가동 중지 시간 공지와 같이 중요한 인바운드 알림에 있어서 많이 선호되는 옵션입니다. 반면 메시지에 매우 빠르게 피로를 느낄 수 있으며 관련 없는 메시지가 너무 많으면 구독을 취소하는 채널이기도 합니다.

인시던트 커뮤니케이션에서 만병통치약 같은 채널은 없습니다. 모든 채널은 서로 다른 강점을 지녔으며 함께 사용될 때 진정한 힘을 발휘합니다. 예를 들어, Atlassian에서는 인시던트를 상태 페이지에 게시하지만 Twitter에도 업데이트를 푸시합니다. 인시던트에 대한 공지 사항은 Jira Service Management 포털에서도 확인할 수 있습니다. 그런 다음 메시지는 인시던트에 대한 자세한 내용을 볼 수 있는 상태 페이지로 사용자를 다시 안내합니다. Jira Service Management에서 인시던트를 관리하면 오해가 쌓이거나 번역에 대한 고객의 신뢰를 잃지 않고 여러 커뮤니케이션 지점을 활용할 수 있습니다.

적절한 대상에 맞게 알림 및 커뮤니케이션 조정

인시던트가 발생할 경우 고객 서비스의 악몽 및/또는 커뮤니케이션 실패를 방지하기 위해 가능한 최소한의 마찰과 리소스로 커뮤니케이션할 대상, 연락 방법 및 해결 방법을 알아야 합니다. 즉각적인 대응 팀에서 내부적으로 시작하여 외부로 작업해 나가며 적절한 대상을 위한 메시지를 선별하는 것이 가장 좋습니다.

조직마다 다르지만 일반적으로 커뮤니케이션이 필요한 대상을 다음과 같은 5가지 개별 그룹으로 생각하면 도움이 됩니다.

1. 핵심 대기 중 팀: 영향을 받는 거의 즉시(일반적으로 모니터링 및 알림 도구를 통해) 문제를 가장 먼저 알게 되는 그룹입니다. 내부 팀은 보이지 않는 곳에서 협업 커뮤니케이션 도구를 사용하여 인시던트를 감지하고, 협력하여 작업하며 상황을 파악하고 해결합니다.

2. 전면 지원 팀: 인시던트 중에 고객의 질문에 직접 답변하고 고객에게 업데이트를 제공하는 그룹입니다. 매우 중요한 역할이므로 이 팀은 최종 사용자에게 전달할 정확한 정보를 확보해야 합니다.

3. 관리자 및 경영진: 핵심 팀은 이 그룹과의 커뮤니케이션을 통해 무슨 일이 일어나고 있는지, 다음 두 그룹에 어떤 잠재적 영향을 미칠지, 상황이 얼마나 오래 지속될 수 있는지에 대한 추정치를 알려야 합니다.

4. 일반 직원: 직원은 사용하는 서비스가 중단되고 복구됨에 따라 계속 정보를 얻어야 합니다. 이러한 사용자와 사전에 커뮤니케이션하면 “현재 상태”에 대한 질문과 중복되는 IT 지원 티켓이 줄어들며, 당면한 문제 해결에 더 집중할 수 있습니다.

5. 외부 고객: 인시던트가 외부 고객에게 영향을 미치는 경우 문제를 설명하고 해결이 예상되는 시기 또는 최소 몇 시간마다 업데이트하겠다는 내용을 전달해야 합니다. 현재 고객의 제품 사용에 여전히 영향을 미치는 문제의 경우 최소 1시간 안에는 계속 업데이트하는 것이 좋습니다. 또한 다음 업데이트가 예상되는 시기도 항상 명시해야 합니다. 특히 보안 또는 데이터 손실과 관련된 심각한 인시던트인 경우 외부 커뮤니케이션을 신속하게 처리하고 필요한 다른 팀(법무, HR, 보안 팀 등)을 참여시키는 것이 좋습니다.

인시던트 및 서비스 중단 커뮤니케이션을 위한 템플릿 설정

인시던트가 발생했을 때는 인시던트 공지를 어떤 말로 표현할지 고민하고 싶지 않을 것입니다. 인시던트를 잘못된 방식으로 표현하면 팀의 대응 프로세스를 비판할 이유를 찾는 기술 팀 이외의 관리자에게 완벽한 공격 대상이 됩니다.

공통 언어를 미리 결정하고 관리자의 승인을 받아 템플릿에 저장합니다. 그러면 관련 세부 정보를 쉽게 연결하고 인시던트를 당일에 해결할 수 있습니다.

다음은 Atlassian의 자체 상태 페이지에 사용하는 2가지 인시던트 템플릿입니다.

• 사이트에 현재 평소보다 많은 양의 로드가 발생하고 있으며, 이로 인해 페이지가 느려지거나 응답하지 않을 수 있습니다. 원인을 조사하고 있으며 가능한 한 빨리 업데이트를 제공하겠습니다.

• 공개 메트릭 데이터용 스토리지 제공업체에서 현재 인프라 문제를 겪고 있습니다. 상황이 나아지거나 정보가 제공되면 업데이트해 드리겠습니다.

전문가처럼 커뮤니케이션 관리

인시던트의 수명 주기에는 여러 연락 지점이 포함될 수 있습니다. 원활하게 처리된 인시던트에는 최초 연락, 인시던트 중 업데이트, 해결 및 사후 검토라는 익숙한 3가지 작업 구조가 있습니다.

프롤로그: 중앙 집중식 내부 팀 커뮤니케이션

무엇보다 인시던트 백엔드의 내부 팀은 확립된 커뮤니케이션 플랫폼을 갖추고 문제 발생 시 협력하여 작업할 준비가 되어 있어야 합니다. 

모니터링, 로깅 및 CI/CD 도구 전반에서 알림을 중앙 집중화 및 필터링하면 팀이 신속하게 대응할 수 있습니다. Jira Service Management와 같은 플랫폼을 통해 팀은 인시던트에 대해 협력하고, 컨텍스트를 얻으며, 인시던트가 지속되는 동안 소통을 유지할 수 있습니다.

파트 1: 최초 연락

초기 업데이트는 가장 중요합니다. 말하는 내용부터 말하는 방법과 시기에 이르는 모든 것이 팀의 대응이 어떻게 받아들여질지 결정합니다. 따라서 템플릿을 미리 설정해두면 큰 도움이 됩니다.

목표는 문제를 신속하게 인정하고, 알려진 영향을 간략하게 요약하며, 추가 업데이트를 약속하고, 가능한 경우 보안 또는 데이터 손실에 대한 우려를 완화하는 것입니다. 아직 정확한 세부 정보를 알지 못하더라도 문제가 있음을 인정하는 것이 중요합니다.

파트 2: 인시던트 중 정기적인 업데이트

인시던트 중 커뮤니케이션은 매우 중요합니다.

Google의 SRE 팀은 인시던트 발생 시 감독해야 할 주요 역할 중 하나로 커뮤니케이션 리더를 꼽았습니다.

Google의 책 “사이트 신뢰성 엔지니어링”에 따르면 커뮤니케이션 리더의 역할은 다음과 같습니다.

“커뮤니케이션 리더는 인시던트 대응 태스크포스를 대표하는 얼굴입니다. 이들의 임무는 인시던트 대응 팀 및 이해 관계자에게 정기적인 업데이트(보통 이메일을 통해)를 제공하는 것이 포함되며, 인시던트 문서를 정확하고 최신 상태로 유지하는 작업 등으로 확대될 수 있습니다.”

또한 커뮤니케이션 리더는 상황이 변경됨에 따라 상태 페이지를 계속 업데이트하거나 다른 채널에 업데이트를 게시하는 일도 담당합니다. “우리는 여전히 문제를 해결하고 있으며 새롭게 보고할 사항은 없습니다”라는 업데이트라도 아무 말도 없이 고객과 관계자를 기다리게 하는 것보다는 낫습니다. 영문을 모르는 관계자들은 최악의 상황을 예상하기 시작합니다.

영향을 받는 사용자 및 기타 이해 관계자와의 커뮤니케이션은 필수입니다. 사전에 정한 채널을 사용하여 사용자에게 진행 상황을 알리세요. 홈페이지에서는 Statuspage 알림을 통해 고객에게 팀이 문제를 인지하고 있음을 알릴 수 있으며 에이전트가 중복된 문의를 처리하는 데 드는 시간을 절약할 수 있습니다. SMS, 이메일 및 모바일 푸시 알림 등의 여러 알림 채널을 통해 고객과 모든 정보를 공유하세요. 

어떤 도구를 사용하든 하나의 도구를 주요 커뮤니케이션 수단으로 식별하고, 다른 채널의 모든 관계자를 해당 도구로 모으는 것이 좋습니다. Jira Service Management를 통해 인시던트 커뮤니케이션을 관리하면 올바른 메시지를 적절한 대상에게 전달할 수 있습니다.

파트 3: 해결, 사후 검토, 다음 단계

2010년 Facebook은 역대 최대의 서비스 중단을 겪었습니다. 당시 기준 사용자 5억 명 중 수백만 명이 약 2시간 30분 동안 소셜 네트워크를 사용할 수 없었습니다.

Facebook은 사용자가 폭발적으로 증가하는 초기 단계에 있었으며, 여전히 비즈니스 세계에서 서비스가 광고 가치가 있음을 증명하느라 바쁘던 급성장하는 기술 대기업 입장에서는 최악의 타이밍이었습니다.

문제가 해결됐을 때 Facebook 엔지니어는 회사 엔지니어링 블로그에 인시던트에 대한 요약글을 395단어로 정리하여 게시했습니다.

블로그 글:

오늘 이른 아침 Facebook은 약 2시간 30분 동안 서비스가 중단되어 많은 사용자가 접속할 수 없었습니다. 4년 넘는 기간 중 겪은 최악의 서비스 중단 사태였으며, 우선 사과의 말씀을 드리고 싶습니다. 또한 벌어진 상황에 대한 훨씬 더 기술적인 세부 정보를 제공하고 이를 통해 얻은 한 가지 큰 교훈을 공유하고 싶었습니다.

사후 검토의 개요는 간단합니다.

• 문제 인정, 영향을 받은 사람들에게 공감 및 사과

• 무엇이 왜 잘못되었는지 설명

• 인시던트를 해결하기 위해 수행한 작업 및 인시던트의 반복을 방지하기 위해 수행한 작업 설명

• 인정하고, 공감하며, 다시 한번 사과

이 커뮤니케이션에서는 화려한 언어나 거창한 말은 필요 없습니다. 단순하고 직설적으로 전달하세요. 예를 들어, Facebook에서 작성한 블로그 글은 다음과 같습니다.

사이트 중단에 대해 다시 한번 사과드립니다. 당사는 Facebook의 성능과 안정성을 매우 중요하게 생각한다는 사실을 알아주시기 바랍니다.

위와 같은 언어를 사용하면 고객과 동료는 여러분이 수준 높은 팀을 운영하며 계속 주의를 기울이고 있음을 쉽게 신뢰할 수 있습니다. 더 많은 아이디어를 보려면 Atlassian의 인시던트 대응 사후 검토 템플릿을 확인하세요.

상시 가동 서비스를 운영하다 보면 현실적으로 예기치 못한 문제가 발생합니다. 가동 중지 시간 동안 효과적으로 커뮤니케이션하면 동료 및 고객 모두와 신뢰를 쌓을 수 있습니다. 원활한 대응이 큰 차이를 만들 수 있습니다. Atlassian에서는 인시던트 발생 시 효과적인 커뮤니케이션을 빠르게 작성하는 데 도움이 되는 간단한 도구도 만들었습니다.