인시던트 관리 4부: 해결 후 인시던트 분석 및 리포팅

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

이 문서의 4부에서는인시던트 대응 팀이 서비스 인시던트의 근본 원인 분석 및 해결을 포함하는 소급을 수행한 다음 소유권이 있는 엔지니어링 팀에 해결 항목을 배정하는 방법을 배우게 됩니다.

이러한 활동을 수행함으로써 Zendesk 고객 지원팀은 영향을 받는 고객과 사건 세부 정보 및 다음 단계를 공유할 수 있습니다.

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

서비스 인시던트 소급 수행하기
수정 항목 배정하기
서비스 인시던트 종료하기

서비스 인시던트 소급 수행하기

Zendesk는 인시던트의 원인, 인시던트가 고객에게 미치는 영향 및 인시던트를 완화하거나 해결하기 위해 취한 조치를 조사하고 문서화하기 위해 인시던트에 관련된 모든 팀원과 함께 성찰 연습을 실시합니다. 팀은 파악된 근본 원인과 사건의 재발을 방지하기 위한 후속 조치를 검토합니다. 이를 서비스 인시던트 내부 소급이라고 합니다. 인시던트 회고는 심각도가 높은 인시던트에 대해서만 공개적으로 공유됩니다.

모든 Zendesk 팀의 투명성과 포용성을 보장하기 위해 Zendesk 내부 소급 캘린더를 사용하여 내부 소급 회의에 참석하여 서비스 인시던트 및 근본 원인에 대한 자세한 정보를 얻을 수 있습니다. 인시던트의 결과는 모든 엔지니어링 팀과 공유되며 중요한 인시던트 결과는 강조 표시되어 Zendesk 주간 엔지니어링 미팅에서 검토됩니다.

서비스 인시던트 소급에서 수행되는 4가지 주요 활동은 다음과 같습니다.

인시던트 문서에 포함된 인시던트 세부 정보를 검토하여 참여자를 인시던트에 고정시키고 방향을 정하세요.
인시던트 문서에 포함된 근본 원인 분석 결과를 검토하고 검증합니다.
Zendesk 엔지니어링 팀이 서비스 인시던트를 유발하는 근본 원인을 완전히 해결하는 데 필요한 모든 수정 작업을 식별하고 분류합니다. 소급 참석자들의 합의로 모든 수정 항목에 동의합니다.
명확하고 적절한 SLA를 정의하여 적절한 엔지니어링 팀에 수정 작업을 배정합니다.

심각도가 높음 인시던트 분석

심각도가 높은 인시던트가 해결되면 인시던트 관리자가 다음을 포함하는 회고 회의를 예약합니다.

인시던트 대응에 참여한 모든 팀원
인시던트의 영향을 받은 제품 또는 서비스를 보유한 팀의 엔지니어
다음과 같은 소유권 또는 투자 이해관계가 있는 팀:

Zendesk 고객 지원팀
제품 팀
영향을 받는 제품, 서비스 및 지원 영역을 소유한 리더

회의 시간은 근본 원인의 복잡성과 여러 지역에 걸쳐 팀원의 가용성에 달려 있다는 사실을 이해하면서 인시던트 해결 후 72시간 이내에 인시던트 소급 회의를 개최하기 위해 모든 노력을 기울이고 있습니다.

인시던트 소급을 예약한 후 엔지니어링 소유자는 근본 원인 분석을 문서화하고 다음 카테고리에 따라 인시던트 문서를 만듭니다.

인시던트 개요
고객에게 미치는 영향
기술적 설명
근본 원인 및 서비스 정보
인시던트 세부 정보 및 타이밍
수정

인시던트 문서는 인시던트 소급을 안내하고 인시던트를 일으킨 근본적인 문제를 완전히 해결하기 위해 식별된 모든 수정 작업을 캡처합니다.

심각도가 0~3인 인시던트에 대해서는 근본 원인 분석이라는 추가적인 분석 단계가 수행됩니다. 이 분석을 통해 엔지니어링 팀은 인시던트를 이해하고 문서화하며 문제를 완전히 해결하는 데 필요한 작업을 정의할 수 있습니다. 이 정보는 인시던트 문서에 캡처됩니다.

