5. 무엇을 실습하나요

#	시나리오	대상	소요	GitHub 필요
0	포털 투어 — 설정·Builder·Capabilities 둘러보기	전체	10분	❌
S1	앱 장애(메모리 누수) → 에이전트가 로그 기반 조사·완화	IT 운영	20분	❌
S2	배포 설정 오류(포트 불일치) → 리비전 기동 실패 조사	IT 운영 · DevOps	20분	❌
S3	응답 지연(오류 없는 느림) → 지연만 보고 원인 판정	IT 운영	20분	❌
2	동일 장애 → 소스 코드에서 근본 원인 발견 + GitHub 이슈 생성	개발자 + IT	20분	✅
3	고객 이슈 트리아지 → 분류·라벨·코멘트 자동화	워크플로 자동화	10분	✅
4	가치 측정 — Operations Hub · Live Reports 로 효과 확인	의사결정자	10분	❌

시간이 부족하면 0 → S1 → 4 순서만으로도 완결된 스토리가 됩니다 (GitHub 불필요, 약 40분). S1 · S2 · S3 는 근본 원인의 종류가 각각 다릅니다 — 코드·용량, 배포 설정, 애플리케이션 설정입니다. 세 개를 이어서 보여주면 "에이전트가 증상이 아니라 원인을 본다"는 점이 분명해집니다.

시나리오 0 — 포털 투어 (GitHub 불필요)

장애를 일으키기 전에 에이전트가 어떤 재료로 일하는지를 먼저 보여주세요. sre.azure.com → 해당 에이전트 선택 후 순서대로 확인합니다.

순서	위치	볼 것	설명 포인트
1	상단 Complete setup (전체 설정)	코드·로그·배포·인시던트·Azure 리소스·기술 자료 파일	연결한 소스가 많을수록 조사 품질이 올라간다
2	Settings ▸ Knowledge Base	업로드된 런북 4개가 색인(Indexed) 상태	에이전트가 우리 팀 절차를 따른다
3	Builder ▸ Agent Canvas	incident-handler 와 연결된 도구 19종	도메인별 전문 에이전트를 직접 만든다
4	Builder ▸ Incident response plans	grubify-http-errors → Autonomous	사람 개입 없이 라우팅된다
5	Capabilities	Built-in / 코드 실행 / 지식 / MCP 도구 목록	커넥터 없이도 Azure 진단은 바로 된다
6	Settings ▸ Basics / Managed resources	대상 리소스 그룹과 권한 수준 · Agent mode	표시는 Reader 지만 관리 ID 에 쓰기 역할을 준 상태 — 그래서 완화까지 한다
7	Favorites ▸ Team onboarding	최초 온보딩 대화	/learn 으로 재시작 가능

그런 다음 새 채팅에서 가볍게 질문해 보세요 (채팅은 영어만 지원):

What Azure resources are you managing right now? Give me a one-line summary of each.

What do you already know about the Grubify application? Cite your knowledge sources.

시나리오 S1 — IT 운영 (GitHub 불필요)

bash scripts/break-app.sh <API_URL> 200 0.5

/api/cart/demo-user/items 로 200회 POST 를 보내 메모리 누수를 유발합니다. (in-memory 장바구니에 eviction 로직이 없음)

1. Grubify Frontend 를 열고 장바구니 담기 시도 → 실패 확인
2. 기다리기 — 경고 발화 → Response Plan 이 incident-handler 를 자율 모드로 자동 실행합니다
3. Incidents 메뉴에서 새 인시던트 행 → 조사 스레드 진입
4. 스레드에서 순서대로 보여주기:
5. Reasoning 블록 — 에이전트가 세운 조사 계획(To-Do Plan)
6. Memory Search — 런북·아키텍처 문서를 참조하는 장면
7. 메트릭/로그 병렬 수집 → 근본 원인 확정
8. 완화 조치 실행 → 경고 종료 → 메모리 저장
9. 복구 확인: Grubify Frontend 에서 다시 장바구니 담기

수동 조사도 가능: 자동 경고를 기다리지 않고 바로 보여주려면 새 채팅 → / 입력 → incident-handler 선택 후 아래 프롬프트를 보내세요.

The Grubify API is failing on "Add to Cart". Investigate and find the root cause,
then propose a mitigation.

실제 소요 시간: 경고 발화 → 완화 약 5분, 최종 보고까지 약 14분 → 6. E2E 결과

시나리오 2 — 개발자 (GitHub 필요)

동일한 장애이지만, 코드 소스를 연결하면 에이전트가 추가로:

• Grubify 소스 코드에서 근본 원인 검색 → 정확한 파일:라인 식별
• 직전 배포와의 상관분석 ("이번 배포가 원인인가?")
• 코드 참조와 수정 제안이 포함된 GitHub 이슈 생성 (경우에 따라 수정 PR)

설정 방법: Complete setup ▸ 코드 카드에서 GitHub 연결 (OAuth 또는 PAT) 또는 azd env set GITHUB_USER <username> 후 bash scripts/post-provision.sh --retry

이슈 생성이 실패하면: Use the GitHub API to create the issue if the direct tool isn't working

시나리오 3 — 워크플로 자동화 (GitHub 필요)

bash scripts/create-sample-issues.sh <your-user>/grubify

