시나리오 가이드

장애를 하나씩 주입하고, 에이전트가 무엇을 근거로 어떤 결론을 냈는지 채점한 기록입니다. 각 시나리오는 정답(Ground truth)을 먼저 적어 두고 실행했습니다.

#	시나리오	근본 원인의 종류	장애 신호	결과
S1	메모리 누수 → OOM	코드 · 리소스 한계	HTTP 5xx 급증	✅ 10/10
S2	인그레스 포트 불일치	배포 설정 오류	전 요청 503	✅ 8/10
S3	주문 API 응답 지연	애플리케이션 설정	오류 없이 느려짐	✅ 8/10

S1 · S2 는 증상이 같고(HTTP 5xx) 원인이 다릅니다. S3 는 아예 오류가 나지 않습니다. 세 개를 이어서 보면 에이전트가 증상이 아니라 원인을 보는지 판단할 수 있습니다.

---

진행 순서

01-setup      배포 · 연결 확인
   ↓
02 S1         메모리 누수 → OOM            (기본 시나리오)
   ↓
03 S2         인그레스 포트 불일치          (같은 증상, 다른 원인)
   ↓
04 S3         주문 API 지연                (오류 없는 장애)
   ↓
05-results    세 시나리오 채점 종합

각 시나리오는 복구까지 마친 뒤 다음으로 넘어갑니다. 장애가 남아 있으면 다음 시나리오의 신호와 섞여 채점이 무의미해집니다.

---

평가 방법

시간 지표

지표	계산
탐지 지연	경고 발화 − 장애 주입
인수 지연	조사 스레드 생성 − 경고 발화
원인 도달	근본 원인 확정 − 스레드 생성

RCA 점수 (10점)

항목	배점	기준
영향 범위	2	리소스 · 엔드포인트 · 리비전을 정확히 특정
직접 원인	3	Ground truth 와 일치
증거	2	로그 · 설정 · 메트릭 근거 제시
완화책	2	최소 범위이고 되돌릴 수 있음
불확실성	1	확인 못 한 부분을 구분해 표시

판정: ✅ Pass(8~10) · ⚠️ Partial(5~7) · ❌ Fail(0~4)

---

공통 준비

모든 시나리오는 아래를 전제로 합니다 → 01-setup.md

• azd up 과 scripts/post-provision.sh 가 끝나 있을 것
• Grubify 가 정상 응답할 것 (GET /api/fooditems → 200)
• 경고 규칙 3종이 활성 상태일 것
• 직전 시나리오가 복구 완료되어 있을 것

⚠️ 재조사 쿨다운 — 같은 경고 규칙이 3시간 안에 다시 발화하면 새 조사를 만들지 않고 기존 스레드에 병합됩니다. 그래서 시나리오마다 별도의 경고 규칙을 씁니다.