Brain💡 핵심 인사이트
인시던트 관리의 유일하고도 절대적인 목표는 "근본 원인 분석이고 나발이고, **일단 사용자(고객)가 멈춰버린 서비스를 최대한 빨리 다시 쓸 수 있게 '임시방편(Workaround)'으로라도 정상화시키는 것"**입니다.
ITIL 서비스 운영의 가장 최전선 소방수 역할입니다.
Ⅰ. 인시던트(Incident)의 정의
ITIL에서 **인시던트(장애, 사건)**란 "IT 서비스의 예기치 않은 중단, 또는 품질의 저하"를 의미합니다.
- 서버가 펑 터져서 홈페이지가 아예 안 들어가는 것 (중단).
- 결제 버튼을 누르면 1초 만에 넘어가던 화면이 오늘은 30초나 걸리는 것 (품질 저하).
- 심지어, 당장 체감 장애는 없지만 모니터링 디스크 용량이 99%를 찍고 있는 아슬아슬한 상태도 선제적인 인시던트로 간주합니다.
Ⅱ. 인시던트 관리의 최우선 철학 (우회책, Workaround)
"왜 이 메일 서버 메모리 누수가 발생했지? 소스 코드를 뜯어서 근본 버그를 고쳐보자!" ➔ 이것은 인시던트 관리팀이 절대 해서는 안 될 행동입니다. (이건 뒤에 나올 '문제 관리팀'의 일입니다.)
비즈니스는 1분 1초가 돈입니다. 고객이 메일을 못 보내고 발을 동동 구르고 있는데 코드를 디버깅하고 있으면 안 됩니다. 인시던트 관리의 미션은 **"일단 서비스를 살려!"**입니다.
- 버그를 못 고치겠으면 일단 서버를 껐다 켭니다(재부팅).
- 메인 서버가 터졌으면 즉시 보조 이중화 서버로 트래픽을 넘깁니다.
- 이런 식으로 진짜 원인은 나중에 찾더라도, 당장 사용자가 임시로라도 서비스를 쓸 수 있게 만들어주는 비상 조치를 **워크어라운드(Workaround, 임시 우회책)**라고 부릅니다.
Ⅲ. 인시던트 관리 프로세스 5단계
서비스 데스크(SPOC)에 전화가 걸려 온 순간부터 시작됩니다.
- 식별 및 로깅 (Logging): 사용자가 전화를 걸면 "인터넷이 안 된다"는 증상, 시간, 연락처를 시스템에 티켓으로 꼼꼼히 기록합니다.
- 분류 및 우선순위 지정 (Prioritization): 가장 중요한 단계입니다. 장애의 심각도를 판단합니다.
- *영업팀 전체가 죽은 인시던트(긴급/Impact 높음)*와 김대리 한 명 프린터 안 되는 인시던트가 겹치면, 프린터는 뒤로 미루고 영업망부터 복구하는 우선순위 매트릭스(SLA 기반)를 따릅니다.
- 초기 진단 (1차 진단): 서비스 데스크 요원이 과거 매뉴얼을 뒤져 바로 할 수 있는 조치(캐시 삭제, 재부팅)를 해봅니다.
- 에스컬레이션 (Escalation): 매뉴얼로 안 되면 Tier 2(전문 서버/네트워크 팀)로 티켓을 토스(상향 보고)합니다.
- 복구 및 종료 (Resolution & Closure): 어떻게든 우회책을 동원해 서비스가 살아나면, 고객에게 전화해 "이제 잘 되시나요?" 확인을 받고 완료 도장을 쾅 찍습니다. (SLA 카운트다운 정지)
📢 섹션 요약 비유: 인시던트 관리는 **'응급실의 심폐소생술(CPR)'**입니다. 길가다 쓰러져 실려 온 환자에게 응급실 의사가 "오늘 아침에 뭘 잘못 먹어서 쓰러졌지? 혈액 검사를 해보자"라고 느긋하게 진단(문제 관리)하지 않습니다. 숨이 멎었으니 원인 불문하고 일단 제세동기로 전기 충격(Workaround)을 줘서 심장 박동(서비스)부터 뛰게 살려놓는 것이 최우선 목표입니다.