장애 대응 플레이북 — 인시던트 선언부터 복구까지 절차

장애 중에 “지금 뭘 해야 하지?”를 고민하면 이미 늦습니다. 플레이북은 스트레스 상황에서 판단 부하를 줄이는 사전 합의된 행동 절차입니다.

인시던트 생애주기

[탐지]  →  [선언]  →  [대응]  →  [복구]  →  [회고]
  ↑                                              ↓
  └──────────────── 개선 반영 ───────────────────┘

각 단계에서 “누가, 무엇을, 언제까지” 가 명확해야 합니다.

1단계: 인시던트 선언

알림을 받은 즉시 인시던트 채널을 열고 공식 선언합니다. “혼자 조용히 확인”하는 시간이 MTTR을 가장 많이 낭비합니다.

# Slack 인시던트 선언 템플릿

🚨 [인시던트 선언] P1 - 결제 API 장애

• 발생 시각: 2026-04-03 14:32 KST
• 증상: 결제 완료율 0% (에러율 100%)
• 영향 범위: 전체 결제 사용자
• 인시던트 리더: @sunwoo
• 커뮤니케이션 담당: @jisoo
• 상태 페이지 업데이트: 진행 중

인시던트 심각도 분류

등급	기준	대응 시간	보고 대상
P1	서비스 전체 중단 / 데이터 손실	즉시	C레벨, 전 팀
P2	핵심 기능 부분 장애 (결제, 로그인)	15분 내	팀장, 관련 팀
P3	비핵심 기능 장애 / 성능 저하	1시간 내	팀 내부
P4	경미한 버그 / 시각적 이슈	다음 근무일	담당자

2단계: 역할 분담

세 가지 역할이 겹치지 않아야 혼선이 없습니다.

역할	책임	담당하지 않는 것
인시던트 리더 (IL)	전체 조율, 의사결정, 에스컬레이션	직접 코드 수정
기술 대응자	원인 조사, 수정, 복구 실행	외부 커뮤니케이션
커뮤니케이션 담당	상태 페이지, 이해관계자 업데이트	기술적 판단

인시던트 리더가 코드도 고치면 안 됩니다

IL이 기술 작업에 빠지는 순간 전체 조율 기능이 사라집니다. 소규모 팀이라도 역할을 나누세요. 한 명이 두 역할을 맡더라도 의식적으로 전환해야 합니다.

3단계: 빠른 완화 (Mitigation First)

근본 원인 파악보다 서비스 복구가 먼저입니다.

완화 우선순위:
1. 롤백 (최근 배포가 원인인 경우 가장 빠름)
2. 트래픽 차단 / 피처 플래그 끄기
3. 수동 스케일 아웃
4. 캐시 초기화
5. DB 쿼리 킬 / 연결 재설정

# 배포 롤백
kubectl rollout undo deployment/payment-api
kubectl rollout status deployment/payment-api

# 피처 플래그로 기능 비활성화
curl -X PATCH https://flags.internal/api/v1/flags/new-checkout \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

# 수동 스케일 아웃 (즉각 트래픽 수용)
kubectl scale deployment/payment-api --replicas=10

4단계: 30분 단위 상태 업데이트

장애가 길어질수록 이해관계자가 불안해집니다. 해결이 안 됐더라도 “진행 중”임을 알리는 것이 침묵보다 낫습니다.

# 상태 페이지 업데이트 템플릿

[14:32] 인시던트 시작 - 결제 장애 조사 중
[14:45] 원인 추정: 최근 배포된 payment-api v2.3.1 관련 조사 중
[15:00] 완화 조치 적용 중 - 이전 버전으로 롤백 시도
[15:12] 서비스 복구 확인 중 - 에러율 감소 추세
[15:20] 장애 해소 - 정상 운영 중, 원인 분석 예정

5단계: 복구 확인 기준

“됐나?”를 명확하게 판단하는 기준이 있어야 합니다.

복구 완료 판단 기준 (예시):
✅ 에러율 < 0.5% (5분 연속)
✅ p95 응답 시간 < 500ms (5분 연속)
✅ 합성 모니터링 연속 3회 성공
✅ 영향받은 사용자 재처리 완료 (또는 계획 수립)

복구는 5분 관찰 후 선언

지표가 회복되자마자 선언하면 “반복 장애”로 오인될 수 있습니다. 5분 이상 안정 상태를 유지한 뒤 공식 종료를 선언하세요.

런북(Runbook) 작성 원칙

런북은 새벽 3시에 잠에서 깬 사람도 바로 실행할 수 있어야 합니다.

좋은 런북의 조건:

• 각 단계는 복사-붙여넣기 가능한 명령어
• 예상 소요 시간 명시
• 판단 분기점마다 “YES → 다음 단계”, “NO → 에스컬레이션” 명확히
• 마지막 검토일 및 검토자 표시

## [결제 DB] 커넥션 고갈 런북
최종 검토: 2026-03-15 / @dba-team

### 증상
- 알림: DB connection pool exhausted
- 사용자 증상: "결제 처리 중" 화면에서 멈춤

### 1단계: 현황 파악 (2분)
현재 커넥션 수 확인:
\`\`\`sql
SELECT count(*), state FROM pg_stat_activity GROUP BY state;
\`\`\`
결과 > 100이면 → 2단계 진행
결과 < 100이면 → 다른 원인, 에스컬레이션

### 2단계: 유휴 커넥션 강제 종료 (1분)
\`\`\`sql
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle' AND query_start < NOW() - INTERVAL '5 minutes';
\`\`\`

### 3단계: 에스컬레이션
10분 내 해소 안 되면 → DBA 온콜 (#dba-oncall) 즉시 호출

다음 단계

• 장애 탐지 & 알림 설계 →
• RCA 방법론 →
• Post-mortem 작성 가이드 →