Close

Atlassian이 소개하는 고속 ITSM에서 Jira Service Management와 다른 강력한 도구에 대해 자세히 알아보세요.

무료 등록

고속 ITSM에 준비되셨습니까?

인시던트 관리란 무엇입니까?

인시던트 관리는 예기치 않은 이벤트 또는 서비스 중단에 대응하고 서비스를 운영 상태로 복원하는 프로세스입니다. IT 인프라 라이브러리(ITIL)에 따르면 '인시던트 관리 프로세스를 통해 정상적인 서비스 운영을 최대한 빨리 복원하고 비즈니스에 미치는 영향을 최소화'합니다.

인시던트는 서비스 품질을 방해하거나 저하시킬 수 있는(또는 그렇게 하도록 위협하는) 모든 종류의 이벤트입니다. 비즈니스 애플리케이션의 가동 중단은 인시던트입니다. 아직 중지되지 않았지만 속도가 늦은 웹 서버도 인시던트가 될 수 있습니다. 실행 속도가 느려 생산성을 저해합니다. 더 큰 문제는 완전히 장애가 발생할 위험이 더 크다는 것입니다.

모든 사용자가 같은 정보를 공유할 수 있도록 관련 용어에 대한 몇 가지 간단한 정의는 다음과 같습니다.

IT 서비스 관리(ITSM)는 IT 서비스를 만들고 지원하고 관리하는 일반적인 접근 방식입니다. ITSM의 핵심 개념은 IT를 서비스로 제공해야 한다는 신념입니다. ITSM의 핵심 관행은 바로 인시던트 관리입니다.

ITIL은 ITSM의 모범 사례 모음입니다.(플레이북으로 간주할 수 있습니다.)

문제는 하나 이상의 인시던트의 아직 알려지지 않은 근본 원인입니다. 네트워크가 느려지고 비즈니스 애플리케이션이 중지되는 위의 인시던트에서 잘못 구성된 라우터는 두 가지 모두의 근본적인 문제가 될 수 있습니다.

ITSM 관행으로 인시던트 관리의 중요성

오늘날 조직이 의존하는 모든 소프트웨어 서비스를 고려할 때 잠재적 장애 지점이 그 어느 때보다 많으며, 인시던트의 영향도 매우 클 수 있습니다. 연구에 따르면 주요 인시던트는 시스템이 중지될 때마다 시간당 300,000달러의 비용이 들 수 있다고 합니다. 일부 웹 기반 서비스의 경우 이 수치가 훨씬 더 높을 수 있습니다.

인시던트 관리 프로세스를 잘 정의하면 이 비용을 대폭 줄일 수 있습니다. 잘 정의된 프로세스의 이점은 다음과 같습니다.

  • 더 빠르게 인시던트 해결
  • 인시던트로 인한 조직의 비용 또는 매출 손실 감소
  • 인시던트 발생 시 내부 및 외부 커뮤니케이션 개선
  • 지속적인 학습 및 개선

인시던트 관리 프로세스

인시던트 관리의 핵심은 적절한 프로세스를 갖추고 지키는 것입니다. 어려워 보일 수 있지만 다행히 수천 명의 다른 IT 서비스 팀의 경험을 통해 배울 수 있습니다.

바쁘고 성장하는 IT 조직의 가장 큰 실수는 처음부터 새로 프로세스를 만들려고 하는 것입니다. 모범 사례를 활용하고 티켓 처리를 위한 자체 도구를 구축하는 데 시간을 낭비하지 마세요.

다음은 인시던트 관리 관행의 중요한 단계에 대한 개요입니다.

인시던트 식별 및 기록

인시던트는 어디서나 발생할 수 있습니다. 직원이 전화를 걸어 신고하거나, 네트워크 허브가 잘못 고정하거나 지붕이 새는 경우 말 그대로 천장 타일을 뚫고 무릎에 떨어질 수 있습니다. (경험을 바탕으로 얘기하는 것은 아닙니다...)

출처와 관계없이 처음 두 단계는 간단합니다. 누군가 인시던트를 식별하면 다른 누군가 이것을 로깅합니다.

서비스 데스크를 통해 이미 로깅된 인시던트를 수신한 경우 이 처음 두 단계가 이미 완료된 것입니다. 전화를 받거나 이메일, 문자 또는 배송 기사를 통해 인시던트가 보고되는 경우 서비스 데스크에 올바르게 로깅하는 것이 서비스 데스크 팀의 업무입니다.

이 인시던트 로그(즉, 티켓)는 일반적으로 다음을 포함합니다.

  • 인시던트를 보고하는 사용자의 이름
  • 인시던트가 보고된 날짜 및 시간
  • 인시던트에 대한 설명(중지되었거나 제대로 작동하지 않는 사항)
  • 추적을 위해 인시던트에 할당한 고유 식별 번호

인시던트 분류

모든 인시던트에 논리적이고 직관적인 범주(및 필요에 따라 하위 범주)를 할당합니다. 그렇지 않으면 나중에 데이터를 분석하고 추세와 패턴을 찾는 능력이 차단됩니다. 이것은 효과적인 문제 관리 및 향후 인시던트 방지에 있어 중요한 부분입니다. 또한 인시던트 범주를 쉽게 사용자 지정할 수 있는 ITSM 서비스 데스크 솔루션을 선택해야 합니다.

