인시던트 관리 2부: Zendesk가 서비스 인시던트를 관리하는 방법

Zendesk의 인시던트 관리 개요2부입니다. 이 가이드는 다음 부분으로 구성되어 있습니다.

이 문서의 2부에서는Zendesk 팀은 심각도 수준에 따라 Zendesk 제품 내에서 서비스 인시던트에 대응합니다. Zendesk는 근본 원인에서 영향을 받는 고객에게 미치는 전체 영향에 이르기까지 사건을 이해하는 데 있어 포괄적인 접근 방식을 취하고 적절한 수준의 세부 정보를 전달합니다.

이 문서는 다음 섹션으로 구성되어 있습니다.

인시던트 심각도
인시던트 대응 팀 구조
사건에 대한 커뮤니케이션 타임라인
심각도가 낮음 인시던트 프로세스

인시던트 심각도

서비스 인시던트를 만들 때 내리는 주요 결정 중 하나는 인시던트의 심각도를 배정하는 것입니다. 인시던트의 심각도에 따라 어떤 Zendesk 팀에서 문제를 해결하는지, 그리고 영향을 받는 고객에게 문제를 전달하는 방법이 결정됩니다.

Zendesk는 인시던트의 특성에 따라 서비스 인시던트를 5가지 심각도 수준으로 그룹화하는 시스템을 사용합니다.

Zendesk 심각도 평가 시스템

서로 다른 에스컬레이션 경로와 팀이 참여하여 심각도 수준에 따라 인시던트를 조사하고, 소통하며, 해결합니다. 이로써 각 사건에 대해 올바른 수준의 엄격함이 보장됩니다. 아래 다이어그램은 심각도 수준에 따라 인시던트가 해결되는 동안과 해결된 후에 일어나는 주요 활동을 설명합니다.

심각도 수준별 프로세스

심각도가 높은 인시던트는 엄격한 분석 및 수정 활동을 거치지만 모든 인시던트는 심각도 수준에 관계없이 실시간 대응 및 조사 프로세스를 거칩니다. 이로써 다음이 생성됩니다.

인시던트가 공개될 때Zendesk 상태 페이지업데이트
근본 원인 분석 및 인시던트 해결
Zendesk(내부) 인시던트 보고서

Zendesk 서비스 가용성 인시던트 예

다음은 Zendesk에서 인시던트 심각도를 설정하는 방식과 Zendesk 팀이 내부적으로 대응하는 방식의 예입니다.

인시던트 검색 및 대응 예

이 예에서는 다음과 같은 워크플로우를 볼 수 있습니다.

Zendesk 네트워크 운영 센터(ZNOC)에서 문제를 확인했습니다.시스템 알림에서 Pod 17의 서비스 노드에 요청이 도달할 수 없다고 표시했을 때입니다. Zendesk 네트워크 엔지니어링 팀은 액세스 문제가 고객 서비스에 직접 영향을 미치는 것을 확인한 후 여러 고객을 위한 Support, Guide 및 Talk 서비스가 예상대로 작동하지 않는다는 사실을 빨리 깨달았습니다. 새 Zendesk 서비스 인시던트를 만들었습니다.
이 사건은 처음 만들어졌을 때 두 명의 고객에게 영향을 미치는 것으로 알려졌지만 서비스 중단의 특성으로 인해 더 많은 고객이 문제를 경험했고 Zendesk 고객 지원팀에 문제를 제기하기 시작했습니다. 엔지니어링 팀은 이 사건에 즉각적인 주의가 필요한 우선 순위가 높은 사건인 1의 심각도를 배정했습니다.
인시던트 응답 대기 팀은 즉시 호출됩니다. 인시던트를 만든 후 몇 분 내에 인시던트 관리자는 서비스 인시던트 문제를 해결하기 위해 정보를 수집하고 추가적인 엔지니어링 리소스를 수집했습니다.

인시던트 대응 팀 구조

Zendesk는 전담 글로벌 인시던트 대응 팀을 갖추고 있어 모든 인시던트가 서비스 인시던트 관리 프로세스를 통해 진행되고 보장되는 경우 Zendesk 경영진의 적절한 수준에 에스컬레이션되도록 보장합니다.

인시던트 관리 역할 및 책임

이러한 팀 구조를 통해 Zendesk는 기술 리소스로 인시던트를 철저히 분석하고 Zendesk 고객 지원을 통해 고객과 실시간으로 소통할 수 있습니다.

사건에 대한 커뮤니케이션 타임라인

