장애보고서(포스트모템)에 꼭 들어가야 할 항목
장애보고서의 뼈대는 개요 정보입니다. 장애 제목은 "결제 API 응답 지연으로 인한 주문 실패"처럼 원인과 증상이 드러나게 적고, 영향받은 시스템/서비스명, 심각도, 작성자를 명시합니다. 심각도는 보통 P1(전체 중단)~P4(경미)로 구분하는데, 등급이 명확해야 보고 라인과 대응 우선순위가 정해집니다. 여기에 발생 시각·감지 시각·복구 시각 세 가지를 기록하면 장애 시간(발생→복구)과 감지 소요시간(발생→감지)이 나옵니다. 감지 소요시간이 길다면 모니터링 공백이 있다는 신호이므로 그 자체가 개선 과제가 됩니다.
타임라인은 장애보고서의 핵심 증거 자료입니다. "14:05 커넥션 풀 고갈 시작 → 14:12 임계치 알림 → 14:30 원인 후보 식별 → 15:00 롤백 → 16:20 정상화 확인"처럼 시각과 사건을 짝지어 기록하면, 대응 과정의 병목(알림이 늦었는지, 원인 파악이 오래 걸렸는지)이 한눈에 보입니다. 영향 범위는 "영향받은 사용자 수·기능"과 "비즈니스 영향(매출 손실, CS 인입량)"을 나눠 적어야 경영진과 기술 조직이 같은 문서를 읽을 수 있습니다.
원인은 직접 원인과 근본 원인을 구분하는 것이 좋은 보고서의 조건입니다. 직접 원인은 "배치의 장기 트랜잭션이 커넥션 풀을 고갈시켰다"처럼 기술적 방아쇠이고, 근본 원인은 "배치와 온라인 트랜잭션이 리소스를 분리 없이 공유했고 배포 전 영향 검토 절차가 없었다"처럼 그것을 가능하게 한 구조입니다. 조치도 마찬가지로 임시 조치(당장 불 끄기)와 영구 조치(구조 개선)를 나누고, 재발 방지 대책에는 항목마다 담당자와 기한을 붙여야 실행이 담보됩니다.
이 생성기는 위 구조를 폼으로 제공하며, 시각을 입력하면 장애 시간이 자동 계산되고 타임라인은 시각순으로 자동 정렬됩니다. 작성 내용은 브라우저에만 저장되어 사내 장애 정보가 외부로 나가지 않으며, 완성된 보고서는 심각도 배지가 포함된 형태로 마크다운 복사(위키·노션), 텍스트 복사(이메일), .md 다운로드, 인쇄/PDF 저장으로 바로 공유할 수 있습니다.