Builder ▸ Scheduled tasks ▸ triage-grubify-issues ▸ Run task now 실행 후 각 [Customer Issue] 에 분류·라벨(bug, api-bug, severity-high 등)·트리아지 코멘트가 달립니다.

이어서 Operations Hub ▸ Automation 탭에서 방금 실행한 작업의 실행 횟수 · 성공률 · 평균 소요시간을 확인하면 자동화 운영 관점까지 연결됩니다.

직접 만들어보기(심화): Connector → Custom Agent → Scheduled task 3단 조립으로 "매일 08:00 리소스 헬스 요약을 Teams 로 발송" 같은 작업을 만들 수 있습니다.

시나리오 4 — 가치 측정 (GitHub 불필요)

조사가 끝난 뒤, 이 에이전트가 정말 도움이 되었는가를 숫자로 보여줍니다.

순서	위치	볼 것
1	Operations Hub ▸ Overview	데이터 소스 연결 상태 · Pending Actions · System Health · AAU 사용량
2	Operations Hub ▸ Incident Analytics	절감된 엔지니어링 시간 · 해결률 · 완화 중앙값(P50) · IntentMet 점수
3	Operations Hub ▸ Automation	예약 작업·트리거 성공률과 실행 시간
4	Live Reports	보안 findings · 인시던트 요약 · 리소스 헬스 · 권장 조치
5	조사 스레드 ▸ ⋯ ▸ Copy link to thread	Teams/Slack 공유용 딥링크

지표는 조사가 누적되면서 의미를 갖습니다. 첫 시연 직후에는 표본이 적을 수 있으므로, "이런 것을 측정할 수 있다" 는 관점으로 소개하는 것을 권장합니다.

보너스 프롬프트

환경 파악

What is the public endpoint URL for the Grubify frontend container app?

What recent changes were made to resources in my resource group? Check the Activity Log.

진단 · 시각화 (Python 차트 도구 사용을 유도)

Show me the CPU and memory usage trends for the Grubify container app over the last hour,
and plot requests vs memory on the same chart.

Using the http-500-errors runbook, walk me through all the diagnostic KQL queries
and show me the results for the Grubify app.

운영 점검

Check if there are any Azure Advisor recommendations for my resource group.

Are there any reliability risks in this resource group? Single points of failure,
missing health probes, or undersized containers?

팀 메모리 (저장 → 회상 데모)

Remember that our on-call rotation is: Monday-Wednesday is Team Alpha,
Thursday-Sunday is Team Beta. Escalation path: on-call → team lead → VP Engineering.

Who is on call today, and what should they check first if the cart API fails again?

시나리오 S2 — 배포 설정 오류 (GitHub 불필요)

시나리오 S1 과 같은 증상(HTTP 5xx), 다른 원인입니다. "에이전트가 증상이 아니라 원인을 보는가" 를 확인하는 시나리오입니다.

# 1) 인그레스를 앱이 듣지 않는 포트로 돌린다 → 전 요청 503
bash scripts/break-app-config.sh break

# 2) 경고 임계값을 넘도록 트래픽을 준다 (약 90건)
for i in $(seq 1 90); do curl -s -o /dev/null "$APP_URL/api/fooditems"; sleep 0.7; done

# 3) 포털에서 조사 스레드를 연다 → 끝나면 상태 확인
bash scripts/break-app-config.sh status

볼 것	기대
경고	alert-revision-unhealthy-sre-lab (Sev2) 발화
조사	시스템 로그의 Pending:PortMismatch 를 근거로 제시
변별	"NOT OOM this time" — 과거 메모리 누수 인시던트와 구분
조치	targetPort 를 8080 으로 정렬 (Autonomous)

에이전트가 스스로 복구하지 않았다면 bash scripts/break-app-config.sh restore 로 되돌립니다. 실측 결과는 6.8 에 있습니다.

시나리오 S3 — 응답 지연 (GitHub 불필요)

오류가 하나도 나지 않고 느려지기만 하는 장애입니다. 5xx 가 없으므로 "에러 없으니 이상 없음" 으로 넘어가지 않는지를 봅니다.

사전 준비 — 기본 Grubify 이미지에는 지연을 넣을 지점이 없습니다. fork 한 저장소에 ORDER_DELAY_MS 미들웨어를 넣고 이미지를 다시 빌드해야 합니다. 코드와 빌드 명령은 guides/04-scenario-s3.md 에 있습니다.

# 1) 주입 — /api/orders 가 4초 지연 후 200 을 반환한다
bash scripts/break-app-latency.sh break

# 2) 부하 — 모두 200 이지만 4초씩 걸린다
CONCURRENCY=10 ROUNDS=20 bash scripts/break-app-latency.sh load

# 3) 복구
bash scripts/break-app-latency.sh restore

볼 것	기대
경고	alert-latency-sre-lab (Sev2, 평균 ResponseTime > 200ms) 발화
조사	오류율은 정상인데 지연만 올라간 점을 구분해 서술
원인	리비전 환경 변수 ORDER_DELAY_MS=4000 을 지목
한계	원인은 찾았지만 완화까지 끝내지 못했습니다 (감점 사유)

실측 결과는 6.10 에 있습니다. CPU 를 굶겨서 지연을 만들려던 첫 시도는 실패했습니다. 그 기록도 6.10 에 함께 남겼습니다.

---