장애 분석 흐름
한 줄 정의
장애 분석 흐름은 사용자 영향부터 확인하고, 메트릭, 트레이스, 로그 순서로 원인 후보를 좁혀 복구와 재발 방지까지 연결하는 절차다.
실무에서 왜 문제 되는가
- 원인부터 찾으려 하면 복구보다 분석이 늦어질 수 있다.
- 영향 범위를 모르면 우선순위와 커뮤니케이션이 흔들린다.
- 최근 변경, 의존성 장애, 자원 포화를 함께 보지 않으면 원인을 오판한다.
- 장애 후 기록이 없으면 같은 문제가 반복된다.
동작 원리
- 사용자 영향과 장애 범위를 확인한다.
- 최근 배포, 설정 변경, 트래픽 급증, 외부 의존성 상태를 확인한다.
- 메트릭으로 latency, error, traffic, saturation 변화를 본다.
- 트레이스로 느리거나 실패한 구간을 확인한다.
- 로그로 구체적인 예외와 상태를 확인한다.
- 우회, 롤백, 차단, 스케일링 같은 복구 조치를 선택한다.
- 회고에서 원인, 탐지, 대응, 예방책을 정리한다.
실무 판단 기준
| 단계 | 질문 | 확인 대상 |
|---|---|---|
| 영향 확인 | 누가 얼마나 영향받는가 | SLI, error rate, CS 문의 |
| 범위 축소 | 특정 API인가 전체인가 | endpoint, instance, region |
| 변경 확인 | 최근 무엇이 바뀌었나 | deploy, config, schema |
| 원인 후보 | 어디서 시간이 쓰이나 | trace, dependency metric |
| 복구 | 가장 빠른 완화책은 무엇인가 | rollback, feature flag, rate limit |
자주 나는 실수
- 사용자 영향 확인 전에 코드 원인부터 찾는다.
- 최근 배포와 설정 변경을 확인하지 않는다.
- 로그 한 줄만 보고 전체 원인을 단정한다.
- 복구 조치와 원인 분석을 구분하지 않는다.
- 장애 후 계측, 알림, runbook을 보완하지 않는다.
확인 방법
- 테스트: 장애 훈련에서 영향 확인부터 복구까지 흐름을 점검한다.
- 로그: error log와 trace id로 실패 조건을 확인한다.
- 메트릭: 장애 시작 시점과 지표 변곡점을 확인한다.
- 트레이스: 가장 긴 span, timeout, retry 구간을 확인한다.
장점과 한계
| 장점 | 한계 |
|---|---|
| 장애 대응 우선순위를 잡기 쉽다 | 충분한 계측이 없으면 분석이 막힌다 |
| 복구와 원인 분석을 분리한다 | 복합 장애는 여러 가설을 병렬로 봐야 한다 |
| 회고와 재발 방지로 이어진다 | 조직의 대응 체계가 함께 필요하다 |
짧은 예제
장애 분석 순서:
1. checkout API 5xx 3% 확인
2. 특정 배포 이후 증가 확인
3. trace에서 Redis timeout span 증가 확인
4. 로그에서 cache fallback 실패 확인
5. 임시로 cache 사용 우회 후 복구
6. timeout, fallback, alert 보완장애 대응에서는 먼저 영향을 줄이고, 이후에 근본 원인을 끝까지 정리한다.
핵심 요약
장애 분석은 사용자 영향 확인에서 시작해야 한다.
메트릭으로 장애 범위와 시점을 확인하고, 트레이스로 지연 구간을 좁힌다.
로그는 구체적인 실패 조건과 예외 원인을 확인하는 데 사용한다.
복구 조치와 근본 원인 분석은 목적이 다르므로 분리해서 진행한다.
장애 후에는 계측, 알림, 대시보드, runbook을 보완해야 한다.
꼬리 질문
- 장애가 발생하면 어떤 순서로 확인할 것인가?
- 복구와 원인 분석을 분리해야 하는 이유는 무엇인가?
- 장애 회고에서 반드시 남겨야 할 내용은 무엇인가?