Zendesk 인시던트 근본 원인 분석 프로세스

심각도가 낮음 인시던트 분석

심각도가 낮은 인시던트는 심각도가 높은 인시던트보다 근본 원인 및 리포팅 단계를 거칩니다. 심각도가 낮은 인시던트에 대해서는 제품 엔지니어링 소유자가 요청하지 않는 한 공식 인시던트 소급 회의가 완료되지 않지만 제품 엔지니어링 소유자가 인시던트 문서를 만듭니다.

근본 원인을 식별하여 분류하여 엔지니어링 팀과 공유하고, SLA와 함께 제품 엔지니어링 팀 백로그에 수정 항목을 추가합니다. 심각도가 높은 인시던트와 마찬가지로 Zendesk는 심각도가 낮은 인시던트를 철저히 조사한 결과 Zendesk의 엔지니어링 프로세스를 배우고 개선하고자 노력합니다.

심각도 3 인시던트는 고객에게 미미한 영향을 미치므로 문제 상태 및 확인된 해결 방법은 Zendesk 티켓을 통해 Zendesk 고객 지원팀을 통해 인시던트에 연락한 영향을 받는 고객과 공유됩니다.

정의상 심각도 4 인시던트는 고객에게 직접적인 영향을 미치지 않습니다. 인시던트 후 분석은 고객에게 전달되지 않지만 위에 설명된 프로세스와 절차를 사용하여 내부적으로 근본 원인을 파악하고 해결 방법을 해결합니다.

수정 항목 배정하기

수정 항목이 완료되었는지 확인하기 위해 제품 엔지니어링 팀은 소급하여 검증된 수정 항목을 검토하고 다음 작업을 수행합니다.

수정 조치를 예방 또는 일반으로 분류합니다.

예방 항목은 사건의 재발을 적극적으로 방지하는 항목입니다.
일반 항목은 그 자체로 예방적일 뿐만 아니라 인시던트 상황의 핵심 부분을 해결할 수 있습니다.
해결 우선 순위를 지정하여 응답 SLA를 설정합니다. 이 연습은 다음 활동을 통해 진행됩니다.

수정 항목 작업을 담당하는 엔지니어링 팀 파악
수정 항목을 해결하는 식별된 근본 원인에 연결
담당 엔지니어링 팀의 작업 백로그에 수정 항목 추가
엔지니어링 SLA 보고서에 수정 항목을 추가하여 SLA 달성 추적

다음은 제품 엔지니어링 팀이 작업 노력을 위해 수정 우선 순위를 정하고 계획하는 시기를 결정하는 데 사용하는 차트입니다.

Zendesk 수정 항목 우선 순위 SLA

회고전에 참석하는 Zendesk 고객 지원팀은 인시던트, 근본 원인 및 파악된 모든 해결 방법에 대한 고객 대면 설명을 작성합니다. 에 게시됩니다. 인시던트와 연결된 헬프 센터 문서입니다.

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

다음은 이 인시던트에 대해 인시던트 소급이 수행된 방식입니다.

인시던트 발생 후 업무일 기준 4일 후에 인시던트 대응 팀과 엔지니어들이 모여 인시던트를 검토하고, 근본 원인에 대해 협력하며, 해결 항목을 만들거나 업데이트했습니다. 모든 수정 항목은 회의 참석자들의 합의에 동의합니다.

인시던트에 관련된 각 사람이 인시던트 회고에서 역할을 수행했습니다.

회의에서 검토 및 논의된 세부 정보는 다음과 같습니다.

