장애 회고를 실행 항목과 증거로 연결하는 액션 트래킹 방법

장애 회고의 산출물은 긴 원인 설명이 아니라 재발 가능성을 낮추는 실행 항목입니다. 영향과 타임라인을 먼저 사실로 고정한 다음, 원인에 대응하는 항목마다 소유자·완료 기한·검증 방법·미완료 시 에스컬레이션을 붙여야 회고가 운영 큐로 이어집니다. 액션 카드의 필드는 owner, due, evidence, status입니다.

회고는 개인을 찾는 문서가 아니라 시스템이 어떻게 실패했는지 설명하는 기록이어야 합니다. Google SRE는 비난 없는 사후 분석과 구체적인 후속 조치를 강조합니다.Google SRE postmortem culture를 참고하되, 팀의 실제 로그와 배포 기록을 우선 증거로 사용합니다.

장애 타임라인과 영향 고정

첫 페이지에는 사용자 영향, 시작·탐지·완화·복구 시각, 영향받은 기능, 정상화 근거만 적습니다. ‘설정 변경이 원인’이라고 단정하기 전에 배포 diff, 모니터링 알림, 오류율 변화, 롤백 시각을 연결합니다. 원인과 기여 요인은 구분하고, 확인되지 않은 가설에는 미확인 표시를 붙입니다.

기여 조건과 원인 경계

‘모니터링 강화’는 작업이 아닙니다. ‘결제 오류율 알림에 카드사별 분류를 추가하고 대시보드 링크를 등록한다’처럼 완료 후 무엇이 달라지는지 씁니다. 각 항목에는 owner, due, priority, evidence, status를 둡니다. 예방·탐지·복구 항목이 한 종류로 몰리지 않았는지도 확인합니다.

1. 원인 문장에서 통제 가능한 실패 지점을 한 개 선택한다.

2. 변경할 코드·설정·런북과 소유자를 지정한다.

3. 완료 증거와 재현 가능한 검증 명령 또는 대시보드를 적는다.

액션 소유권과 검증 증거

가상 사례의 입력은 배포 직후 상품 조회 오류가 증가했고 이전 설정으로 되돌리자 정상화된 장애입니다. 결정은 배포 승인 체크에 캐시 키 호환성 검사를 넣는 것입니다. 중간 산출물은 ‘액션 A: 캐시 키 회귀 테스트 추가 / owner: 플랫폼 / due: 금요일 / evidence: CI 링크 / 신호: 오류율 알림’ 카드입니다.

예상 결과는 다음 배포 전에 호환성 실패가 CI에서 보이고, 운영자는 같은 알림 대시보드에서 재발 여부를 확인하는 것입니다. 단순히 회고 문서에 ‘주의’라고 적는 것은 산출물도 소유자도 없어 완료로 인정하지 않습니다.

회고 종료 검토와 실패 복구

기한이 지난 항목을 회고 문서에서 조용히 삭제하면 재발 방지 공백이 생깁니다. 상태를 blocked로 바꾸고 막힌 의존성, 새 기한, 결정권자에게 보낼 에스컬레이션을 기록합니다. 증거 링크가 깨졌다면 링크를 새로 만들기 전에 원본 로그의 보존 정책과 접근 권한을 확인하고 요약 증거를 남깁니다.

재발 방지 완료 조건

회고는 영향·타임라인·원인에 근거 링크가 있고 모든 실행 항목에 owner, due, 완료 증거가 있으며, 미완료 항목은 다음 검토 일정과 에스컬레이션이 기록된 때 완료로 표시합니다. 검증 실행 결과와 재발 신호가 실제 대시보드에서 확인되면 검증 완료입니다.