인시던트 우선 순위 지정

모든 인시던트의 우선 순위를 지정해야 합니다. 비즈니스에 미치는 영향을 평가하는 것부터 시작합니다. 영향을 받는 관련자의 수와 잠재적으로 재무, 보안 및 규정 준수에 미치는 영향을 고려합니다. 이렇게 하면 인시던트가 얼마나 많은 어려움을 초래하는지, 그리고 비즈니스에서 인시던트를 얼마나 긴급하게 해결해야 하는지 파악할 수 있습니다.

여기에서 모범 사례는 인시던트가 발생하기 전에 심각도 및 우선 순위 수준을 정의하여 인시던트 관리자가 우선 순위를 빠르게 알아낼 수 있게 하는 것입니다.

우선 순위 수준이 확실하지 않은 경우 더 높은 우선 순위를 지정합니다. 심각한 문제를 간과하는 것보다 지나치다 싶을 정도로 조심하는 편이 더 낫습니다.

우선 순위를 설정한 후에는 모든 미해결 인시던트를 우선 순위에 따라 해결합니다. 대부분의 조직은 각 우선 순위 수준에 대해 명확한 서비스 계약을 설정하므로 고객은 응답 및 해결에 시간이 얼마나 걸릴지 알 수 있습니다.

대응

인시던트 대응은 폭넓게 사용되는 용어이므로, 인시던트를 식별, 분류 및 우선 순위를 지정한 후에 수행할 가능성이 가장 높은 단계로 조금 더 세분화하겠습니다.

초기 진단

병원에서 새로 내원하는 환자를 분류하는 것과 같은 분류 기능이라고 생각하세요. 서비스 데스크 직원은 무엇이 잘못되었는지에 대한 빠른 가설을 수립하고 있으므로 문제 해결을 시작하거나 적절한 절차를 따르고 올바른 리소스를 모아서 문제를 해결할 수 있습니다. 기술 자료 및 진단 매뉴얼은 이 단계에서 유용한 도구입니다.

대응한 첫 번째 에이전트가 초기 진단 및 사용 가능한 기술 자료 및 도구를 사용하여 인시던트를 해결할 수 있는 경우 인시던트는 해결된 것입니다. 그렇지 않으면 에스컬레이션해야 할 차례입니다.

인시던트 에스컬레이션

전면 지원 팀은 에스컬레이션하지 않은 가장 자주 발생하는 많은 인시던트를 해결할 수 있어야 합니다. 하지만 그럴 수 없는 경우 목표는 올바른 정보를 수집하고 로깅하여 지원 팀이 인시던트를 즉시 해결할 수 있도록 속도를 내는 것을 지원하는 것입니다.

조사 및 진단

ITIL은 이것을 별도로 하나의 단계로 강조합니다. 실제로 이 단계는 인시던트 수명 주기 전반에 걸쳐 발생합니다.

대응하는 첫 번째 지원 담당자는 정보를 수집하는 시점을 어느 정도 이미 조사하고 있으며 에스컬레이션이 필요 없이도 인시던트를 진단하고 해결할 수도 있습니다. 이 경우 해결 및 복구와 인시던트 종결이라는 몇 가지 단계를 바로 건너뛰었습니다.

그렇지 않으면 해결책을 상담하고 지원하기 위해 외부 리소스를 에스컬레이션하거나 외부 리소스를 도입할 때 모든 단계에서 조사 및 진단이 이루어집니다.

해결 및 복구

결과적으로(그리고 가능하면 확립된 서비스 수준 계약(SLA) 내에서) 진단을 완료하고 인시던트 해결에 필요한 단계를 수행합니다. 적절한 해결 방법을 식별한 후에도 일부 수정(예: 버그 패치 등)을 테스트하고 배포해야 할 수 있으므로, 복구는 운영을 완전히 복원하는 데 걸리는 시간을 의미합니다.

인시던트 종결

그런 다음 인시던트를 서비스 데스크로 다시 전달하여(에스컬레이션된 경우) 종결합니다. 품질을 유지하고 원활한 프로세스를 보장하기 위해 서비스 데스크 직원만 인시던트를 종료할 수 있으며, 인시던트 소유자는 인시던트를 보고한 사용자에게 해결이 만족스럽고 인시던트를 종료해도 되는지 확인해야 합니다.

요약

특히 소규모 조직의 구성원인 경우 인시던트 관리 프로세스가 불필요한 형식으로 보일 수 있습니다. 그러나 팀 구조와 관계없이 인시던트 수명 주기는 여전히 동일하며 에스컬레이션이 종종 발생해야 하므로 단계를 건너뛰지 마세요.

인시던트는 발생합니다. 그러나 강력한 인시던트 관리 프로세스는 인시던트의 영향을 줄이고 서비스를 신속하게 복원할 수 있음을 의미합니다.

Jira Service Management의 인시던트 관리에 대해 알아보시겠습니까?