회의 녹음으로 사고 분석하기: 포스트모템 템플릿

먼저 사건의 순서를 복원하세요

장애 후에는 오류를 발견한 때, 나중에 메시지를 받은 때, 수정을 시작한 때 등 사람마다 다른 순간을 기억합니다. 그럴듯한 설명도 순서를 틀릴 수 있습니다. 검증할 수 있는 타임라인에서 시작하세요.

초기 복구가 끝나면 팀이 차분히 포스트모템을 작성할 수 있습니다. 녹음에는 설명이 남습니다. 시간은 메시지, 로그, 다른 자료와 대조하세요. 공개 보고서에는 내부 자료를 넣지 마세요.

분석을 네 부분으로 구성하세요

1. 영향을 설명하세요

   어떤 기능이나 업무가 누구에게 얼마나 오랫동안 불가능했는지 적으세요. 확인된 영향과 가능성을 구분하세요. 영향받은 사람 수를 모르면 그 사실을 명시하세요.

2. 타임라인을 만드세요

   발생, 감지, 보고, 초기 대응, 복구 시각을 모으고 시간대를 적으세요. 증언만 있는 사건은 출처와 확신 정도를 남기세요. 대략적인 시간은 구분해 표시하세요.

3. 설명을 검증하세요

   직접적인 계기와 문제를 발생시키거나 길게 만든 조건을 구분하세요. 결정할 때 알았던 정보를 물으세요. 각 가설에 증거를 연결하고 무엇이 반증이 될지 적으세요.

4. 검증할 수 있는 조치를 배정하세요

   구체적인 위험을 줄이거나 감지 및 복구를 앞당길 조치를 고르세요. 각각 담당자, 결과, 확인 방법을 정하세요. ‘더 조심하기’로는 업무가 바뀌었는지 확인할 수 없습니다.

새 요청 알림이 도착하지 않는다

가상의 학습 예시입니다. 이름, 조건, 결과는 방법을 설명하기 위한 것입니다.

요청 기록은 남아 있었습니다. 알림 전송에 장애가 있었습니다. 이 차이로 영향과 조치가 달라집니다.

타임라인은 예시입니다. 발생과 감지 사이의 간격을 보여 주지만 기술적 원인을 입증하지는 않습니다.

포스트모템 템플릿

검증할 때까지 원인 후보를 가설로 표시하세요.

사고, 기간, 시간대:
확인된 영향:
타임라인: 시각 / 사건 / 출처:
직접적인 계기:
기여한 조건:
복구에 도움이 된 것:
아직 확인되지 않은 것:
조치 / 담당자 / 기한 / 검증:
실행 여부를 확인할 시점:

재발 방지에 도움이 되는지 확인하세요

• 영향을 ‘전부 고장 났다’보다 구체적으로 설명했다.
• 사건 시각과 논의 시각을 구분했다.
• 확인된 원인과 가설을 구분했다.
• 조치마다 관찰 가능한 문제와 검증 방법이 있다.