Zendesk는 고객에게 적절한 시간 내에 인시던트를 적절하게 전달하고 해결하기 위해 최선을 다하고 있습니다. 인시던트 세부 정보 배포를 위한 내부 일정을 수립했습니다. 타임라인은 인시던트의 심각도 수준과 서비스 인시던트 관리 단계를 기준으로 합니다.

단계	응답 타임라인
공개 공지	인시던트 호출 후 15분 이내
인시던트 업데이트	서비스가 복원될 때까지 또는 새 정보가 제공될 때까지 30분마다
이벤트 분석 (심각도 0 및 1 인시던트의 경우)	인시던트 해결 후 48시간 이내
근본 원인 분석	인시던트 해결 후 72시간 이내
공개 인시던트 소급	인시던트 해결 후 96시간 이상

심각도 평점이 0 - 2인 인시던트는 높음으로 간주됩니다.수 있습니다. 심각도가 높은 인시던트가 발생하면 글로벌 대기 중인 인시던트 대응 팀이 연중무휴로 인시던트에 대응할 수 있습니다. 팀은 다음과 같은 역할로 구성됩니다.

인시던트 대응 팀 역할

글로벌 인시던트 대응 팀 위치

대기 중인 팀이 호출을 받으면 인시던트가 선언된 후 분 이내에 인시던트 진단이 시작됩니다. Slack 채널과 Zoom 통화가 만들어지므로 대응 팀이 실시간으로 소통할 수 있습니다. 인시던트 대응 팀이 인시던트를 선별하고 범위를 지정할 때 어떤 제품 및 서비스가 영향을 받는지에 따라 대기 엔지니어링 팀에 호출됩니다.

Zendesk 상태 페이지의 공개 게시물인시던트 생성 후 15분 이내에 고객에게 알려진 인시던트에 대한 정보를 제공합니다. 그 이후에는 새 정보가 제공되어 문제가 해결될 때까지 30분마다 업데이트가 게시됩니다. 문제 및 식별되는 새 정보의 양에 따라 필요에 따라 이 주기를 줄이거나 늘릴 수 있습니다. 고객은 Zendesk 상태 페이지에서 활성 서비스 인시던트를 모니터링할 수 있습니다. 자세한 내용은 이 가이드의 3부 문서를 참조하세요.

Zendesk는 글로벌 온콜 인시던트 대응 팀 외에도 리더십 알림 및 에스컬레이션을 위한 프로세스를 확립했습니다. 심각도가 높은 인시던트가 특정 기준에 부합하는 경우에는 다음 수준의 대응인 위기 관리를 사용 설정합니다.

Zendesk 서비스 가용성 인시던트 예 계속

서비스 가용성 인시던트 를 예로 들면 다음과 같습니다. Zendesk의 인시던트 관리 프로세스를 통해 인시던트 응답이 진행되었습니다.

스크린샷

서비스 가용성 인시던트 응답 타임라인

예에서 볼 수 있듯이 Zendesk 인시던트 포털에서 인시던트가 만들어지고 나면 다음과 같은 일련의 자동화된 작업이 수행됩니다.

인시던트 대응 대기 팀이 인시던트에 응답하기 위해 호출되었습니다.

인시던트 Slack 채널이 자동으로 만들어지고 인시던트 응답 대기 팀이 전용 Slack 채널에 추가되었습니다.

Zoom 통화가 자동으로 시작되어 모든 응답자가 참여할 수 있도록 Slack 채널에 게시됨

사건을 문서화하고 진행 상황을 Zendesk와 내부적으로 공유하기 위해 이벤트 요약 문서가 자동으로 만들어졌습니다.

Zoom 통화에서 사건 관리자는 초기 심각도를 확인하고 문제의 범위와 영향을 확인했습니다.

Pod 17의 여러 컨테이너 노드에 액세스할 수 없고 Support, Guide 및 Talk 제품을 포함한 종속 서비스에서 사용할 수 없다는 것이 신속하게 확인되었습니다. 특히 한 노드 유형에는 다른 POD에 사용 가능한 복제본이 없었습니다. 이로 인해 이러한 제품이 여러 고객에게 응답하지 않을 수 있습니다.

ZNOC는 해당 네트워크 엔지니어링 팀을 Zoom 통화에 연결하여 고객에 대한 서비스 및 API 액세스를 복원하는 즉각적인 문제를 해결하는 방법을 조사하기 시작했습니다. 에지 엔지니어링 SME도 호출되어 통화에 참여했습니다. 5분 내에 수정 사항을 파악하여 배포하여 영향을 받는 노드가 API 호출 및 서비스에 다시 액세스할 수 있도록 했습니다.

