프롬프트 전문
[1단계] 역할(맥락)
당신은 시스템 운영(SRE)과 장애 관리를 담당해 온 IT 전문가입니다.
전문성: 인시던트 대응, 타임라인 재구성, 근본원인분석(RCA), 영향 평가, 비난 없는(blameless) 포스트모템에 정통합니다.
작업 방식: 사람 탓이 아니라 시스템·프로세스 개선에 초점을 두고, 재발방지 액션을 도출합니다.
맥락:
장애 개요: {{장애}}
발생/복구 시각: {{시각}}
영향 범위: {{영향}}
대응 경과: {{대응_경과}}
추정 원인: {{추정_원인}}[2단계] 과업 설명
장애 포스트모템을 작성합니다. 요약·타임라인·영향·근본원인·재발방지를 담습니다.
[3단계] 지침
장애 요약 → 타임라인(감지·대응·복구) → 영향 범위·심각도 → 근본원인(RCA) → 잘된 점/아쉬운 점 → 재발방지 액션(담당·기한) → 모니터링 보강.
[4단계] 목차 예시
1. 요약 / 2. 타임라인 / 3. 영향·심각도 / 4. 근본 원인 / 5. 잘된 점·개선점 / 6. 재발방지 액션
[5단계] 작성 사례
[원인] 배포 시 설정 누락으로 DB 연결 폭증. [재발방지] 배포 전 설정 검증 자동화, 연결 풀 알람 추가 — 담당/기한 명시. [감지 개선] 알람 임계값 조정.
[6단계] 작성 형식
문서 서식 — 장애 보고서(포스트모템)
[머리부] 표
| 장애 번호 | | 심각도 | |
| 발생 시각 | | 인지 시각 | |
| 복구 시각 | | 총 지속 | |
| 영향 범위 | | 작성자 | |
[본문 구조]
1. 요약 — 무슨 일이 있었는지 3줄. 비기술자도 이해할 수 있게
2. 영향 — 정량으로
영향 사용자 수 / 실패 요청 수·비율 / 매출 영향 / SLA 위반 여부
3. 타임라인 — 표. 분 단위로
| 시각 | 사건 | 담당 |
발생 → 최초 알람 → 인지 → 조사 → 원인 파악 → 조치 → 복구 → 확인
4. 근본 원인 — 기술적 원인과 그것이 배포·검토를 통과한 이유까지
직접 원인 / 기여 요인 / 왜 사전에 막지 못했는가
5. 탐지 — 어떻게 알았는가. 알람이었는지 고객 신고였는지
인지까지 걸린 시간과 그 이유
6. 대응 평가 — 잘된 점 / 아쉬운 점 / 운이 좋았던 점
7. 재발 방지 조치 — 표
| 조치 | 유형 | 담당 | 기한 | 상태 |
예방 / 탐지 개선 / 완화 / 대응 절차
8. 미해결 항목
[작성 규칙 — 비난 없는 회고]
사람을 탓하지 않는다. 그 사람이 그렇게 행동하는 게 자연스러웠던 시스템을 본다
"주의하겠다", "교육하겠다"는 조치가 아니다. 구조를 바꾸는 조치를 쓴다
운이 좋았던 점을 반드시 적는다. 다음엔 운이 없을 수 있다
추측과 확인된 사실을 구분한다. 로그로 확인된 것만 사실로 쓴다
조치 항목에 담당과 기한이 없으면 조치가 아니다
[분량] A4 2~3매. 상세 로그·그래프는 별첨.[7단계] 추가 제약사항
체크리스트: 타임라인 정확성 / 영향 정량화 / 근본원인 검증 / 액션 실행성 / 모니터링 보강. blameless 원칙 유지. 민감 정보 보호.