장애 대응 — 인시던트 관리, 포스트모템, SLI와 SLO와 SLA

서버가 터졌습니다. 그런데 누가 무엇을 해야 하는지 아무도 모릅니다. 이런 상황, 어떻게 대비할 수 있을까요?

장애는 반드시 발생합니다. 중요한 건 장애를 완전히 막는 게 아니라, 빠르게 감지하고 복구하고 재발을 방지하는 체계를 갖추는 것입니다.

이게 뭔가요?

• 인시던트(Incident): 서비스에 영향을 주는 계획되지 않은 이벤트. 서버 다운, 응답 지연, 데이터 유실 등
• 인시던트 관리(Incident Management): 인시던트를 감지 → 대응 → 복구 → 사후 분석하는 전체 프로세스
• 포스트모템(Postmortem): 장애 복구 후 원인과 대응 과정을 분석하고 재발 방지책을 도출하는 문서
• SLI(Service Level Indicator): 서비스 품질을 측정하는 구체적 지표
• SLO(Service Level Objective): SLI의 목표 범위
• SLA(Service Level Agreement): 고객과 맺는 공식 계약 (SLO 미달 시 보상 포함)

왜 필요한가요?

장애 상황에서 프로세스가 없으면 이런 일이 벌어집니다:

• 누가 담당인지 모름 → 모두가 우왕좌왕
• 임시 조치만 하고 근본 원인은 방치 → 같은 장애 반복
• "그때 그 장애 원인이 뭐였지?" → 기록이 없어서 재학습 불가
• 고객에게 "99.9% 가용성 보장"이라고 했는데, 실제 측정을 안 하고 있음

체계적인 장애 대응은 평균 복구 시간(MTTR)을 줄이고, 동일한 장애의 재발을 막고, 팀의 학습을 촉진합니다.

어떻게 동작하나요?

1. 인시던트 관리 프로세스

[감지] → [분류] → [대응] → [복구] → [사후 분석]

감지(Detection):

• 모니터링 알림 (Grafana, PagerDuty, Datadog 등)
• 사용자 신고
• 자동화된 헬스 체크 실패

분류(Classification):

대응 역할:

인시던트 커맨더(IC): 전체 조율, 의사결정
  ├── 기술 리드: 원인 분석 및 수정
  ├── 커뮤니케이션 리드: 고객/경영진 상태 전달
  └── 기록자: 타임라인 기록

복구 원칙:

1단계: 완화(Mitigate) — 서비스 정상화가 최우선
  → 롤백, 트래픽 우회, 긴급 패치
  → 근본 원인 분석은 나중에

2단계: 근본 원인 분석(Root Cause Analysis)
  → 복구 후 진행
  → 포스트모템으로 연결

2. 포스트모템 작성법

Google SRE 팀이 확립한 Blameless(비난 없는) 포스트모템 형식:

## 인시던트 요약
- 날짜: 2027-01-15
- 심각도: P1
- 영향: 주문 API 30분간 500 에러 반환
- 감지: Grafana 에러율 알림
- 근본 원인: DB 커넥션 풀 고갈

## 타임라인
- 14:00 — 배포 완료 (신규 기능에 N+1 쿼리 포함)
- 14:15 — DB 커넥션 풀 사용률 90% 알림
- 14:20 — 주문 API 500 에러 발생, P1 선언
- 14:25 — 인시던트 커맨더 배정, 이전 버전으로 롤백 시작
- 14:35 — 롤백 완료, 서비스 정상화
- 14:50 — 모니터링 확인 후 인시던트 종료

## 근본 원인
신규 기능의 주문 목록 조회에서 N+1 쿼리가 발생.
주문 건수가 많은 사용자의 요청이 DB 커넥션을 장시간 점유하여
풀이 고갈됨.

## 잘된 점
- 알림이 5분 이내에 발생하여 빠른 감지
- 롤백 프로세스가 자동화되어 있어 10분 내 복구

## 개선할 점
- N+1 쿼리 감지가 코드 리뷰에서 누락됨
- 커넥션 풀 고갈 시 서킷 브레이커가 없었음

## 액션 아이템
- [ ] N+1 쿼리 감지 정적 분석 규칙 추가 (담당: 홍길동, 기한: 1/22)
- [ ] DB 커넥션 풀 서킷 브레이커 도입 (담당: 김철수, 기한: 1/29)
- [ ] 스테이징 환경에서 부하 테스트 의무화 (담당: 이영희, 기한: 2/5)

핵심 원칙: Blameless(비난 없는) 문화

