장애 관리 입문 — MTTD·MTTR·인시던트 대응 기초

서비스가 다운됐을 때 “지금 뭘 해야 하지?”라고 당황한 적 있나요? 장애 관리는 이런 상황에서 팀이 침착하게 움직일 수 있는 체계를 만드는 것입니다.

장애(인시던트)란?

사용자에게 영향을 주는 예상치 못한 서비스 중단 또는 성능 저하를 인시던트(Incident)라고 합니다.

인시던트 예시:
- 결제가 안 됨 (서비스 중단)
- 로그인 페이지가 30초 걸림 (성능 저하)
- 이미지가 안 불러와짐 (부분 장애)

핵심 지표: MTTD와 MTTR

MTTD (Mean Time To Detect) — 평균 탐지 시간

장애 발생부터 팀이 인지하기까지 걸리는 시간.

나쁜 예: 사용자 신고가 쌓인 뒤에야 인지 → MTTD 30분
좋은 예: 모니터링 알림으로 즉시 인지 → MTTD 2분

MTTR (Mean Time To Recover) — 평균 복구 시간

장애 인지부터 서비스 정상화까지 걸리는 시간.

MTTR = 탐지 시간 + 진단 시간 + 수정 시간 + 배포 시간

목표 기준

지표	좋음	보통	나쁨
MTTD	< 5분	5~30분	> 30분
MTTR	< 30분	30분~2시간	> 2시간

장애 심각도 분류

모든 장애를 동일하게 다루면 안 됩니다. 심각도에 따라 대응 방식이 달라집니다.

등급	상황	대응
P1	전체 서비스 중단, 결제 불가	즉시 모든 사람 소집
P2	핵심 기능 일부 장애	담당팀 즉시 대응
P3	비핵심 기능 이슈	업무 시간 내 처리
P4	경미한 UI 버그	다음 릴리스에 포함

장애 대응 5단계

1. 탐지 (Detect)

모니터링 알림 또는 사용자 신고로 장애를 인지합니다.

2. 선언 (Declare)

“이건 인시던트입니다” 라고 공식 선언하고 Slack 채널을 엽니다. 혼자 조용히 해결하려다 늦어지는 것이 가장 나쁩니다.

3. 완화 (Mitigate)

원인 분석보다 서비스 복구가 먼저입니다.

• 최근 배포가 원인? → 롤백
• 트래픽 급증? → 스케일 아웃
• DB 문제? → 재시작 또는 쿼리 킬

4. 해소 (Resolve)

서비스가 정상 상태로 돌아왔음을 확인하고 공식 종료를 선언합니다.

5. 회고 (Review)

Post-mortem을 작성해 같은 장애가 반복되지 않도록 개선합니다.

지금 당장 시작할 수 있는 것

장애 관리 체계가 없다면 이것부터 시작하세요:

Week 1: Slack에 #incident 채널 만들기
Week 2: 에러율 5% 초과 알림 설정 (Prometheus or Datadog)
Week 3: 핵심 API 런북(Runbook) 1개 작성
Month 2: 온콜 로테이션 도입

다음 단계

• 온콜 프로세스 설계하기 →
• 장애 탐지 & 알림 설계 →
• 장애 대응 플레이북 →