인시던트 사후 분석 타임라인 만드는 방법

장애를 돌아볼 때는 알림을 받은 시각, 대응을 시작한 시각, 오류가 줄어든 시각을 기억하기 쉽습니다. 하지만 고객이 처음 영향을 받은 시각은 그보다 빠를 수 있습니다. 사후 분석 타임라인은 기록된 사실과 나중에 세운 가설을 분리해 그 간격을 살펴보게 합니다.

각 시각을 검증 가능한 정보로 남기세요. 시간대와 기록 출처, 확신 수준을 함께 적고 빈칸을 추정치로 채우지 말고 ‘미확인’으로 표시합니다. 감지, 확인, 완화, 복구, 후속 조치를 분리하세요. 첫 알림이 고객 영향의 시작을 뜻하는 것은 아닙니다.

협업 보드에 사건, 질문, 후속 조치를 함께 놓고 논의해 보세요. Google SRE의 사후 분석 지침은 상세한 시간 기록과 비난보다 시스템 개선에 집중하는 방식을 강조합니다. 아래 시각은 설명을 위한 가상 사례이며 Boardmix 고객 데이터가 아닙니다.

순서를 정하기 전에 근거를 모으세요

오류 로그, 배포 기록, 장애 채널의 대화, 고객 지원 문의, 서비스 지표를 모읍니다. 발생 시각과 팀이 알게 된 시각을 구분하고 시간대도 적으세요. 출처마다 시간이 다르면 하나를 임의로 골라 쓰지 말고 차이를 확인합니다.

예시: 예약 확인 오류

이 순서만으로 배포가 유일한 원인이었다고 단정할 수 없습니다. 코드와 설정, 실제 동작을 대조해야 합니다. 오류율이 정상 범위로 돌아와도 지연된 예약 확인까지 모두 끝났다는 뜻은 아닙니다.

영향과 추정을 별도로 표시하세요

시간선 아래에 고객 영향, 경보, 팀의 결정, 열린 질문을 나눠 둡니다. ‘경보가 09:16에 울렸다’는 확인 가능한 문장입니다. ‘당직자가 늦게 대응했다’는 표현은 당시 어떤 정보를 받았는지 설명하지 못합니다. 원인 가설은 확인된 사건과 다른 색으로 표시하세요.

Boardmix에 타임라인을 만드세요

가로축에 시각을 놓고 아래에 확인된 고객 영향을 표시합니다. 보안상 민감한 로그는 공개 보드에 복사하지 말고 권한이 관리되는 원본 기록에 연결하세요. 여덟 분의 탐지 간격과 이를 줄일 방안을 별도 영역에 적고, 각 조치의 책임자와 확인 방법을 정합니다.

‘모니터링 개선’이라는 말만으로는 부족합니다. 어떤 조건을 바꾸고 적용 후 어떻게 검증할지 정해야 합니다. 보드는 분석을 돕고, 실제 운영 사실은 모니터링 시스템에서 확인합니다.