• "누가 실수했나"가 아니라 "시스템이 왜 이 실수를 허용했나"에 집중
• 사람을 탓하면 장애를 숨기게 되고, 시스템을 탓하면 재발을 방지할 수 있음

3. SLI, SLO, SLA

이 세 개념은 계층적으로 연결됩니다:

SLA (계약) ← 고객과의 약속, 위반 시 보상
  └── SLO (목표) ← 내부 목표, SLA보다 약간 엄격
       └── SLI (지표) ← 실제 측정값

SLI — 무엇을 측정하나?

가용성 SLI = 성공한 요청 수 / 전체 요청 수
          = 99,700 / 100,000
          = 99.7%

지연 시간 SLI = p99 응답 시간
            = 200ms (전체 요청의 99%가 200ms 이내)

에러율 SLI = 5xx 응답 수 / 전체 응답 수
          = 30 / 100,000
          = 0.03%

SLO — 목표를 어떻게 잡나?

SLO: 월간 가용성 99.9%

→ 한 달(30일) 기준 허용 다운타임:
  99.9% → 43.2분
  99.95% → 21.6분
  99.99% → 4.3분

에러 예산(Error Budget):

SLO를 뒤집으면 "허용 가능한 장애 시간"이 나옵니다.

SLO: 99.9% → 에러 예산: 0.1% (월 43분)

에러 예산이 남아 있으면 → 새 기능 배포 가능
에러 예산이 소진되면 → 안정성 작업에 집중 (새 기능 배포 중단)

이 개념이 중요한 이유는, "100%를 목표로 하지 않겠다"는 현실적인 합의이기 때문입니다. 100% 가용성은 비용이 무한대로 수렴합니다.

SLA — 계약으로 연결:

SLO: 99.95% (내부 목표, 더 엄격)
SLA: 99.9%  (고객 계약, 약간 여유)

→ SLO를 지키면 SLA는 자연스럽게 충족
→ SLA 위반 시 크레딧 반환 등 보상 조항 발동

자주 헷갈리는 포인트

SLO와 SLA의 차이가 뭔가요?

• SLO: 팀 내부의 목표. 위반해도 외부 보상은 없지만, 에러 예산 소진으로 배포가 제한됨
• SLA: 고객과의 공식 계약. 위반하면 크레딧 반환, 위약금 등 법적 효력

보통 SLO를 SLA보다 살짝 높게 잡아서 버퍼를 둡니다.

포스트모템을 매번 써야 하나요?

모든 인시던트에 풀 포스트모템을 쓸 필요는 없습니다. 기준을 정하면 됩니다:

• P1, P2: 반드시 포스트모템 작성
• P3: 간소화된 포스트모템 (타임라인 + 액션 아이템만)
• P4: 이슈 티켓으로 관리

MTTR, MTTD, MTBF?

• MTTD(Mean Time To Detect): 장애 발생 → 감지까지 걸린 시간
• MTTR(Mean Time To Recover): 장애 감지 → 복구까지 걸린 시간
• MTBF(Mean Time Between Failures): 장애 사이의 평균 간격

MTTD를 줄이려면 → 모니터링과 알림 강화
MTTR을 줄이려면 → 롤백 자동화, 런북 정비
MTBF를 늘리려면 → 근본 원인 해결, 카오스 엔지니어링

9가 하나 더 붙으면 비용이 얼마나 늘어나나요?

대략적으로 9가 하나 추가될 때마다 비용이 10배 늘어난다고 합니다. 99.9% → 99.99%로 올리려면 중복 인프라, 멀티 리전, 자동 페일오버 등이 필요합니다. 비즈니스 가치에 맞는 적절한 수준을 선택하는 게 핵심입니다.

정리

• 인시던트 관리는 감지 → 분류 → 대응 → 복구 → 사후 분석의 체계적 프로세스
• 포스트모템은 비난 없이(Blameless) 근본 원인을 분석하고 재발 방지 액션 아이템을 도출하는 문서
• SLI는 측정 지표, SLO는 내부 목표, SLA는 고객 계약 — 계층적으로 연결됨
• 에러 예산은 "허용 가능한 장애"를 정량화하여, 기능 개발과 안정성 작업의 균형을 잡는 도구
• MTTR을 줄이는 것이 MTBF를 늘리는 것보다 현실적으로 더 효과적

References

• Google SRE Book
• Google SRE Workbook - Postmortem Culture
• Atlassian - Incident Management
• Google SRE Book - Service Level Objectives