회고는 누가 잘못했는지 정하는 문서보다, 당시의 정보와 시스템 조건을 복원하고 다음 행동을 정하는 문서에 가까워야 합니다. 사실·해석·개선 과제를 분리하고 과제마다 담당자와 완료 증거를 남기세요.
회고의 출발점은 사용자 영향
어떤 기능이 얼마나 오래 영향을 받았는지부터 작성합니다. 측정된 값, 추정한 값, 아직 알 수 없는 값을 구분하고 근거가 되는 로그나 지표의 위치를 남깁니다. 운영자가 바빴다는 사실만으로는 이용자가 겪은 문제를 설명할 수 없습니다. 이 문서는 일반적인 서비스 장애 회고 가이드입니다. 보안 사고 조사나 법적 보고 의무가 있는 상황의 절차를 대체하지 않습니다.
시간순 사실과 나중의 해석을 나누기
타임라인에는 발견, 전파, 판단, 조치, 복구 확인 시각을 적습니다. ‘왜 그렇게 판단했는가’는 당시 볼 수 있었던 정보에 근거해 기록합니다. 회고 시점에 알게 된 사실을 당시 담당자도 알고 있었다고 가정하지 마세요. 가상 예시: ‘배포 알림은 성공이었고 오류 대시보드는 5분 지연되어 이상을 바로 확인하지 못함’은 ‘담당자가 확인을 소홀히 함’보다 개선 대상을 찾기 쉽습니다. 사람이 한 행동을 지우는 대신 그 행동을 유도한 조건까지 함께 적습니다.
원인 하나로 설명을 끝내지 않기
문제를 촉발한 변경, 영향이 커진 구조, 늦게 발견한 이유, 복구를 어렵게 만든 조건을 나누어 봅니다. 코드 결함과 별개로 검증 환경, 승인 기준, 알림 전달, 롤백 준비가 영향을 줄 수 있습니다. 근거 없는 추정은 가설로 표시하고 후속 확인 담당자를 둡니다. 잘 작동한 대응도 남기세요. 빠르게 도움이 된 문서나 연락 체계는 다음 사고에서도 유지해야 할 자산입니다.
개선 과제는 완료를 확인할 수 있게
‘주의하기’, ‘교육 강화’만으로 끝내지 말고 다음 행동과 확인 방법을 적습니다. 아래는 가상 과제 예시입니다. 문제: 배포 후 오류 증가를 늦게 확인함 행동: 배포 체크리스트에 핵심 요청의 오류율 확인 단계 추가 담당: 서비스 담당자 한 명 지정 기한: 다음 정기 배포 전 완료 증거: 체크리스트 변경과 리허설 기록 링크 과제를 많이 만드는 것보다 위험을 줄이는 소수의 과제를 실제로 완료하는 편이 낫습니다. 미완료 사유와 재검토 시점도 추적하세요.
회고 문서를 닫기 전 확인
영향과 타임라인에 근거가 있는가? 당시의 판단 맥락이 설명되어 있는가? 관찰 사실과 가설이 구분되어 있는가? 개선 과제마다 담당·기한·완료 증거가 있는가? 공유본에서 고객 개인정보와 비밀값을 제거했는가? 다음 담당자가 이 문서만 읽어도 같은 상황에서 첫 행동을 선택할 수 있는지 검토하면 문서의 빈 부분을 찾기 쉽습니다.
참고 자료
사람을 비난하기보다 시스템과 절차를 개선하는 회고 원칙 및 실행 가능한 후속 조치는 Google SRE Workbook의 Postmortem Culture를 참고했습니다. 본문의 양식과 예시는 이 사이트의 일반 가이드로 구성했습니다. https://sre.google/workbook/postmortem-culture/
장애 대응, 처음부터 끝까지
사례로 익히는 현장 대응 프로세스