영역	예
일정	20:02 UTC - 업데이트된 인증서로 호스팅 서비스에 배포된 새 컨테이너 버전 20:08(UTC) - 컨테이너 연결 경고가 나타나기 시작함 20:37(UTC) - 서비스가 새 컨테이너에 연결할 수 없어 서비스 지연/중단이 발생했다는 첫 번째 증거 20:57(UTC) - Zendesk 내부 서비스가 요청 처리를 중지하여 POD 17에 호스팅된 Support, Guide 및 Talk 애플리케이션에서 시간 초과 오류가 발생함 21:02(UTC) - 클러스터 자동 확장 처리가 연결할 수 없는 서비스에 대한 새 컨테이너를 만들기 시작합니다. 21:07(UTC) - 기존 서비스 구성과 작동할 서비스 컨테이너의 전체 프로비저닝 완료 21:49 UTC - 연결할 수 없는 컨테이너 정리 완료 22:07 UTC - 인시던트가 완전히 해결됨
근본 원인	보안 인증서 서비스가 변경된 후 스크립트에 인코딩된 변경 내용을 적용하도록 컨테이너가 모두 다시 구축되지는 않았습니다. 재배포되지 않은 컨테이너가 올바른 보안 인증서 제공업체를 참조하지 않았으며 다른 Zendesk 서비스 및 컨테이너에서 신뢰하지 않았습니다.
영향을 미치는 요인	새 컨테이너를 만들 때 새 보안 인증서 제공업체를 제대로 참조하도록 배포 스크립트를 업데이트하지 않았습니다. 새 컨테이너를 너무 빠르고 광범위하게 배포하여 장애가 발생하기 시작한 후 조정할 수 없음 자동 롤백 기능 없음
수정	새 컨테이너를 구축하고 배포할 때 보안 인증서 규정 준수를 평가하는 방법 변경 새 인스턴스를 시작하기 전에 인증서를 확인하기 위한 보다 강력한 다른 방법 추가 수평적으로 확장되는 인프라를 위한 배포 전략 문서화 알림 발생 시 배포 자동 롤백 사용 플랫폼 엔지니어링이 인프라 구성 요소를 더 자주 재구축할 수 있는 방법 연구 중요한 인프라의 분산 및 내결함성을 어떻게 개선할 수 있는지 알아보세요.

철저한 분석을 통해 엔지니어링 팀이 구체적인 조치를 취할 수 있도록 모든 팀원이 인시던트를 자세히 설명하고 수정 작업을 개발하는 데 필요한 정보를 제공했습니다. 인시던트 대응 팀에서 모든 질문이나 문제를 해결한 후에는 인시던트 소급이 완료된 것으로 간주됩니다.

공개된 인시던트 소급을 담당하는 Zendesk 고객 지원팀 리드는 내부 소급 회의가 끝날 때 질문이 있거나 공개 문서를 만드는 데 팀으로부터 추가 정보가 필요한지 물었습니다. 그녀는 더 이상 묻지 않았고 의서비스 알림 섹션에 있는 공공 서비스 인시던트 문서에 아래의 소급 정보를 추가했습니다. 를 참조하세요.

서비스 가용성 VM 인시던트에 대한 공개 소급 정보

Zendesk 제품 및 서비스를 개선한 이 인시던트 회고의 3가지 중요한 결과는 다음과 같습니다.

인시던트의 근본 원인을 파악하여 모든 Zendesk 제품 팀이 향후 개발 과정에서 이를 고려할 것입니다.

수정 사항을 파악하여 SLA가 있는 엔지니어링 팀에 배정했습니다.

공개 회고록은 Zendesk 고객 지원팀에서 헬프 센터에 게시했으며 티켓을 제출한 영향을 받는 고객에게 발송되었습니다.

서비스 인시던트 종료하기

가장 좋은 방법은 Zendesk가 고객과의 모든 등록 티켓을 종료하여 모든 것이 적절하게 문서화되고 인시던트에 대해 소통되도록 하는 것입니다.

완료된 모든 서비스 인시던트는 주간 서비스 인시던트 요약 보고서에 요약되어 Zendesk 전체에서 공유됩니다. 인시던트 설명, 고객에게 미치는 영향 및 중요한 해결 방법이 이 보고서에 포함되어 있으며 Zendesk 경영진과 공유하는 격주 운영 검토 보고서에도 포함되어 있습니다.

소급 정보가 헬프 센터에 게시되고 등록 티켓이 소급 결과로 업데이트된 후에는 서비스 인시던트에 대한 분석 및 리포팅 단계가 완료된 것으로 간주됩니다. Zendesk 고객 지원팀은 그러한 티켓을 서비스 인시던트에 연결하여 종료로 표시합니다.

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

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