장애 대응 시나리오

경고 알림이 울렸을 때 "어디부터 봐야 할지"를 매번 즉흥으로 판단하면 대응이 느려집니다. 이 가이드는 장애 대응 담당자가 감지부터 복구·사후 분석까지 일관된 흐름으로 수행할 수 있도록 WhaTap의 주요 메뉴를 단계별로 어떻게 엮어 쓰는지 정리합니다.

이 가이드가 맞는 사람

장애 대응 담당자를 맡고 있거나 앞으로 맡을 엔지니어
장애 대응 플레이북을 팀에 정착시키고 싶은 리드·SRE
"알림은 받는데 그다음 뭘 봐야 할지 모르겠다"는 팀원

사전 준비

다음 Quick Win 3종이 완료된 상태여야 실전 운영이 가능합니다.

첫 경고 알림 붙이기 — 기본 알림 규칙
팀과 대시보드 같이 보기 — 팀 공용 대시보드 + 권한
팀별 알림 라우팅 설정하기 — 태그 기반 알림 라우팅

장애 대응 5단계

① 감지 (Detect)  →  ② 영향 범위 (Scope)  →  ③ 원인 분석 (Root Cause)
                                 ↓
                  ④ 복구 (Mitigate)  →  ⑤ 사후 분석 (Postmortem)

① 감지 — 알림 확인

목표: 알림이 진짜 이상 상황인지 1분 안에 판단

Slack·Email·SMS·앱으로 받은 알림 메시지에서 다음을 확인:
- 레벨 (Critical / Warning)
- 프로젝트와 에이전트 이름
- 어떤 이벤트 규칙이 발동했는지 (예: "CPU 사용률 임계값 초과")
알림 메시지의 딥링크를 클릭해 WhaTap 화면으로 바로 진입하세요.

오탐(False Positive) 구분

잦은 스파이크 같은 오탐이면 이벤트 규칙의 지속 시간 조건을 올리세요 (예: 1분 → 5분). 반복되는 오탐을 방치하면 팀이 알림을 신뢰하지 않습니다.

② 영향 범위 파악 — 얼마나 퍼졌나

목표: 몇 개 에이전트·서비스·트랜잭션이 영향받았는지 2분 안에 확인

사용 메뉴: 애플리케이션 대시보드 또는 팀 Flexboard

애플리케이션 대시보드에서 다음을 한눈에 확인합니다.
- Apdex가 급락했는가
- TPS가 비정상적으로 낮거나 높은가
- 평균 응답 시간이 튀었는가
- 에러율 증가 여부
여러 에이전트가 함께 이상이면 인프라·의존성 문제 가능성 ↑ (DB, 네트워크 등)
특정 에이전트만 이상이면 해당 노드·인스턴스 문제 가능성 ↑

장애 vs 배포

최근 배포가 있었는지 먼저 확인하세요. 배포 직후 이상이면 롤백이 가장 빠른 복구일 때가 많습니다.

③ 원인 분석 — 어디서 느려졌나

목표: 어느 구간(코드·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 활용 (심화)

사전 준비​

장애 대응 5단계​

① 감지 — 알림 확인​

② 영향 범위 파악 — 얼마나 퍼졌나​

③ 원인 분석 — 어디서 느려졌나​

AI 분석으로 단축하기​

④ 복구 — 응급 처치​

⑤ 사후 분석 — 다시 안 겪으려면​

팀에 정착시키기​

다음 단계​