RCA 보고서 작성 — 근본 원인과 재발방지를 증명하는 문서 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theoryitsm/rca-report-writing

TRACK

ITSM

SLA

50분

SEV

SEV-2

PHASES

3단계

ENV

local

INCOMING TICKET

“고객사 IT 담당자: "복구는 알겠습니다. 왜 커넥션 풀이 고갈됐고, 다음 달에 또 안 난다는 보장은 무엇입니까? 장애보고서 말고 근본원인분석(RCA) 보고서를 정식 산출물로 제출해 주세요 — 담당·기한이 붙은 재발방지대책까지요."”

YOUR ROLE

IT 서비스 운영·문제관리(Problem) 담당

IMPACT IF UNRESOLVED

복구 경위만 적힌 장애보고서를 다시 내면 반려되고, 근본 원인·기여 요인을 안 밝히면 같은 부류 장애가 재발하며, 담당·기한 없는 대책은 추적되지 않아 다음 장애 때 미이행 추궁으로 되돌아온다.

🚨INCIDENT BRIEF

운영자 A가 지난주 결제 장애의 장애보고서를 올렸습니다 — "21:05 결제 실패 급증, 커넥션 풀 고갈 확인, 21:27 인스턴스 재시작 후 정상화." 무슨 일이 났고 어떻게 복구했는지가 깔끔히 담겼습니다.

그런데 고객사 IT 담당자가 회신합니다. "복구는 알겠습니다. 왜 커넥션 풀이 고갈됐고, 다음 달에 또 안 난다는 보장은 무엇입니까? 재발방지대책을 정식 문서로 주세요."

장애보고서는 사건을 정확히 적었지만 거기서 멈췄습니다. 고객이 요구하는 건 한 단계 위의 문서 — RCA 보고서입니다. "무슨 일이 났나"가 아니라 "왜 일어났고, 누가, 언제까지, 어떻게 막는가"를 증명하는 문서. 이 Lab은 그 문서를 세 단계로 직접 작성한다 — 사실 정리, 근본 원인 도출, 재발방지 대책·검증·추적.

⏱ 50분📊 중급🔧 3단계#rca-report#root-cause#documentation#itil

MISSION

사실 기반 정리 — 문제 정의·영향·타임라인 (원인 섞지 않기)

무엇이 잘못됐는지(증상·범위), 영향(서비스·건수·시간·정량 손실), 탐지에서 정상화까지의 타임라인을 시각과 함께 사실로만 정리하고, 증명 안 된 원인을 정의에 섞지 않는다.

근본 원인 도출 — 5 Whys로 깊게, 피시본으로 넓게 (표면 증상과 구분)

5 Whys로 표면 증상에서 제거하면 이 부류 장애가 안 나는 지점까지 내려가 근본 원인을 서술하고, 피시본으로 기여 요인을 여러 범주로 펼쳐 단일 원인 단정과 개인 귀책을 피한다.

재발방지 대책·검증·추적 — 근본 원인·기여 요인마다 담당·기한·효과 측정

근본 원인과 각 기여 요인을 하나도 빠짐없이 대책으로 연결하고, 대책마다 담당·기한·검증 방법을 붙여 액션아이템으로 만들며, 문제관리 보드 등록으로 완료까지 추적한다.

📌 선수 지식

• [이론] itsm/rca-report-writing

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES