좋은 인시던트 후 검토의 특징 및 구성 요소

이제 인시던트 후 검토가 무엇인지, 인시던트 대응 프로세스에서의 역할 및 수행해야 하는 시기를 알 수 있습니다. 이 단원에서는 인시던트 후 검토를 가장 효과적으로 만드는 요소에 대한 세부 정보를 좀 더 자세히 살펴보겠습니다.

인시던트가 다르기 때문에 인시던트 후 리뷰의 정확한 구성도 다를 수 있습니다. 그러나 프로세스를 수행하기 위한 견고한 기반을 제공할 수 있는 좋은 검토의 몇 가지 일반적인 특성과 구성 요소가 있습니다.

그것이 아닌 것

인시던트 후 검토에 적합한 특성을 이해하기 전에, 우선 어떤 점이 그렇지 않은지 고려해야 합니다 .

• 문서나 보고서가 아닙니다. "검토"를 서면 요약으로 쉽게 생각할 수 있으며 실제로 요약 보고서는 종종 인시던트 후 검토를 따릅니다. 그러나 이러한 부분은 인시던트 응답 수명 주기의 분석 단계에서 서로 다르고 고유한 두 부분입니다.
• 그것은 인과 관계의 결정이 아닙니다. 검토는 실패에 기여한 요인을 살펴보지만, 목적은 범인을 정확히 찾아내는 것이 아닙니다(특히 단일 근본 원인은 아니며, 복잡한 시스템은 거의 항상 전체 기여 요인 집합으로 인해 실패함). 학습하고 개선할 수 있도록 인시던트의 모든 측면에 대한 정보를 생각하고 공유하는 것입니다. 작업 항목 목록이 아닙니다. 검토에서 학습한 내용의 결과로 이러한 목록이 표시될 수 있지만 이는 포커스가 아닙니다. 티켓 큐나 버그 보고 시스템에서 항목 목록을 얻지 못하더라도, 시스템에 대해 이전보다 더 많이 이해하게 되었다면, 그 검토는 성공적이었습니다.

인시던트 검토는 무엇보다도 대화입니다. 이 공간은 팀이 당시에 알고 있는 내용과 현재 알고 있는 내용을 검토하고, 인적 부품을 포함한 시스템 부분이 문제에 대응하여 함께 작동하거나 작동하지 않는 방식을 탐색하고 더 잘 이해할 수 있는 정의된 공간입니다.

특성 및 구성 요소

마지막 단원에서 언급했듯이 인시던트 검토는 흠이 없습니다. 시스템의 인적 부분이 어떻게 상호 작용하는지 검토해야 하지만 누구에게도 "잘못"이라는 레이블을 지정하기 위해 이 작업을 수행하지 않습니다. 초점은 기술의 실패와 프로세스에 있어야합니다, 하지 사람들의.

예를 들어 이를 반영하도록 질문을 구성합니다.

• 키보드의 사람에게 올바른 결정을 내리는 데 필요한 컨텍스트를 제공하지 못한 모니터링의 적자는 무엇이었습니까?
• 도구에 "전체 데이터베이스 삭제" 옵션이 있는 이유는 무엇인가요?
• 또는 더 나은 아직: 이 함수를 수행하기 전에 도구에서 확인을 요청하지 않은 이유는 무엇인가요?

상황이 잘못되면 손가락을 가리키려는 유혹이 있을 수 있습니다. 그러나 다음 핵심 사항을 기억해야 합니다.

사람들을 해고해서는 안정성을 확보할 수 없습니다.

부끄러움과 비난 또는 "책임이있는"사람을 찾고 해고하기위한 조사는 더 신뢰할 수있는 시스템으로 이어지지 않습니다. 대신, 그것은 경험이 없거나 심지어 빈 운영 팀과 행동을 두려워하는 직원으로 이어질 것입니다.

누가 무엇을 했는지에 대한 사냥과 그에 대한 반응이 아니라 지식과 맥락에 대한 검색으로 검토에 접근하십시오.

검토는 기술의 실패에 관한 것이지만, 사람 프로세스만큼 기술적인 프로세스는 아닙니다. 사건에 연루된 사람들과 이야기하고, 더 중요한 것은 그들의 이야기를 들어보세요. 열린 마음을 유지합니다. 다른 사람들은 서로 다른 관점을 가지고 있으며 모든 사람이 동의하는 것은 아니며, 관점의 혼합은 학습 과정에 매우 중요합니다.

인시던트 후 검토는 정직한 질문입니다. 따라서 다음과 같은 주요 구성 요소를 수용합니다.

• 토론
• 담론(Discourse)
• 불 찬성
• 발견

이러한 "4Ds"는 인시던트 후 검토를 빌드할 수 있는 프레임워크를 만들어 더 안정적인 시스템과 함께 작동하는 생산성을 높일 수 있는 팀을 만듭니다.

다음 단원에서는 효과적인 인시던트 후 검토를 만들기 위해 수행할 수 있는 프로세스에 대해 자세히 설명합니다.