이벤트·모니터링 관리 — 장애를 신고 전에 먼저 안다 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theoryitsm/event-monitoring

TRACK

ITSM

SLA

55분

SEV

SEV-2

PHASES

3단계

ENV

local

INCOMING TICKET

“운영팀장: "알림이 하루 수백 건씩 와서 다들 채널을 음소거했고, 지난주엔 새벽에 결제 DB 디스크가 꽉 차는데 일곱 시간을 아무도 몰랐어요. 반대로 옆 팀은 자정에 '디스크 85퍼센트 초과' 경고를 받고 로그를 정리해 아무 일도 없던 것처럼 넘어갔고요. 신호를 정보·경고·예외로 분류하고, 임계치를 제대로 잡고, 진짜 알림만 남게 노이즈를 정리해서 장애를 신고 전에 먼저 잡는 체계를 만들어 주세요."”

YOUR ROLE

IT 서비스 운영·관제 담당

IMPACT IF UNRESOLVED

이벤트 분류·임계·노이즈 규칙이 없으면 정보성 알림에 진짜 예외가 묻혀 장애를 고객 전화로 알게 되고, 임계를 감으로 잡아 사소한 변동에 알림이 쏟아지거나 문제가 커진 뒤에야 뜨며, 경보 피로로 운영자가 알림 전체를 신뢰하지 않게 된다.

🚨INCIDENT BRIEF

운영팀장이 말합니다.

"모니터링은 다 깔려 있어요. 그런데 알림이 하루 수백 건씩 오니까 다들 채널을 음소거했고, 지난주엔 새벽에 결제 DB 디스크가 꽉 차는데 일곱 시간을 아무도 몰랐어요. 반대로 옆 팀은 자정에 '디스크 85퍼센트 초과' 경고를 받고 로그를 정리해 아무 일도 없던 것처럼 넘어갔고요. 우리도 신호를 분류하고, 임계치를 제대로 잡고, 진짜 알림만 남게 노이즈를 정리해 주세요."

두 팀의 차이는 모니터링 도구의 유무가 아니라, 신호를 받고도 살아 있는 체계가 있느냐다. 이 Lab은 이벤트를 정보·경고·예외로 분류하고 임계치를 정하며, 알림 정책과 인시던트 자동 연계를 설계하고, 경보 피로를 막는 노이즈 튜닝까지 규칙으로 확정한다.

⏱ 55분📊 중급🔧 3단계#event#monitoring#alerting#threshold

MISSION

이벤트 유형 분류(정보·경고·예외) + 임계치 설정 — 감이 아니라 선으로

들어온 상태 변화 신호를 정보·경고·예외로 분류하고, 각 지표의 임계치를 지속 조건까지 붙여 규칙으로 정한다.

알림 정책 + 인시던트 자동 연계 — 임계를 넘으면 알리고, 예외는 티켓이 된다

임계 초과 신호가 누구에게·어떤 채널로·얼마나 급하게 가는지 알림 정책을 정하고, 예외급은 인시던트 티켓으로 자동 생성되는 흐름을 설계한다.

경보 피로 방지 + 노이즈 튜닝 — 알림을 끄지 말고 정확하게

알림 피로의 원인(정보 알림·빡빡한 임계·상관분석 부재)을 짚고, 정보 제거·지속 조건·상관분석·중복 억제로 적은 알림이 모두 의미를 갖게 튜닝한다.

📌 선수 지식

• [이론] itsm/event-monitoring

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES