[Infra Ops] 타임라인 분석과 재발 방지 대책 수립

🚨INCIDENT ALERT

HIGH

새벽 2시에 장애가 났습니다. 빠르게 서비스를 복구했고, 오전 9시에 팀장이 묻습니다. "보고서 언제 나와요?" 무슨 내용을 어떻게 써야 할지 막막합니다. 그냥 "DB 문제였고 재시작으로 해결했다"고 쓰면 될까요?

장애 보고서는 다음 장애를 막기 위한 문서입니다. 잘 쓴 보고서는 팀 전체가 같은 장애를 두 번 겪지 않게 하고, 조직의 인프라 성숙도를 높입니다. 이 모듈은 장애 타임라인 재구성부터 5-Why 분석, 재발 방지 대책 수립까지 — 실제로 쓸 수 있는 보고서를 만드는 방법을 다룹니다.

이번 챕터에서 배울 것

1장애 보고서의 구성 요소(요약, 타임라인, 원인 분석, 재발 방지)를 설명할 수 있다
2로그 timestamp를 기준으로 장애 타임라인을 재구성할 수 있다
35-Why 기법으로 직접 원인에서 근본 원인까지 분석할 수 있다
4측정 가능한 재발 방지 대책(담당자, 기한, 완료 기준 포함)을 작성할 수 있다
5좋은 재발 방지 대책과 나쁜 재발 방지 대책의 차이를 구분할 수 있다

장애 보고서 구성

💡개념

보고서가 다뤄야 할 핵심 항목

장애를 복구하고 나서 팀장이 "보고서 써줘"라고 합니다. 처음 쓰는 사람은 "기술적으로 무슨 일이 있었는지"만 나열하다가 마칩니다. 경영진은 "몇 명 고객이 영향받았고, 매출 손실이 얼마였으며, 다시는 일어나지 않을 것인지"를 묻습니다. 두 독자를 모두 만족시키지 못하면 좋은 보고서가 아닙니다. 구조를 알면 쓰는 시간도, 받아들이는 쪽도 훨씬 빨라집니다.

장애 보고서의 독자는 두 종류입니다. 기술 내용을 이해하는 엔지니어팀과, 영향 범위와 재발 방지에 관심 있는 경영진입니다. 좋은 보고서는 두 독자 모두를 만족시킵니다.

장애 보고서 표준 구성:

1. 요약 (Executive Summary)
   - 발생 일시와 복구 일시
   - 총 장애 지속 시간
   - 영향 범위 (서비스명, 영향받은 사용자 수/트랜잭션 수)
   - 핵심 원인 한 줄 요약

2. 타임라인 (Timeline)
   - 장애 발생부터 복구까지 시각 순서대로
   - 각 시점에 누가 무엇을 했는지 명시

3. 원인 분석 (Root Cause Analysis)
   - 직접 원인: 기술적으로 무슨 일이 발생했나
   - 근본 원인: 왜 그 일이 가능했나 (5-Why)

4. 재발 방지 대책 (Action Items)
   - 각 대책에 담당자, 기한, 완료 기준 명시

5. 교훈 (Lessons Learned)
   - 팀 전체가 공유할 인사이트

타임라인 재구성

💡개념

로그에서 타임라인을 뽑아내는 방법

장애 타임라인은 기억에 의존하면 안 됩니다. 로그의 timestamp가 유일한 사실입니다. 장애 복구 직후, 관련 로그를 수집하고 시각순으로 정렬하는 것이 첫 번째 작업입니다.

로컬 터미널

# Tomcat 에러 로그에서 장애 시각대 추출
grep -E "ERROR|WARN|Exception" /opt/tomcat/logs/catalina.out \
  | grep "2026-05-30 14:" \
  | head -30

# 예시 출력:
# 2026-05-30 14:02:31 WARN  HikariPool - Connection is not available, request timed out after 30000ms
# 2026-05-30 14:02:31 ERROR DispatcherServlet - Servlet.service() for servlet threw exception
# 2026-05-30 14:03:15 ERROR HikariPool - HikariPool-1 - Connection timeout

# Nginx 액세스 로그에서 500 에러 시작 시점
grep " 500 " /var/log/nginx/access.log | grep "30/May/2026:14:" | head -5

# DB slow query 로그 확인 (MySQL 예시)
grep -A2 "Query_time" /var/log/mysql/slow.log | grep "2026-05-30 14:" | head -10

# 시스템 로그에서 관련 이벤트
journalctl -u tomcat --since "2026-05-30 14:00" --until "2026-05-30 15:00" \
  | grep -E "ERROR|killed|OOM"

타임라인 작성 예시:

14:00  배포 완료 (v2.4.1 → v2.4.2)
14:02  모니터링 alert — Tomcat Connection Pool 사용률 100%
14:03  고객 신고 첫 건 — "결제 오류" (Slack #support)
14:05  온콜 엔지니어(홍길동) 접속, 로그 확인 시작
14:08  DB slow query 확인 — /api/orders GET 쿼리 5초 이상
14:12  해당 쿼리 인덱스 없음 확인 (EXPLAIN 실행)
14:15  Tomcat 재시작으로 임시 서비스 복구
14:22  인덱스 추가 배포
14:25  모니터링 정상 확인, 장애 종료
       총 장애 시간: 23분 (14:02 ~ 14:25)

5-Why 분석

💡개념

표면적 원인에서 근본 원인으로

보고서에 "Tomcat이 다운되었습니다"라고 쓰면, 다음 달에 같은 Tomcat이 또 다운됩니다. "왜 다운됐는가"까지 파고들지 않으면 증상만 치료하고 원인은 그대로 남습니다. 장애 재발 방지의 핵심은 표면 현상에서 멈추지 않고 운영 절차나 구조적 결함까지 도달하는 것입니다. 5-Why는 이 과정을 체계화합니다.

5-Why는 "왜?"를 반복해서 근본 원인까지 파고드는 기법입니다. 단순히 5번을 채우는 것이 목적이 아닙니다. "더 이상 왜를 물을 수 없는 곳"에서 멈추는 것이 목표입니다.

5-Why 분석 예시:

현상: 14:02부터 결제 서비스에서 500 에러 폭발

Why 1: 왜 500 에러가 났는가?
→ Tomcat Connection Pool이 고갈됐다

Why 2: 왜 Connection Pool이 고갈됐는가?
→ DB 쿼리 응답이 5분 이상 걸렸다

Why 3: 왜 DB 쿼리 응답이 5분 이상 걸렸는가?
→ /api/orders?userId=... 쿼리가 인덱스 없이 full scan을 했다

Why 4: 왜 인덱스 없는 쿼리가 배포됐는가?
→ 이번 배포에 orders 테이블에 새 컬럼이 추가됐는데 인덱스가 누락됐다

Why 5: 왜 인덱스 누락이 배포 전에 감지되지 않았는가?
→ 배포 전 SQL 리뷰 프로세스가 없었고, 개발 환경에서는 데이터가 적어 full scan이 문제되지 않았다

근본 원인: 배포 전 SQL 변경사항에 대한 리뷰 프로세스 부재
→ 재발 방지 대책: CI 파이프라인에 SQL 변경사항 리뷰 단계 추가

좋은 5-Why의 특징:

각 단계가 논리적 인과관계로 연결된다
마지막 원인이 프로세스나 설계 수준이다 (개인 실수가 아니라)
근본 원인을 해결하면 같은 패턴의 장애가 재발하지 않는다

피해야 할 패턴:

Why 1: 왜 장애가 났는가? → 담당자가 인덱스를 빠뜨렸다
Why 2: 왜 인덱스를 빠뜨렸는가? → 실수로
Why 3: 왜 실수를 했는가? → 주의를 안 했다
...

사람을 탓하는 방향으로 흐르면 재발 방지 대책이 "주의한다"가 됩니다. 5-Why는 시스템과 프로세스의 결함을 찾는 도구입니다.

재발 방지 대책 작성

💡개념

실행 가능한 대책을 만드는 기준

3개월 전 장애 보고서를 꺼내봤더니 "모니터링을 강화한다"고 적혀 있습니다. 그 사이에 같은 유형의 장애가 한 번 더 났습니다. "강화한다"는 말에는 담당자도, 기한도, 완료 기준도 없습니다. 막연한 의지 표명은 재발 방지가 되지 않습니다. 실제로 실행되고 검증될 수 있는 대책의 조건이 있습니다.

재발 방지 대책은 "무엇을, 누가, 언제까지, 어떻게 완료됐다고 판단하는가"가 명확해야 합니다.

나쁜 재발 방지 대책 예시:

1. 배포 전 더 주의한다
2. 모니터링을 강화한다
3. 인덱스를 항상 확인한다

이 세 항목은 모두 담당자가 없고, 기한이 없고, 완료 기준이 없습니다. 한 달 후 같은 장애가 나도 이 항목들이 지켜졌는지 확인할 방법이 없습니다.

좋은 재발 방지 대책 예시:

| # | 대책 | 담당 | 기한 | 완료 기준 |
|---|------|------|------|-----------|
| 1 | CI 파이프라인에 SQL 변경사항 리뷰 체크리스트 추가 | DB팀 이민준 | 6/15 | PR에 SQL 변경 시 체크리스트 없으면 머지 차단 |
| 2 | 개발 환경 DB에 운영 수준 데이터 볼륨 추가 | 인프라팀 박현우 | 6/30 | EXPLAIN 플랜에서 full scan 감지 시 경고 |
| 3 | Tomcat Connection Pool 고갈 alert 추가 | 인프라팀 박현우 | 6/10 | Pool 사용률 80% 초과 시 Slack alert 동작 확인 |

각 항목이 "완료됐다"고 판단하는 기준이 테스트 가능한 형태입니다.

실습

1장애 시각대 로그에서 타임라인 재구성

실제 로그 파일에서 장애 시각대의 에러와 경고를 추출합니다. timestamp, 로그 레벨, 메시지를 한 줄로 정리해 타임라인 초안을 만듭니다. 파일이 없는 실습 환경에서는 /var/log/syslog 또는 journalctl 출력으로 대체합니다.

grep -E 'ERROR|WARN|Exception' /opt/tomcat/logs/catalina.out | grep '2026-05-30 14:' | awk '{print $1, $2, $3, $NF}' | head -20

🔍실행 후 확인할 것

첫 번째 ERROR 로그의 timestamp가 모니터링 alert 시각과 일치하는가
에러 패턴(같은 Exception이 반복)이 보이는가 — 반복 패턴은 루프 에러 가능성
WARN 로그가 ERROR보다 먼저 나타났는가 — WARN이 사전 징조일 수 있음
복구 조치 이후 로그에서 에러가 사라지는 시점이 확인됐는가

25-Why 분석 연습

DB 연결 관련 에러를 확인하고, 해당 에러를 시작점으로 5-Why 분석을 직접 작성해봅니다. 로그에서 첫 번째 에러 메시지를 가져와 "왜 이 에러가 발생했는가?"부터 시작합니다.

grep -E 'ORA-|SQLException|Connection' /opt/tomcat/logs/catalina.out | grep '2026-05-30 14:' | tail -5

🔍실행 후 확인할 것

로그 메시지에서 에러 유형(Connection timeout, OOM, OutOfMemory 등)을 식별했는가
에러 메시지로부터 Why 1을 자연스럽게 도출할 수 있는가
5번의 Why가 개인 탓이 아닌 프로세스/설계 결함으로 이어지는가
마지막 Why의 답이 구체적인 재발 방지 대책으로 연결되는가

트러블슈팅

원인: 재발 방지 대책을 "빠르게 마무리해야 하는 형식"으로 접근하거나, 근본 원인 분석 없이 표면적 증상에 대한 대책만 만들 때 발생합니다. 또는 특정 팀이나 개인을 탓하지 않으려는 배려가 지나쳐 구체성이 사라지기도 합니다.

진단 체크리스트:

재발 방지 대책 품질 점검:

□ 담당자가 명시됐는가? (팀명이 아닌 특정 사람)
□ 기한이 있는가?
□ 완료 기준이 테스트 가능한가? ("확인한다" → "X 상황에서 Y가 발생하면 Z로 간주")
□ 이 대책이 실행됐다면 이번 장애를 막을 수 있었는가?
□ "주의한다", "강화한다", "노력한다" 같은 태도 표현이 없는가?

개선 예시:

나쁜 예: "모니터링을 강화한다"
좋은 예: "Tomcat Connection Pool 사용률 80% 초과 시 Slack #ops-alert으로 알람 발송
          (담당: 인프라팀 박현우, 기한: 6/10, 완료 기준: 테스트 환경에서 80% 초과 시 알람 동작 확인)"

나쁜 예: "배포 전 더 주의한다"
좋은 예: "배포 PR 체크리스트에 'SQL 변경사항 EXPLAIN 결과 첨부' 항목 추가,
          체크리스트 미완성 시 GitHub Actions에서 머지 차단
          (담당: DB팀 이민준, 기한: 6/15)"

💼

실무 맥락

현업 패턴

실제 업무에서 이 지식이 쓰이는 상황:

장애 보고서는 단순히 "어떤 일이 있었다"의 기록이 아닙니다. 잘 작성된 보고서 하나가 팀 전체의 인프라 성숙도를 높이고, 동일 패턴의 장애를 영구히 없애는 계기가 됩니다.

장애 보고서 작성 타임라인 권장:

장애 복구 직후 (0~1시간): 로그 수집, 타임라인 메모
복구 후 24시간 내:        초안 작성 (완벽하지 않아도 됨)
복구 후 48~72시간 내:     팀 리뷰, 5-Why 완성, 재발 방지 대책 확정
1주 후:                   재발 방지 대책 이행 시작 확인

장애 보고서 템플릿 (직접 사용 가능):

MARKDOWN

## 장애 보고서 — [서비스명] [날짜]

### 요약
- 발생: YYYY-MM-DD HH:MM
- 복구: YYYY-MM-DD HH:MM
- 지속 시간: N분
- 영향: [영향받은 서비스/사용자 수/트랜잭션 수]
- 핵심 원인: [한 줄 요약]

### 타임라인
| 시각 | 행동 | 담당자 |
|------|------|--------|
| HH:MM | 현상 감지 | 시스템/모니터링 |
| HH:MM | [대응 행동] | [이름] |
| HH:MM | 서비스 복구 | [이름] |

### 원인 분석
**직접 원인:** [기술적 현상]

**5-Why 분석:**
- Why 1: [현상] → [원인]
- Why 2: [원인] → [더 깊은 원인]
- Why 3: ...
- 근본 원인: [프로세스/설계 결함]

### 재발 방지 대책
| 대책 | 담당 | 기한 | 완료 기준 |
|------|------|------|-----------|
| [구체적 행동] | [이름] | [날짜] | [테스트 가능한 기준] |

### 교훈
- [팀 전체가 공유할 인사이트]

다음 모듈에서는 서버 보안 운영 실무 — 계정 권한 관리, 보안 헤더 설정, TLS 강화를 다룹니다.