Zendesk 고객 지원팀에서 고객 보고서를 추적하기 위해 문제 티켓을 만들었습니다. 이 티켓은 새 보고서가 들어올 때 신속하게 추가될 수 있도록 인시던트 Slack 채널에 추가되었습니다.

조사가 계속 진행되는 동안 인시던트 에스컬레이션 관리자는 인시던트 생성 12분 후 첫 번째 공개 업데이트를 만들어 Zendesk 상태 페이지에 게시했습니다.

Zendesk 시스템 상태 페이지의 첫 번째 서비스 가용성 인시던트 게시

팀이 인시던트를 조사하는 동안 접수된 고객 보고서는 인시던트와 관련된 주요 문제 티켓에 연결되었습니다. 이로써 인시던트 대응 팀이 공개 알림을 보낼 때 영향을 받는 모든 고객에게 업데이트를 보낼 수 있었습니다.

네트워크 엔지니어링 팀은 인증서 생성 및 사용 방법의 변경이 사건의 원인이라고 판단하여 영향을 받는 고객에게 서비스를 복원하기 위해 다음과 같은 조치를 취했습니다.

연결할 수 없는 노드를 비활성화했습니다.

올바르게 참조된 인증서로 새 서비스 노드를 만들었습니다.

서비스에 대해 그리고 API 호출을 통해 새 서비스 노드에 액세스할 수 있는지 확인했습니다.

수신 요청이 이제 적절하게 처리되고 있는지 확인하기 위해 수신 트래픽을 모니터링했습니다.

인시던트가 진행됨에 따라 두 가지 공개 업데이트가 더 이루어졌습니다. 하나는 인시던트를 만든 지 14분 후, 다른 하나는 인시던트를 만든 후 63분입니다. 게시된 인시던트 소급 정보와 함께 공개 커뮤니케이션 기록은서비스 알림 페이지 에서 확인할 수 있습니다.을(를) 참조하세요.

예에 표시된 대로 심각도가 높은 인시던트는 제품 엔지니어링 팀이 인시던트를 일으킨 근본적인 문제를 해결할 수 있도록 근본 원인을 파악하고 수정 항목을 만드는 엄격한 프로세스를 거칩니다. 이 분석은 인시던트 회고 중에 이루어지며 자세한 내용은 해결 후 인시던트 분석 섹션.

심각도가 낮음 인시던트 프로세스

심각도가 낮은 서비스 인시던트(레벨 3~4)는 더 적은 수의 고객에게 영향을 미치고 그러한 고객이 Zendesk 제품의 비즈니스 크리티컬 기능을 사용하는 것을 방해하지 않으므로 덜 중요합니다. 이러한 인시던트는 위의 가이드라인에 따라 해결되지만 공개 채널에 게시되지는 않습니다.

심각도 3 인시던트는 심각도 0-2 인시던트와 거의 동일한 방식으로 처리됩니다. 비즈니스에 미치는 영향 감소로 인해 예상 응답 시간이 연장됩니다. 대기 팀이 호출되지 않더라도 이러한 인시던트는 지원 제품 엔지니어링 팀과 연결된 특정 Zendesk 인시던트 Slack 채널을 통해 처리되며 팀은 심각도가 높은 인시던트만큼 신속하게 응답하는 경향이 있습니다. 대부분의 심각도 3 인시던트는 공개 커뮤니케이션 채널을 사용하지 않습니다. 대신 Zendesk 고객 지원팀은 일부 고객으로부터 특정 조치가 필요한 경우 사전대응 알림을 통해 고객에게 연락합니다.

심각도 4 인시던트는 고객의 Zendesk 서비스 사용에 직접적인 영향을 미치지 않지만 해결되지 않을 경우 영향을 미칠 가능성이 있습니다. 이러한 인시던트는 잠재적인 문제에 대한 사전대응 대응으로 만들어집니다. 제품 엔지니어링 팀은 심각도 3 프로세스와 동일한 방식으로 참여합니다.

자세히 알아보기

이로써 Zendesk의 인시던트 관리 개요의2부, Zendesk가 서비스 인시던트를 관리하는 방법을 마쳤습니다.

자세히 알아보려면 이 가이드의 다음 부분으로 이동하세요. 3부: 공개 Zendesk 서비스 인시던트 모니터링하기.

번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.

번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.