장애 대응 시나리오
경고 알림이 울렸을 때 "어디부터 봐야 할지"를 매번 즉흥으로 판단하면 대응이 느려집니다. 이 가이드는 장애 대응 담당자가 감지부터 복구, 사후 분석까지 일관된 흐름으로 수행할 수 있도록 WhaTap의 주요 메뉴를 단계별로 어떻게 엮어 쓰는지 정리합니다.
- 장애 대응 담당자를 맡고 있거나 앞으로 맡을 엔지니어
- 장애 대응 플레이북을 팀에 정착시키고 싶은 리드, SRE
- "알림은 받는데 그다음 뭘 봐야 할지 모르겠다"는 팀원
사전 준비
다음 Quick Win 3종이 완료된 상태여야 실전 운영이 가능합니다.
- 첫 경고 알림 붙이기. 기본 알림 규칙
- 팀과 대시보드 같이 보기. 팀 공용 대시보드 + 권한
- 팀별 알림 라우팅 설정하기. 태그 기반 알림 라우팅
장애 대응 5단계
① 감지 (Detect) → ② 영향 범위 (Scope) → ③ 원인 분석 (Root Cause)
↓
④ 복구 (Mitigate) → ⑤ 사후 분석 (Postmortem)
① 감지, 알림 확인
목표
알림이 실제 이상 상황을 나타내는지 1분 안에 판단
- Slack, Email, SMS, 앱으로 받은 알림 메시지에서 다음을 확인:
- 레벨 (Critical / Warning)
- 프로젝트와 에이전트 이름
- 어떤 이벤트 규칙이 발동했는지 (예를 들어 "CPU 사용률 임계값 초과")
- 알림 메시지의 딥링크를 클릭해 WhaTap 화면으로 바로 진입하세요.
잦은 스파이크 같은 오탐이면 이벤트 규칙의 지속 시간 조건을 올리세요 (예를 들어 1분 → 5분). 반복되는 오탐을 방치하면 팀이 알림을 신뢰하지 않습니다.
② 영향 범위 파악, 얼마나 퍼졌나
목표
몇 개 에이전트, 서비스, 트랜잭션이 영향받았는지 2분 안에 확인
사용할 메뉴는 다음과 같습니다.
애플리케이션 대시보드 또는 팀 Flexboard
- 애플리케이션 대시보드에서 다음을 한눈에 확인합니다.
- Apdex가 급락했는가
- TPS가 비정상적으로 낮거나 높은가
- 평균 응답 시간이 튀었는가
- 에러율 증가 여부
- 여러 에이전트가 함께 이상이면 인프라 및 의존성 문제 가능성 ↑ (DB, 네트워크 등)
- 특정 에이전트만 이상이면 해당 노드 및 인스턴스 문제 가능성 ↑
최근 배포가 있었는지 먼저 확인하세요. 배포 직후 이상이면 롤백이 가장 빠른 복구일 때가 많습니다.
③ 원인 분석, 어디서 느려졌나
목표
문제가 발생한 구간(코드, SQL, 외부 호출, 리소스)을 식별
사용할 메뉴는 다음과 같습니다.
히트맵 트랜잭션 → 트랜잭션 트레이스 → (필요시) 액티브 스택
- 히트맵 트랜잭션에서 느려진 시간대의 점 뭉침을 드래그해서 선택하세요.
- 색상, 위치로 패턴을 먼저 파악하세요: 특정 시간에만 느린가, 전체적으로 느린가.
- 선택한 트랜잭션 중 가장 느렸던 것을 클릭해 트랜잭션 트레이스 화면으로 진입하세요.
- 호출 관계: 어느 메서드, SQL, HTTP 호출에서 시간이 소요되는가
- 스택 샘플: 어느 코드 위치에서 대기했는가
- DB가 의심되면 DB 연결 상태와 Slow SQL을 동시에 확인하세요.
- GC, 메모리가 의심되면 힙 메모리와 액티브 스택을 확인하세요.
- 스레드 교착이나 블로킹이 의심되면 인스턴스 성능 관리의 스레드 목록·덤프를 확인하세요 (인 스턴스 성능 관리 활용).
AI 분석으로 단축하기
트레이스, 스택을 사람이 해석하는 데 시간이 오래 걸릴 때, WhaTap의 AI 분석 기능으로 1차 가설을 빠르게 잡을 수 있습니다.
- AI 액티브 스택 분석. 액티브 스택 화면에서 의심 스택을 선택하면 AI가 병목 구간, 대기 원인을 자연어로 요약합니다. 스레드 덤프를 읽을 줄 몰라도 "어느 스레드가 어디서 막혀 있는지"를 설명합니다. 특히 GC, 락, IO 대기 구분에 유용합니다.
- AI 브라우저 에러 스택 분석. 프론트 에러 추적 시 AI가 에러 스택을 해석해 코드 레벨 원인 위치와 대응 방향을 제안합니다.
- WhaTap AI 챗봇 / MCP. 자연어로 "지금 이 DB 커넥션 풀 수치가 정상 범위인가?", "이 메트릭이 급증하면 어떻게 대응?" 같은 질문을 던져 문서, 가이드, 유사 사례 기반 답변을 받을 수 있습니다 (현재 베타, 한국어 지원).
AI 분석 결과는 1차 가설로 활용하세요. 최종 판단은 실제 트레이스, 스택, 로그를 교차 확인해야 합니다. 특히 비즈니스 맥락(최근 배포, 트래픽 이벤트)은 AI가 모릅니다.
관련 심화 가이드는 다음과 같습니다.
트레이스 하나는 "사례"입니다. 패턴을 확인하려면 같은 시간대의 여러 트레이스를 비교하세요. 한 트레이스의 특징이 다른 트레이 스에도 보이면 공통 원인, 아니면 개별 이슈입니다.
④ 복구, 응급 처치
목표
사용자 영향을 최소화하는 임시 조치 수행
원인별 기본 조치는 다음과 같습니다.
| 원인 유형 | 빠른 복구 |
|---|---|
| 최근 배포 이슈 | 이전 버전으로 롤백 |
| DB 커넥션 풀 고갈 | 풀 크기 증대 또는 슬로우 쿼리 강제 종료 |
| 특정 노드 장애 | 해당 노드 재기동 또는 로드밸런서에서 제외 |
| 메모리 릭 | 프로세스 재기동 (근본 해결은 사후) |
| 외부 API 장애 | 해당 기능 일시 비활성화 / 페일오버 |
| 트래픽 급증 | 오토스케일 확인, 레이트 리밋 검토 |
복구는 지금 사용자 영향을 줄이는 일, 원인 분석은 왜 그렇게 됐는지 이해하는 일입니다. 사용자 영향이 있는 동안 원인 규명에 시간을 쏟으면 피해만 커집니다. 복구 먼저, 완전한 원인 규명은 ⑤ 사후 분석에서 이어가세요.
⑤ 사후 분석, 다시 안 겪으려면
목표
재발 방지 액션과 문서화
사용할 메뉴는 다음과 같습니다.
이벤트 기록 (알림 발생 이력) + 트레이스 기록
- 이벤트 기록 메뉴에서 이번 장애의 시간대와 발동된 이벤트 목록을 확보하세요.
- 트레이스, 로그 화면에서 증거 스크린샷을 모아두세요 (나중에 재현이 어렵습니다).
- 사후 분석 문서에 정리:
- 타임라인: 알림 발생 → 감지 → 복구 시각
- 원인: ③단계에서 발견한 것
- 영향: 몇 분간 몇 명/몇 트랜잭션 영향
- 재발 방지: 이벤트 규칙, 알림 정책, 코드/인프라 조치
- 재발 방지 항목 중 이벤트 규칙 보완은 바로 적용:
- 더 빨리 감지할 임계값 조정
- 새 경고 규칙 추가
- 알림 수신 태그 재배정
팀에 정착시키기
장애 대응은 한 사람 잘하는 것보다 팀 전체가 같은 절차로 수행하는 것이 중요합니다.
- 이 가이드를 팀 위키에 고정 북마크 (Quick Win 2에서 만든 팀 대시보드 옆에)
- 담당자 인수인계 시 "지난 주 사용한 트레이스·이벤트 기록" 공유
- 분기별로 사후 분석 회고를 반복. 패턴이 보이면 이벤트 규칙으로 승격
다음 단계
- 리포팅으로 공유 → 성능 리포팅 시나리오
- 배포 시점 문제 최소화 → 릴리즈 검증 시나리오
- AI 이상 탐지로 사전 대응 → Anomaly Detection 활용 (심화)