인시던트 관리 프로세스를 IT 운영 전문가처럼 완벽하게 수행하기

인시던트 식별 및 기록

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

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

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

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

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

인시던트 분류

다음 두 단계(분류 및 우선 순위 지정)는 모두 중요하지만 일반적으로 간과됩니다. 또한 제가 일했던 “정상적인” 편인 서비스 데스크를 그렇게 정상적이지는 않은 서비스 데스크와 분리해 줍니다.

먼저 모든 인시던트에 논리적이고 직관적인 범주(및 필요에 따라 하위 범주)를 할당해야 합니다. 그렇지 않으면 나중에 데이터를 분석하고 추세와 패턴을 찾는 능력이 차단됩니다. 이것은 효과적인 문제 관리 및 향후 인시던트 방지에 있어 중요한 부분입니다.

그러니 잊지 마세요. 또한 인시던트 범주를 쉽게 사용자 지정할 수 없는 IT 서비스 데스크 솔루션에 안주하지 마세요.

인시던트 우선 순위 지정

두 번째로, 모든 인시던트의 우선 순위를 지정해야 합니다.

인시던트의 우선 순위를 지정하려면 먼저 인시던트가 비즈니스에 미치는 영향을 평가하는 것부터 시작하세요. 영향을 받는 관련자의 수와 인시던트가 잠재적으로 재무, 보안 및 컴플라이언스에 미치는 영향을 모두 고려하여 인시던트로 인한 어려움의 정도와 비즈니스에 대한 해결책이 얼마나 시급한지를 파악하세요.

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

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

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

대응

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

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

기술 자료 및 진단 매뉴얼 역시 이 단계에서 유용한 도구입니다.

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

인시던트 에스컬레이션
에스컬레이션은 부정적인 단어처럼 들리지만 그렇지 않습니다.

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

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

전면 지원 담당자는 정보를 수집하는 시점을 어느 정도 이미 조사하고 있으며 에스컬레이션이 필요 없이도 인시던트를 진단하고 해결할 수도 있습니다.

이 경우 해결 및 복구와 인시던트 종결이라는 몇 가지 단계를 바로 건너뛰었습니다.

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

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

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

결론: 단계를 건너뛰지 마세요

특히 서비스 데스크 분석가가 몇 명뿐인 경우 프로세스가 불필요하게 형식적으로 보일 수 있습니다. 그러나 팀 구조와 관계없이 인시던트 수명 주기는 여전히 동일합니다.

서비스 데스크 분석가가 한 명뿐이므로 수준 3 지원이 없다고 가정해 보겠습니다. 하지만 서비스 데스크 분석가의 지식을 능가하는 인시던트의 경우 수석 엔지니어든 외부 컨설턴트든 또는 여러분이든 맡아 해결해야 합니다.

결국 여러분이나 엔지니어를 통해 이미 수준 2 또는 수준 3 지원을 갖춘 셈입니다.

요점을 말씀드리자면, ITIL은 의미론에 관한 것처럼 보일 수 있지만 의미론에 사로 잡히지 마세요. 위에서 설명한 것처럼 간단한 IT 서비스 관리 프레임워크에 맞게 조직의 계층 구조 및 프로세스 워크플로를 조정할 수 있는 쉬운 방법을 찾으세요.

이렇게 하면 더 뛰어난 고객 서비스를 제공하고 비즈니스에 훨씬 더 많은 가치를 제공할 수 있습니다. (게다가 정신없는 상태를 방지할 수 있다는 점은 덤입니다!)

마지막으로 몇 가지 내용을 요약해 보겠습니다.

• 모든 인시던트를 로그합니다. 고유한 번호를 지정합니다. 그리고 중앙 집중식 지원 센터 시스템에서 날짜, 시간, 설명과 같은 중요한 세부 정보를 캡처합니다.
• 인시던트 업데이트를 전달할 내부 또는 외부 대상이 많은 경우 인시던트 커뮤니케이션을 위한 상태 페이지를 만드는 것을 고려하세요.
• 모든 인시던트에 범주(및 필요에 따라 하위 범주)를 할당합니다.
• 모든 인시던트에 우선 순위 수준을 부여하고 모든 우선 순위 수준을 SLA로 지정합니다.
• 인시던트 관제자, 주요 인시던트 관리자, 커뮤니케이션 리더와 같은 인시던트 대응자의 역할을 명확하게 정의해 둡니다.
• 가능하면 기술 자료 문서 및 인시던트 진단 스크립트로 전면 지원 팀을 지원하여 인시던트를 신속하게 해결합니다.
• 서비스 데스크에서 인시던트 진행률, 라우팅 및 상태를 항상 제어하는지 확인합니다.
• 인시던트 데이터를 캡처하는 데서 그치지 말고 데이터를 분석하세요! 인시던트의 수를 줄이고 위험을 완화할 수 있는 추세, 패턴 및 잠재적인 근본 문제를 찾아보세요.

작성자 소개