유용한 인시던트 사후 검토의 특징 및 구성 요소
이제 인시던트 사후 검토의 정의와 인시던트 대응 프로세스에서의 역할 및 수행해야 하는 시기를 알아보았습니다. 이 단원에서는 인시던트 사후 검토를 가장 효과적으로 활용하는 방법에 대해 자세히 살펴봅니다.
인시던트는 다 다르므로 인시던트 사후 검토의 정확한 구성도 다를 수 있습니다. 하지만 프로세스를 수행하기 위한 견고한 기반을 제공할 수 있는 유용한 검토의 몇 가지 일반적인 특성 및 구성 요소가 있습니다.
아닌 항목
유용한 인시던트 사후 검토에 대한 특성을 이해하려면 무엇이 아닌지를 고려해야 합니다.
- 문서 또는 보고서가 아닙니다. “검토”를 서면 요약이라고 생각하기 쉬우며, 실제로 인시던트 사후 검토에 이어 요약 보고서를 작성하는 경우가 많습니다. 하지만 인시던트 대응 수명 주기의 분석 단계에는 두 가지 고유한 부분이 있습니다.
- 인과 관계를 결정하는 것이 아닙니다. 검토 과정에서 오류에 기여한 요인을 조사하지만, 원인을 파악하는 것이 목적은 아닙니다. 특히, 유일한 근본 원인은 아닙니다. 복잡한 시스템에서는 대부분 다양한 요인으로 인해 오류가 발생합니다. 인시던트의 모든 측면을 고려하고 정보를 공유하여 배우고 향상하는 것이 목적입니다. 작업 항목의 목록이 아닙니다. 검토에서 학습한 결과가 그런 목록으로 나타날 수 있지만, 이는 초점이 아닙니다. 버그 보고 시스템에서 티켓 큐 또는 버그 보고서의 항목 목록을 알 수는 없지만 시스템에 대해 이전보다 더 많은 것을 알 수 있다면 검토는 성공한 것입니다.
무엇보다 인시던트 검토는 ‘대화’입니다. 팀에서 사용자가 당시에 알고 있던 내용과 지금 알고 있는 내용을 검토하고, 사용자를 비롯한 시스템의 각 부분이 문제에 대응하여 상호 간에 어떻게 작용하거나 작용하지 않는지를 파악할 수 있도록 정의된 공간입니다.
특성 및 구성 요소
마지막 단원에서 언급한 대로 인시던트 검토에서는 비난이 없어야 합니다. 시스템의 사용자 부분이 어떻게 상호 작용하는지를 조사해야 하지만, 특정 사용자의 “잘못”으로 레이블을 지정하기 위한 것이 아닙니다. 사용자가 아니라 기술 및 프로세스의 오류에 초점을 맞추어야 합니다.
이 점을 반영하여 질문을 구성하세요. 예를 들면 다음과 같습니다.
- “모니터링에서 올바른 결정을 내리는 데 필요한 컨텍스트를 키보드에 제공하지 못한 부족했던 점은 무엇인가요?”
- “도구에 ‘전체 데이터베이스 제거’ 옵션이 있는 이유는 무엇인가요?”
- 다음과 같은 질문이라면 더 좋습니다. “이 기능을 수행하기 전에 도구에서 확인을 요청하지 않는 이유는 무엇인가요?”
오류가 발생할 경우 비난하기 쉽습니다. 하지만 다음과 같은 주요 사항을 명심해야 합니다.
개인을 해고하여 안정성을 얻을 수 없습니다.
비난하고 수치심을 주거나 “책임자”를 찾아서 해고하기 위한 목적으로 조사하는 것으로는 안정적인 시스템을 구축할 수 없습니다. 대신 경험이 미숙하거나 허울뿐인 팀만 남고 담당자는 행동하는 것을 두려워하게 됩니다.
누가 무엇을 했는지 밝히고 그에 반응하는 것이 아닌 정보와 컨텍스트를 검색하는 과정으로 검토에 접근해야 합니다.
검토는 기술 오류에 관한 것이지만 사용자 프로세스만큼 기술적인 프로세스가 아닙니다. 인시던트에 관련된 사람들과 대화하고 의견을 들어보세요. 열린 마음을 유지하세요. 사람마다 관점이 다르고 모두가 동의하는 것은 아니므로 관점을 결합하는 것이 학습 프로세스에 매우 중요합니다.
인시던트 사후 검토는 솔직한 조회입니다. 따라서 다음과 같은 주요 구성 요소를 수용합니다.
- 토론(Discussion)
- 담론(Discourse)
- 이의 제기(Dissent)
- 발견(Discovery)
위의 “4D”는 함께 작용하는 더 신뢰할 수 있는 시스템과 더 생산적인 팀을 구축하는 데 유용한 인시던트 사후 검토를 구성할 수 있는 토대를 제공합니다.
다음 단원에서는 효과적인 인시던트 사후 검토를 만들기 위해 따라야 하는 프로세스를 자세히 설명합니다.