장애를 분류하고 업데이트를 조율하며 대응을 후속 작업으로 전환합니다. — Claude Skill

사후 분석 패턴

비난 없는 사후 분석 구조, 근본 원인 분석 기법, 조치 항목 추적, 카오스 엔지니어링 패턴입니다. 장애 해결 후 또는 회복성 테스트 프로그램을 설계할 때 사용하세요.

비난 없는 사후 분석 구조

핵심 원칙

1. 비난 금지: 개인이 아니라 시스템, 프로세스, 조건에 집중
2. 좋은 의도 가정: 모든 참여자는 당시 사용 가능한 정보로 최선을 다하고 있었음
3. 처벌이 아니라 학습: 목표는 책임 추궁이 아니라 재발 방지
4. 넓게 공유: 사후 분석은 팀 망신이 아니라 조직 학습

사후 분석 문서 템플릿

# 장애 사후 분석: [제목]

**날짜:** [장애 날짜]
**심각도:** P[0-3]
**지속 시간:** [시작 시간]부터 [종료 시간]까지([총 지속 시간])
**장애 지휘자:** [이름]
**작성자:** [이름]
**상태:** [초안 | 검토 | 최종]

## 요약

[무슨 일이 일어났고 사용자 영향이 무엇이었는지 1-2문장으로 설명]

## 영향

- **영향받은 사용자:** [수 또는 비율]
- **지속 시간:** [사용자가 문제를 경험한 시간]
- **매출 영향:** [해당 시]
- **데이터 영향:** [데이터 손실 또는 손상 여부]
- **SLA 영향:** [SLA 위반 여부]

## 타임라인

모든 시간은 [시간대] 기준입니다.

| 시간 | 이벤트 |
|------|-------|
| HH:MM | [첫 신호 / 경보 발생] |
| HH:MM | [온콜 확인] |
| HH:MM | [심각도를 P_로 분류] |
| HH:MM | [핵심 조사 발견 사항] |
| HH:MM | [완화 조치 적용] |
| HH:MM | [문제 해결 확인] |
| HH:MM | [모니터링 안정 확인] |

## 근본 원인

[근본 원인의 상세 설명. 어떤 조건이나 변경이 실패로 이어졌는가?]

## 기여 요인

- [요인 1: 예, 이 실패 모드에 대한 모니터링 누락]
- [요인 2: 예, 트래픽이 높은 기간에 배포]
- [요인 3: 예, 자동 롤백 미설정]

## 잘된 점

- [항목 1: 예, 영향 발생 후 2분 안에 경보가 울림]
- [항목 2: 예, 팀이 상황실에서 효과적으로 조율함]
- [항목 3: 예, 롤백이 매끄럽고 빨랐음]

## 부족했던 점

- [항목 1: 예, 실패한 서비스를 식별하는 데 20분 걸림]
- [항목 2: 예, 이 실패 모드에 대한 런북이 없었음]
- [항목 3: 예, 상태 페이지가 30분 동안 업데이트되지 않음]

## 조치 항목

| ID | 조치 | 담당자 | 우선순위 | 기한 | 상태 |
|----|--------|-------|----------|----------|--------|
| 1 | [조치 설명] | [이름] | P1 | [날짜] | 열림 |
| 2 | [조치 설명] | [이름] | P2 | [날짜] | 열림 |

## 배운 점

[향후 설계, 프로세스, 도구 결정에 반영해야 할 핵심 교훈]

사후 분석 미팅 진행

미팅 전:

• 사후 분석 문서 초안을 작성해 24시간 전에 공유
• 모든 참여자가 정확성을 위해 타임라인을 검토
• 장애 지휘자가 근본 원인 분석을 준비

미팅 중(60-90분):

1. 타임라인 리뷰(15분): 이벤트를 훑고, 오류를 고치고, 빈틈을 채움
2. 근본 원인 논의(20분): 5 Whys 또는 피시본 분석 적용
3. 기여 요인(15분): 무엇이 장애를 더 악화시키거나 해결을 어렵게 만들었는가?
4. 잘된 점(10분): 효과적이었던 실천을 강화
5. 조치 항목(20분): 구체적이고 배정 가능하며 기한이 있는 조치를 정의

미팅 후:

• 24시간 안에 문서 최종화
• 더 넓은 조직에 배포
• 조치 항목을 추적 시스템에 입력
• 조치 항목 완료 상태를 확인하기 위한 후속 리뷰 일정 잡기

근본 원인 분석 기법

5 Whys

증상을 지나 근본 원인까지 내려가기 위해 "왜"를 반복해서 묻습니다.

예시:

문제: 사용자에게 주문 확인 이메일이 중복 발송됨.

왜 1: 이메일 서비스가 확인 이메일을 두 번 보냄.
왜 2: 주문 완료 이벤트가 두 번 발행됨.
왜 3: 주문 서비스가 제한시간 초과 후 재시도함.
왜 4: 메시지 브로커가 부하 상태에서 느리게 확인 응답함.
왜 5: 브로커 디스크가 95% 가득 차서 쓰기 지연이 발생함.

근본 원인: 메시지 브로커의 디스크 사용량 모니터링이나 경보가 없었음.
조치: 디스크 사용량 80% 임곗값 경보 + 자동 확장 추가.

가이드라인:

• 고칠 수 있는 시스템적 원인(프로세스, 도구, 설계)에 도달하면 멈춤
• "휴먼 에러"에서 멈추지 말고, 시스템이 왜 그 오류를 허용했는지 질문
• 일부 장애에는 여러 근본 원인이 있으므로 각 분기마다 5 Whys를 수행
• 답은 추측이 아니라 사실이어야 함

피시본 다이어그램(이시카와)

기여 요인을 표준 차원별로 분류합니다.

                    ┌─ 사람: 온콜이 서비스를 잘 모름
                    ├─ 프로세스: 롤백 런북이 없었음
중복 이메일 ───────├─ 기술: 이메일 발송에 멱등성이 없음
                    ├─ 환경: 브로커 디스크 95%
                    ├─ 모니터링: 디스크 사용량 경보 없음
                    └─ 외부: 상위 트래픽 급증

표준 범주:

• 사람: 지식 공백, 인력 배치, 커뮤니케이션
• 프로세스: 누락된 런북, 불명확한 절차, 승인 병목
• 기술: 버그, 누락된 기능, 아키텍처 공백
• 환경: 인프라, 용량, 설정
• 모니터링: 누락된 경보, 잘못된 임곗값, 관찰 가능성 공백
• 외부: 서드파티 장애, 트래픽 급증, 공격

장애 트리 분석

실패에서 거꾸로 추적해 가능한 모든 원인을 식별합니다.

최상위 이벤트: 서비스 중단
├── AND: 로드 밸런서 실패
│   ├── OR: 설정 오류
│   └── OR: 상태 확인 설정 오류
└── AND: 장애 조치가 작동하지 않음
    ├── OR: 장애 조치가 설정되지 않음
    └── OR: 장애 조치 상태 확인도 실패함

사용 시점: 여러 실패가 상호작용해 5 Whys만으로 부족한 복잡한 장애.

조치 항목 추적

조치 항목 품질 기준

모든 조치 항목은 다음을 만족해야 합니다.

• 구체적: 무엇을 할지 명확히 설명("모니터링 개선" 금지)
• 배정 가능: 팀이 아니라 한 명의 담당자
• 기한 있음: "언젠가"가 아니라 기한
• 검증 가능: 완료 정의가 명확함
• 우선순위 있음: P1(다음 온콜 교대 전), P2(이번 스프린트), P3(이번 분기)

조치 항목 범주

추적 및 후속 조치

• 모든 조치 항목을 즉시 팀의 이슈 추적기에 입력
• 추적 가능성을 위해 postmortem과 장애 ID 태그 지정
• 팀 스탠드업에서 열린 사후 분석 조치 항목을 매주 리뷰
• 기한이 지난 P1 항목은 엔지니어링 매니저에게 에스컬레이션
• 조치 항목은 검증 완료된 경우에만 닫기("코드 병합"만으로 닫지 않음)

조치 항목 안티패턴

카오스 엔지니어링 패턴

장애 주입

회복성을 검증하기 위해 의도적으로 실패를 도입합니다.

흔한 장애 유형:

장애 주입 체크리스트

• 가설 정의: "[장애]가 발생하면 [X]가 일어날 것이라고 믿는다"
• 폭발 반경 제한(단일 인스턴스, 카나리, 스테이징)
• 롤백 장치 준비(실험용 kill switch)
• 효과를 관찰할 모니터링 준비
• 팀이 실험 실행 사실을 알고 있음
• 중단 기준 정의(실제 사용자 영향이 N%를 넘으면 중단)

게임 데이

팀이 모의 장애를 상대로 장애 대응을 연습하는 구조화된 훈련입니다.

게임 데이 계획 템플릿:

## 게임 데이: [제목]

**날짜:** [날짜와 시간]
**지속 시간:** [예상 지속 시간]
**진행자:** [이름]
**참여자:** [팀원]

### 시나리오
[모의 장애 설명]

### 목표
- [ ] 경보가 [N]분 안에 장애를 탐지하는지 검증
- [ ] 팀이 올바른 심각도로 분류할 수 있는지 검증
- [ ] 완화 조치를 [N]분 안에 적용할 수 있는지 검증
- [ ] 커뮤니케이션 프로토콜이 지켜지는지 검증

### 기본 규칙
- 이것은 평가가 아니라 연습입니다
- 진행자가 시나리오 진행을 통제합니다
- 실제 운영 환경 영향이 감지되면 누구나 "중지"를 외칠 수 있습니다
- 모든 관찰을 실시간으로 문서화합니다

### 디브리프 질문
1. 경보가 예상대로 울렸는가?
2. 올바른 팀이 충분히 빨리 참여했는가?
3. 런북은 충분했는가?
4. 실제 장애라면 무엇을 다르게 했을까?

게임 데이 주기:

• 중요 서비스는 분기마다
• 주요 아키텍처 변경 후
• 새 온콜 엔지니어 온보딩 시
• P0 장애 후(수정 사항 테스트)

회복성 테스트 방법론

회복성 성숙도 수준

회복성 테스트 체크리스트

각 중요 서비스에 대해 다음을 검증하세요.

• 단일 인스턴스 실패: 인스턴스 하나가 죽어도 서비스가 복구됨
• 의존성 제한시간 초과: 서비스가 느린 의존성을 우아하게 처리함
• 의존성 중단: 의존성이 중단되어도 서비스가 충돌하지 않고 성능 저하됨
• 네트워크 분리: 서비스가 스플릿 브레인 시나리오를 처리함
• 부하 급증: 평소의 3배 트래픽에서 부하를 차단하거나 확장함
• 디스크 가득 참: 충돌 전에 경보를 울리고 성능 저하됨
• 설정 오류: 잘못된 설정에서 명확한 오류와 함께 빠르게 실패함
• 롤백: 5분 안에 이전 버전을 배포할 수 있음
• 데이터 손상: 지난 분기 안에 백업 복원이 테스트됨

정상 상태 가설

카오스 실험을 실행하기 전에 "정상"이 무엇인지 정의하세요.

정상 상태:
- 요청 성공률 > 99.9%
- p99 지연 시간 < 200ms
- 오류율 < 0.1%
- 울리는 경보 없음

실험: 서비스 인스턴스 3개 중 1개 종료

가설: 장애 주입 후 60초 안에 정상 상태 지표가
      기준선의 10% 이내로 유지된다.

중단 조건: 오류율이 30초 넘게 5%를 초과한다.

---

name: incident-response description: 장애 분류, 연쇄 장애 예방, 사후 분석 방법론입니다. 운영 환경 장애를 처리하거나, 회복성 패턴을 설계하거나, 카오스 엔지니어링 실험을 수행할 때 사용합니다. keywords:

• incident response
• outage
• postmortem
• triage
• incident
• response

---

장애 대응

탐지부터 사후 분석까지 구조화된 장애 관리와, 연쇄 실패를 예방하고 차단하기 위한 회복성 패턴입니다.

사용 시점

• 운영 환경 장애 진행 중(중단, 성능 저하, 데이터 손실)
• 서킷 브레이커, 벌크헤드, 대체 경로 전략 설계
• 카오스 엔지니어링 실험 수행 또는 계획
• 사후 분석 문서 작성 또는 검토
• 온콜 절차와 에스컬레이션 경로 수립

다음 경우에는 피하세요.

• 문제가 운영 환경 영향이 없는 개발 중 버그인 경우
• 일반 시스템 아키텍처 설계(대신 system-design 사용)

빠른 참조

장애 대응 작업 흐름

1단계: 탐지

• 경보가 울리거나 사용자 보고가 접수됨
• 문제가 실제인지 확인(오탐 아님)
• 영향받은 서비스와 사용자 영향 범위 식별

2단계: 분류

• 심각도 분류(P0-P3)
• 장애 지휘자 지정
• 커뮤니케이션 채널 개설(상황실, Slack 채널)
• 상태 페이지 업데이트 시작

3단계: 차단

• 출혈을 멈춤: 롤백, 기능 플래그, 트래픽 전환
• 연쇄 장애 예방: 서킷 브레이커, 부하 차단, 벌크헤드 격리
• 커뮤니케이션: P0/P1은 15분마다 이해관계자 업데이트

4단계: 해결

• 수정 구현(먼저 최소 실행 가능한 수정)
• 시간이 허락하면 스테이징에서 검증
• 모니터링과 롤백 계획을 준비한 상태로 배포
• 지표가 기준선으로 돌아오는지 확인해 복구 검증

5단계: 사후 분석

• 48시간 안에 타임라인 문서화
• 모든 참여자와 비난 없는 리뷰 진행
• 근본 원인과 기여 요인 식별
• 담당자와 기한이 있는 조치 항목 지정
• 배운 점을 바탕으로 런북과 경보 업데이트

심각도 프레임워크

출력

• 장애 타임라인과 심각도 분류
• 수행한 차단 조치
• 조치 항목이 포함된 사후 분석 문서
• 업데이트된 런북과 경보 규칙

흔한 실수

• 심각도 분류를 건너뛰고 모든 것을 P0로 다룸
• 롤백 계획 없이 변경함
• 이해관계자에게 상태를 알리는 것을 잊음
• 시스템 문제를 식별하지 않고 책임을 묻는 사후 분석 작성
• 사후 분석 조치 항목을 후속 조치하지 않음

분류 프레임워크

Production 장애를 위한 심각도 분류, 연쇄 장애 예방, 커뮤니케이션 프로토콜, 에스컬레이션 경로입니다. 진행 중인 장애 대응이나 장애 대응 절차를 수립할 때 사용하세요.

심각도 분류(P0-P3)

P0 -- 치명적

정의: 전체 사용자에게 영향을 주는 완전한 서비스 중단, 진행 중인 데이터 손실, 보안 침해입니다.

예시:

• Production 데이터베이스에 접근할 수 없음
• 인증 서비스가 완전히 중단됨
• 진행 중인 데이터 손상 또는 손실
• 유출이 확인된 보안 침해
• 결제 처리가 중단됨

P1 -- 높음

정의: 주요 기능이 중단되었거나 큰 사용자 집합에 중대한 성능 저하가 발생했습니다.

예시:

• 한 지역에서 결제 처리가 실패함
• 검색 기능이 쿼리의 20% 이상에서 오류를 반환함
• API 지연 시간이 평소보다 10배 높음
• 특정 OS 버전에서 모바일 앱이 실행 즉시 충돌함

P2 -- 중간

정의: 우회 방법이 있는 성능 저하 또는 부분 기능 손실입니다.

예시:

• 비핵심 엔드포인트의 지연 시간이 상승함(평소의 2-3배)
• 백그라운드 작업 처리가 지연됨
• 비핵심 서드파티 연동이 중단됨
• 보고서 생성이 느리지만 작동은 함

P3 -- 낮음

정의: 사용자 영향이 최소인 작은 이슈입니다. 우회 방법이 있거나 외관 문제입니다.

예시:

• 예외 사례에서 UI 렌더링 오류
• 비핵심 cron 작업 실패(재시도 예정)
• 내부 도구 대시보드 로드 지연
• 기능에 영향을 주지 않는 작은 로깅 오류

심각도 결정 트리

데이터가 손실되거나 손상되고 있는가?
├─ 예 → P0
└─ 아니오
   보안 침해가 있는가?
   ├─ 예 → P0
   └─ 아니오
      기본 서비스가 완전히 중단되었는가?
      ├─ 예 → P0
      └─ 아니오
         많은 사용자에게 주요 기능이 중단되었는가?
         ├─ 예 → P1
         └─ 아니오
            성능이 크게 저하되었는가?
            ├─ 예 → P2
            └─ 아니오 → P3

연쇄 장애 예방

서킷 브레이커

실패 중인 의존성을 자동으로 더 이상 호출하지 않아 연쇄 장애를 예방합니다.

구현 체크리스트:

• 모든 외부 의존성에 서킷 브레이커가 있음
• 실패 임곗값이 의존성별로 조정되어 있음(모든 곳에 같은 값 사용 금지)
• OPEN 상태가 의미 있는 대체 경로를 반환함(캐시 데이터, 성능 저하 응답, 오류)
• HALF-OPEN 탐침이 가벼움(전체 요청이 아니라 상태 확인)
• 서킷 브레이커 상태를 관찰할 수 있음(지표, 대시보드)
• 서킷 브레이커가 열리면 경보가 울림

설정 템플릿:

의존성: [서비스 이름]
실패 임곗값: [T]초 동안 [N]회 실패
재설정 제한시간: [T]초
대체 경로: [캐시 응답 | 오류 메시지 | 성능 저하 모드]

벌크헤드 격리

한 영역의 장애가 다른 영역의 리소스까지 고갈시키지 않도록 리소스를 분리합니다.

패턴:

• 스레드 풀 격리: 의존성별 별도 스레드 풀
• 커넥션 풀 격리: 하위 서비스별 전용 커넥션 풀
• 프로세스 격리: 중요 워크로드와 비핵심 워크로드를 별도 프로세스로 분리
• 인프라 격리: 중요 워크로드와 배치 워크로드를 별도 클러스터로 분리

체크리스트:

• 중요 경로 의존성에 전용 리소스 풀이 있음
• 비핵심 백그라운드 작업이 중요 요청 처리를 굶기지 않음
• 풀별 리소스 한도가 설정되어 있음(최대 커넥션, 최대 스레드)
• 풀 고갈은 조용한 대기가 아니라 경보를 발생시킴

부하 차단

고우선순위 트래픽의 용량을 보존하기 위해 낮은 우선순위 작업을 의도적으로 버립니다.

우선순위 등급:

구현:

• 요청 우선순위 헤더 또는 경로 기반 분류 사용
• 차단한 요청에는 Retry-After 헤더와 함께 503 반환
• 차단율을 지표로 모니터링(차단율 > 0이면 경보)

우아한 성능 저하 전략

커뮤니케이션 프로토콜

상태 페이지 업데이트

상태 페이지 항목 템플릿:

[타임스탬프] - [상태: 조사 중 | 원인 확인 | 모니터링 중 | 해결됨]

영향: [사용자가 볼 수 있는 영향의 짧은 설명]
현재 상태: [우리가 아는 내용과 현재 수행 중인 일]
다음 업데이트: [다음 업데이트 예상 시점]

업데이트 주기:

• P0: 해결될 때까지 15분마다
• P1: 해결될 때까지 30분마다
• P2: 시작 시와 해결 시
• P3: 해결 시에만

이해관계자 알림 템플릿

제목: [P0/P1] [서비스] - [짧은 영향 설명]

심각도: P[0-3]
시작 시간: [ISO 8601 타임스탬프]
영향: [누가 어떤 영향을 받는지]
현재 상태: [우리가 아는 내용]
수행한 조치: [지금까지 수행한 내용]
예상 복구 시간: [알고 있으면 기재, 아니면 "조사 중"]
다음 업데이트: [시점]
장애 지휘자: [이름]
상황실: [링크/채널]

내부 커뮤니케이션 규칙

1. 단일 진실 공급원: 모든 업데이트는 개인 메시지가 아니라 장애 채널을 통해 전달
2. 추측이 아니라 사실: 아는 내용을 공유하고, 추정은 추정이라고 표시
3. 모든 것에 타임스탬프: 모든 조치와 관찰에 타임스탬프 기록
4. 비난 금지: 누가 일으켰는지가 아니라 무엇이 일어났는지에 집중
5. 명확한 인수인계: 교대 시 맥락을 명시적으로 인수인계

에스컬레이션 경로

에스컬레이션 트리거

에스컬레이션 체크리스트

• 1차 온콜이 호출되고 확인함
• 5분 안에 확인이 없으면 2차 온콜 호출
• 장애 지휘자 지정
• 관련 팀 리드에게 알림
• 상태 페이지 업데이트
• 고객 지원팀에 대화 가이드 제공
• 경영진 이해관계자에게 알림(P0/P1만)

온콜 책임

장애 중:

• 5분 안에 호출 확인
• 심각도를 평가하고 장애 채널 개설
• 조사를 시작하고 발견 사항을 실시간 문서화
• 필요 시 다른 팀과 조율
• 요구된 주기에 맞춰 상태 업데이트 제공

장애 후:

• 모니터링으로 해결이 확인되었는지 보장
• 장애 타임라인 초안 작성
• 필요 시 사후 분석 일정 잡기
• 새로 배운 내용을 런북에 업데이트
• 교대가 장애 중 끝나면 다음 온콜에게 인수인계