# RCA(근본원인분석) 보고서 (빈 양식)

> 작성 원칙
> 1. RCA는 **장애보고서를 대체하지 않는다.** 장애보고서의 타임라인을 입력으로 삼아 분석·약속을 얹는다.
> 2. 근본 원인을 **하나로 단정하지 않는다.** 기여 요인(탐지·여유·검증의 빈틈)을 함께 본다.
> 3. **사람이 아니라 시스템·절차의 빈틈**을 본다(blameless). "담당자가 깜빡함"이 아니라 "체크리스트에 없어 누락될 수 있는 구조".
> 4. 재발방지대책은 **무엇을 / 누가 / 언제까지 / 어떻게 검증**까지 채워 액션아이템으로 추적한다.

| 항목 | 내용 |
|---|---|
| 문서번호 | `RCA-[YYYY-MMDD-NN]` |
| 연관 장애보고서 | `[INC-________]` |
| 대상 서비스 / 장애일 | `[서비스명 / YYYY-MM-DD]` |
| 작성자 / 부서 | `[작성: 홍길동 / 문제관리]` |
| 작성일 / 검토자 | `[YYYY-MM-DD / ____]` |

---

## 1. 문제 정의

> 무엇이 잘못됐는지 한두 문장으로. 증상과 범위만. (원인을 미리 단정해 섞지 말 것)

`[작성 예시: HH:MM부터 OO분간 OO 서비스의 요청 OO%가 OO으로 실패함.]`

## 2. 영향

- 영향 서비스: `[ ]`
- 실패 건수 / 영향 고객: `[정량으로 — "영향 있었음"으로 끝내지 말 것]`
- 지속 시간: `[HH:MM ~ HH:MM, __분]`
- 정량 손실: `[추정 매출 / SLA 위반 여부]`

## 3. 타임라인

> 탐지·에스컬레이션·조치·정상화를 시각과 함께. (분석 결과는 여기 섞지 말 것 — 4번에서)

```text
[HH:MM]  [발생/탐지]
[HH:MM]  [인지·조사 시작]
[HH:MM]  [직접 원인 확인]
[HH:MM]  [복구 조치]
[HH:MM]  [정상화 확인]
```

## 4. 분석 과정

> 어떻게 원인에 도달했는지. 결론만 적지 말고 도달 과정을 남긴다.

### 4-1. 5 Whys (수직 — 한 줄기를 깊게)

```text
Q1. 왜 [표면 증상]이 발생했나?   → [한 단계 아래 원인]
Q2. 왜 [위 원인]이 일어났나?     → [더 아래 원인]
Q3. 왜 [위 원인]이 운영까지 갔나? → [검증/절차의 빈틈]
Q4. 왜 [위]를 미리 못 막았나?    → [탐지/관측의 빈틈]
Q5. 왜 [위]가 없었나?            → [구조적 누락]
                                → (근본 원인: __________)
```

### 4-2. 피시본 (수평 — 여러 범주로 넓게)

> 5 Whys 한 줄기로 놓치는 기여 요인을 범주별로 펼친다.

| 범주 | 기여 요인 |
|---|---|
| 사람(People) | `[교육·인수인계·권한 등 — 단, 개인 비난 아닌 구조로]` |
| 프로세스(Process) | `[체크리스트·승인·리뷰의 빈틈]` |
| 시스템(System) | `[코드·설정·아키텍처의 약점]` |
| 환경(Environment) | `[트래픽·외부 의존·타이밍]` |

## 5. 근본 원인

> 제거하면 이 부류의 장애가 안 나는 지점. 표면 증상을 근본 원인으로 적지 말 것.

`[작성: __________ (제거 시 이 부류 재발이 막히는 지점)]`

## 6. 기여 요인

> 근본 원인이 장애로 번지게 한 다른 요인들. 비어 있으면 단일 원인 단정을 의심한다.

- `[기여 요인 1 — 탐지 측면]`
- `[기여 요인 2 — 여유/용량 측면]`
- `[기여 요인 3 — 검증/테스트 측면]`

## 7. 재발방지대책 (액션아이템)

> 근본 원인뿐 아니라 **기여 요인 각각**을 대책으로 연결한다. 빈 축이 있으면 그 축으로 재발한다.
> 유형: **시정(이미 난 것 고침)** / **예방(다시 안 나게 함)** — 예방이 비어 있지 않은지 점검.

| # | 대책 (검증 가능한 동사로) | 유형 | 담당 | 기한 | 검증 방법 |
|---|---|---|---|---|---|
| 1 | `[          ]` | `[시정/예방]` | `[    ]` | `[    ]` | `[          ]` |
| 2 | `[          ]` | `[시정/예방]` | `[    ]` | `[    ]` | `[          ]` |
| 3 | `[          ]` | `[시정/예방]` | `[    ]` | `[    ]` | `[          ]` |

## 8. 검증 계획

> 대책이 실제로 효과 있었는지 확인하는 방법·시점. (대책으로 끝내고 검증을 빠뜨리지 말 것)

- `[예: 대책 적용 후 2주간 OO 지표 모니터링, 임계 경보 발화 테스트로 동작 확인]`
- `[예: 다음 정기 점검/부하 테스트 리포트에 해당 항목 포함 여부 확인]`
- 액션아이템 추적: `[다음 문제관리(Problem) 보드/운영 회의에서 완료·검증까지 추적]`

---

> 결재 / 검토
>
> | 작성 | 검토(운영 PL) | 승인(PM) | 고객 통보 |
> |---|---|---|---|
> | `[서명/일시]` | `[서명/일시]` | `[서명/일시]` | `[담당/일시]` |