[ITSM] 인시던트 관리 — 멈춘 서비스를 가장 빨리 정상으로

운영의 하루에 들어오는 신고 중 가장 급한 종류가 인시던트입니다. 정의는 단순합니다 — 정상적으로 동작하던 서비스가, 계획되지 않게 중단되거나 품질이 떨어진 상태.

여기서 두 단어가 핵심입니다.

• "정상이던 게" — 원래 되던 것이 안 되는 것입니다. 원래 없던 기능을 새로 해달라는 것은 서비스 요청이지 인시던트가 아닙니다.
• "계획되지 않게" — 예고된 점검(maintenance)으로 멈춘 건 인시던트가 아닙니다. 예상 밖으로 멈춘 것이 인시던트입니다.

중요한 건 '완전 중단'만 인시던트가 아니라는 점입니다. 품질 저하(degradation) 도 인시던트입니다.

인시던트 관리에서 가장 자주 오해받는 지점이 여기입니다. 인시던트 관리의 목표는 합의된 서비스 수준 안에서 서비스를 가능한 한 빨리 정상으로 되돌리는 것입니다. 근본 원인을 밝히는 게 아닙니다.

왜일까요? 사용자 입장에서 생각하면 분명합니다. 결제가 멈춘 고객은 "왜 멈췄는지 알아냈습니다"라는 보고가 아니라 "지금 결제가 다시 됩니다" 를 원합니다. 멈춰 있는 1분마다 매출과 신뢰가 깎입니다.

그래서 인시던트 관리는 임시조치(workaround) 를 적극적으로 씁니다.

• 죽은 노드를 재시작한다(왜 죽었는지는 나중에).
• 방금 배포한 변경을 롤백한다.
• 장애 난 경로를 우회해 트래픽을 우회 라우팅한다.

이것들은 "제대로 된 수리"가 아니라 "일단 불 끄기"입니다. 그래도 맞습니다. 빠른 복구가 먼저고, "왜 불이 났는가"는 복구 뒤에 문제관리(Problem Management) 로 따로 추적합니다.

이 분리를 못 하면 시나리오의 C처럼 됩니다 — 원인을 쫓느라 복구가 늦어지는 것. 복구와 원인 규명을 순서로 분리하는 것이 인시던트 관리의 핵심 감각입니다.

인시던트는 들어와서 끝날 때까지 정해진 단계를 밟습니다. 각 단계가 무엇을 하는지 알면, 지금 내가 어디에 있고 다음에 뭘 해야 할지 길을 잃지 않습니다.

여기에 종결 뒤 사후 검토(post-incident review) 가 붙기도 합니다. 큰 장애(P1 등)는 "무엇이 잘 됐고 무엇이 늦었나"를 돌아보고, 반복·원인 미상이면 문제관리로 넘깁니다.

순서를 외우려 하지 말고, "지금 복구됐나? 아니라면 어느 단계에 막혀 있나?" 를 자문하는 도구로 쓰세요. 막힌 단계가 보이면 거기서 에스컬레이션할지 판단합니다.

같은 유형의 인시던트가 자꾸 들어오면, 매번 즉흥적으로 푸는 건 낭비입니다. 인시던트 모델(Incident Model) 은 "이런 유형이 오면 이렇게 처리한다"를 미리 적어둔 표준 처리 절차입니다.

예를 들어 "디스크 풀(disk full)로 서비스가 느려진다"가 자주 온다면, 다음을 모델로 만들어 둡니다.

• 처리 단계: 임시 로그 압축·정리 → 사용률 확인 → 임계 알람 점검 → 사용자 확인 후 종결
• 담당: 1차 운영, 30분 내 미해소 시 인프라팀 에스컬레이션
• 우선순위 기준: 영향 서비스 매출 등급에 따라 P2~P3

이렇게 해두면 에이스가 아니어도 누가 받든 같은 품질·속도로 처리됩니다. 인시던트 모델은 장애를 없애주는 게 아니라, 처리의 품질이 사람에 휘둘리지 않게 만드는 장치입니다. 자주 보는 유형부터 하나씩 모델로 만드는 것이 운영 성숙의 시작입니다.

한 가지 구분을 분명히 해 둡니다 — 인시던트 vs 문제.

이 트랙에서 문제관리는 뒤 모듈에서 깊게 다룹니다. 여기서는 "복구는 인시던트, 재발 방지는 문제" 라는 경계만 분명히 잡고 갑니다.