장애 대응과 인시던트 관리: 온콜부터 포스트모템까지

탐지 (Detection)
    ↓
트리아지 (Triage)
    ↓
대응 (Response)
    ↓
완화 (Mitigation)
    ↓
복구 (Recovery)
    ↓
사후 분석 (Post-Mortem)
    ↓
개선 (Improvement)

┌─────────────────────────────────────┐
│        인시던트 커맨더 (IC)           │
│     의사결정 총괄, 외부 커뮤니케이션   │
└───────────┬─────────────────────────┘
            │
    ┌───────┼───────┬────────────┐
    ▼       ▼       ▼            ▼
 ┌──────┐ ┌──────┐ ┌────────┐ ┌────────────┐
 │기술   │ │커뮤니│ │운영    │ │스크라이브  │
 │리드   │ │케이션│ │리드    │ │(Scribe)   │
 │(Tech │ │리드  │ │(Ops   │ │ 타임라인   │
 │ Lead)│ │(Comms│ │ Lead) │ │ 기록      │
 └──────┘ │Lead) │ └────────┘ └────────────┘
           └──────┘

1. 알림 수신 → 온콜 엔지니어 확인 (5분 이내)
2. 초기 평가 → 심각도 분류 (SEV1-4)
3. SEV1/SEV2 → 인시던트 선언 → 전쟁방(War Room) 개설
4. 역할 배정 → IC, Tech Lead, Comms Lead, Scribe
5. 조사 및 완화 → 근본 원인 발견 전이라도 증상 완화 우선
6. 커뮤니케이션 → 정기적 상태 업데이트 (15-30분 간격)
7. 해결 → 서비스 정상 확인 → 인시던트 종료 선언
8. 사후 분석 → 48-72시간 이내 포스트모템 작성

# Runbook: 데이터베이스 연결 고갈 (DB Connection Pool Exhaustion)
 
## 알림 조건
- 활성 DB 연결 수 > 최대 풀 크기의 90%
 
## 초기 진단
1. 현재 활성 연결 수 확인: `SELECT count(*) FROM pg_stat_activity;`
2. 오래 실행 중인 쿼리 확인: `SELECT * FROM pg_stat_activity WHERE state = 'active' AND duration > interval '30 seconds';`
3. 연결 대기 큐 확인
 
## 완화 조치
1. 오래 실행 중인 쿼리 종료: `SELECT pg_cancel_backend(pid);`
2. 필요시 유휴 연결 정리
3. 연결 풀 크기 일시적 증가 (PgBouncer 설정)
 
## 근본 원인 조사
- 느린 쿼리 로그 분석
- 최근 배포 이력 확인
- 트래픽 급증 여부 확인
 
## 에스컬레이션
- 30분 내 해결 불가 시: DBA 팀 호출

# 포스트모템: [인시던트 제목]
 
## 요약
- 날짜: YYYY-MM-DD
- 심각도: SEV1
- 영향 시간: HH:MM ~ HH:MM (총 X분)
- 영향 범위: Y% 사용자의 Z 기능
 
## 타임라인
| 시간 | 이벤트 |
|------|--------|
| 14:00 | 배포 v2.3.1 시작 |
| 14:05 | 에러율 1% → 15% 급증 |
| 14:07 | 알림 발송, 온콜 엔지니어 확인 |
| 14:10 | 인시던트 선언 (SEV1), IC 배정 |
| 14:15 | 배포 롤백 결정 |
| 14:20 | 롤백 완료, 에러율 정상화 |
 
## 근본 원인
데이터베이스 마이그레이션 스크립트가 인덱스를 삭제하면서
주요 쿼리의 응답 시간이 10배 증가, 연결 풀 고갈로 이어짐
 
## 기여 요인
- 마이그레이션 스크립트 리뷰 부재
- 카나리 배포 없이 전체 배포
- DB 커넥션 풀 모니터링 알림 미설정
 
## 교훈
- 잘된 점: 빠른 롤백 결정 (10분 이내)
- 개선할 점: 마이그레이션 리뷰 프로세스, 카나리 배포
 
## 액션 아이템
| 번호 | 조치 | 담당자 | 기한 | 우선순위 |
|------|------|--------|------|----------|
| 1 | DB 마이그레이션 리뷰 체크리스트 작성 | DBA팀 | 1주 | P1 |
| 2 | 카나리 배포 필수화 | DevOps | 2주 | P1 |
| 3 | DB 커넥션 풀 알림 추가 | SRE | 1주 | P2 |

왜 서비스가 중단되었는가?
  → 데이터베이스 연결 풀이 고갈되었기 때문
왜 연결 풀이 고갈되었는가?
  → 쿼리 응답 시간이 10배 증가하여 연결이 반환되지 않았기 때문
왜 쿼리 응답 시간이 증가했는가?
  → 인덱스가 삭제되어 Full Table Scan이 발생했기 때문
왜 인덱스가 삭제되었는가?
  → 마이그레이션 스크립트에 DROP INDEX가 포함되어 있었기 때문
왜 리뷰에서 발견되지 않았는가?
  → 마이그레이션 스크립트 리뷰 프로세스가 없었기 때문 (근본 원인)

MTBF = MTTF + MTTR
 
가용성 = MTTF / MTBF = MTTF / (MTTF + MTTR)
 
예시: MTTF = 720시간, MTTR = 0.5시간
가용성 = 720 / 720.5 = 99.93%

가정: "6개월 후, 이 시스템에서 대규모 장애가 발생했다."
질문: "무엇이 잘못되었을까?"
 
팀원들이 독립적으로 실패 시나리오를 작성하고 공유:
- "DB 샤드 간 불균형으로 핫스팟 발생"
- "서드파티 결제 API 장시간 장애"
- "캐시 스탬피드로 DB 과부하"

DevOps = 문화와 철학 (무엇을 해야 하는가)
SRE    = 구체적 구현 (어떻게 해야 하는가)
 
"SRE는 DevOps 철학의 특정 구현이다" - Google