빠른 속도의 팀을 위한 인시던트 관리
인시던트 관리 프로세스를 IT 운영 전문가처럼 완벽하게 수행하기
작성자: Nick Wright, Atlassian 서비스 운영 관리자
먼저 마음 속에서 털어놓아야 할 말이 있습니다. 전면 지원 팀은 모든 비즈니스의 숨은 영웅입니다.
모든 비즈니스의 영웅이라고 할 수 있습니다.
저는 기술 지원이 서비스 업계로 간주되어야 하며, 고객은 우수한 서비스를 제공하는 에이전트에게 팁을 남길 수 있어야 한다고 생각합니다. 가능하기만 하다면, 제 이슈를 빠르게 해결한 모든 뛰어난 지원 담당자에게 미소와 함께 기꺼이 팁을 남길 것입니다.
주제에서 벗어난 이야기를 했네요. 이 글을 읽고 있는 분들은 지원 센터 팀을 관리하거나 맡고 있을 것입니다. 아마 지금 머리에 불이 붙을 정도로 정신이 없고 냄새도 끔찍할 것입니다. 이제 이에 대해 조치를 취하고 IT 인시던트 관리 프로세스를 제어해 보겠습니다.
인시던트 관리에 대해 자세히 살펴보기 전에 몇 가지 일반적인 용어에 대해 알아보겠습니다.
ITSM 및 인시던트 관리
IT 분야에서 일하는 경우 ITIL, ITSM, 인시던트 및 문제에 대해 잘 알고 있을 것입니다. 모두가 같은 정보를 공유할 수 있도록, Atlassian에서 사용하는 용어에 대한 몇 가지 간단한 정의는 다음과 같습니다.
ITIL(IT 인프라 라이브러리)은 ITSM의 모범 사례의 모음입니다(플레이북으로 간주할 수 있습니다).
ITSM(IT 서비스 관리)은 IT 서비스를 만들고, 지원하고, 관리하는 일반적인 접근 방식입니다. ITSM의 핵심 개념은 IT를 서비스로 제공해야 한다는 신념입니다. ITSM의 핵심 관행은 바로 인시던트 관리입니다.
인시던트는 서비스 품질을 방해하거나 저하시킬 수 있는(또는 그렇게 하도록 위협하는) 모든 종류의 예기치 않은 이벤트입니다. 비즈니스 애플리케이션의 가동 중단은 인시던트입니다. 아직 중지되지 않았지만 속도가 늦은 웹 서버도 인시던트가 될 수 있습니다. 실행 속도가 느려 생산성을 저해합니다. 더 큰 문제는 완전히 장애가 발생할 위험이 더 크다는 것입니다.
문제는 하나 이상의 인시던트의 아직 알려지지 않은 근본 원인입니다. 네트워크가 느려지고 비즈니스 애플리케이션이 중단되는 위의 인시던트에서 잘못 구성된 라우터는 두 가지 모두의 근본적인 문제가 될 수 있습니다.
ITSM 관행으로 인시던트 관리의 중요성
그렇다면 왜 인시던트 관리가 중요합니까? 인시던트 관리가 ITSM 세계의 일부인 이유는 무엇입니까?
답은 그 영향에 있습니다. 연구에 따르면 회사에서는 주요 인시던트로 인해 시스템이 가동 중단될 때마다 시간당 평균 100,000에서 300,000달러에 이르는 비용이 들 수 있다고 합니다.
인시던트 관리 프로세스를 잘 정의하면 이 비용을 대폭 줄일 수 있습니다. 잘 정의된 프로세스의 이점은 다음과 같습니다.
- 더 빠르게 인시던트 해결
- 조직의 비용 또는 수익 손실 감소
- 인시던트 발생 시 내부 및 외부 커뮤니케이션 개선
- 지속적인 학습 및 개선
인시던트 관리 워크플로
ITIL 프레임워크를 사용하여 적절한 티켓 처리에 대한 개괄적인 개요를 안내해 드릴 것이지만, 대부분의 널리 사용되는 다른 프레임워크도 약간 다른 용어를 사용하여 비슷한 개념을 설명합니다.
인시던트 관리의 핵심은 적절한 프로세스를 갖추고 지키는 것입니다.
어려워 보일 수 있지만 다행히 수천 명의 다른 IT 서비스 팀의 경험을 통해 배울 수 있습니다.
바쁘고 성장하는 IT 조직의 가장 큰 실수는 (모범 사례를 활용하지 않고) 처음부터 새로 프로세스를 만들려고 하거나 티켓 처리를 위한 자체 도구를 구축하는 것입니다.
인시던트 식별 및 기록
인시던트는 어디서나 발생할 수 있습니다. 직원이 전화를 걸어 신고하거나, 네트워크 허브를 잘못 고정하거나 지붕이 새는 경우 말 그대로 천장 타일을 뚫고 무릎에 떨어질 수 있습니다. (경험을 바탕으로 얘기하는 것은 아닙니다... *으흠*)
출처와 관계없이 처음 두 단계는 간단합니다. 누군가 인시던트를 식별하면 다른 누군가 이것을 로깅합니다.
서비스 데스크를 통해 이미 로깅된 인시던트를 수신한 경우 이 처음 두 단계가 이미 완료된 것입니다. 전화를 받거나 이메일, 문자 또는 배송 기사를 통해 인시던트가 보고되는 경우 서비스 데스크에 올바르게 로깅하는 것이 서비스 데스크 팀의 업무입니다.
이 인시던트 로그(즉, 티켓)는 일반적으로 다음을 포함합니다.
- 인시던트를 보고하는 사용자의 이름
- 인시던트가 보고된 날짜 및 시간
- 인시던트에 대한 설명(중지되었거나 제대로 작동하지 않는 사항)
- 추적을 위해 인시던트에 할당한 고유 식별 번호
인시던트 분류
다음 두 단계(분류 및 우선 순위 지정)는 모두 중요하지만 일반적으로 간과됩니다. 또한 제가 일했던 “정상적인” 편인 서비스 데스크를 그렇게 정상적이지는 않은 서비스 데스크와 분리해 줍니다.
먼저 모든 인시던트에 논리적이고 직관적인 범주(및 필요에 따라 하위 범주)를 할당해야 합니다. 그렇지 않으면 나중에 데이터를 분석하고 추세와 패턴을 찾는 능력이 차단됩니다. 이것은 효과적인 문제 관리 및 향후 인시던트 방지에 있어 중요한 부분입니다.
그러니 잊지 마세요. 또한 인시던트 범주를 쉽게 사용자 지정할 수 없는 IT 서비스 데스크 솔루션에 안주하지 마세요.
인시던트 우선 순위 지정
두 번째로, 모든 인시던트의 우선 순위를 지정해야 합니다.
인시던트의 우선 순위를 지정하려면 먼저 인시던트가 비즈니스에 미치는 영향을 평가하는 것부터 시작하세요. 영향을 받는 관련자의 수와 인시던트가 잠재적으로 재무, 보안 및 컴플라이언스에 미치는 영향을 모두 고려하여 인시던트로 인한 어려움의 정도와 비즈니스에 대한 해결책이 얼마나 시급한지를 파악하세요.
여기에서 모범 사례는 인시던트가 발생하기 전에 심각도 및 우선 순위 수준을 정의하여 인시던트 관리자가 우선 순위를 빠르게 알아낼 수 있게 하는 것입니다.
우선 순위 수준이 확실하지 않은 경우 더 높은 우선 순위를 지정합니다. 심각한 문제를 간과하는 것보다 지나치다 싶을 정도로 조심하는 편이 더 낫습니다.
우선 순위를 지정한 후에는 모든 미해결 인시던트를 우선 순위에 따라 해결합니다. 대부분의 조직은 각 우선 순위 수준에 대해 명확한 서비스 계약을 설정하므로 고객은 대응 및 해결에 시간이 얼마나 걸릴지 알 수 있습니다. 반드시 필요한 작업입니다.
대응
인시던트 대응은 폭넓게 사용되는 용어이므로, 인시던트를 식별, 분류 및 우선 순위를 지정한 후에 수행할 가능성이 가장 높은 단계로 조금 더 세분화하겠습니다.
초기 진단
병원에서 새로 내원하는 환자를 분류하는 것과 같은 분류 기능이라고 생각하세요. 서비스 데스크 직원은 무엇이 잘못되었는지에 대한 빠른 가설을 수립하고 있으므로 문제 해결을 시작하거나 적절한 절차를 따르고 올바른 리소스를 모아서 문제를 해결할 수 있습니다.
기술 자료 및 진단 매뉴얼 역시 이 단계에서 유용한 도구입니다.
첫 번째 수준의 서비스 데스크 에이전트가 자신의 초기 진단 및 사용 가능한 기술 자료 및 도구를 사용하여 인시던트를 해결할 수 있는 경우 인시던트는 해결된 것입니다. 그렇지 않으면 에스컬레이션해야 할 차례입니다.
인시던트 에스컬레이션
에스컬레이션은 부정적인 단어처럼 들리지만 그렇지 않습니다.
전면 지원 팀은 에스컬레이션하지 않은 가장 자주 발생하는 많은 인시던트를 해결할 수 있어야 합니다. 하지만 그럴 수 없는 경우 목표는 올바른 정보를 수집하고 로깅하여 두 번째 및 세 번째 수준(더 기술적인)의 지원 팀이 인시던트를 즉시 해결할 수 있도록 속도를 내는 것을 지원하는 것입니다.
조사 및 진단
ITIL은 이것을 별도로 하나의 단계로 강조합니다. 실제로 이 단계는 인시던트 수명 주기 전반에 걸쳐 발생합니다.
전면 지원 담당자는 정보를 수집하는 시점을 어느 정도 이미 조사하고 있으며 에스컬레이션이 필요 없이도 인시던트를 진단하고 해결할 수도 있습니다.
이 경우 해결 및 복구와 인시던트 종결이라는 몇 가지 단계를 바로 건너뛰었습니다.
그렇지 않으면 해결책을 상담하고 지원하기 위해 수준 2 또는 수준 3 지원으로 에스컬레이션하거나 외부 리소스 또는 기타 부서의 팀원을 도입할 때 모든 단계에서 조사 및 진단이 이루어집니다.
해결 및 복구
결과적으로(그리고 가능하면 확립된 서비스 수준 계약(SLA) 내에서) 진단을 완료하고 인시던트 해결에 필요한 단계를 수행합니다. 적절한 해결 방법을 식별한 후에도 일부 수정(예: 버그 패치 등)을 테스트하고 배포해야 할 수 있으므로, 복구는 운영을 완전히 복원하는 데 걸리는 시간을 의미합니다.
인시던트 종료
그런 다음 인시던트를 서비스 데스크로 다시 전달하여(에스컬레이션된 경우) 종료합니다. 품질을 유지하고 원활한 프로세스를 보장하기 위해 서비스 데스크 직원만 인시던트를 종료할 수 있으며, 인시던트 소유자는 인시던트를 보고한 사용자에게 해결이 만족스럽고 인시던트를 종료해도 되는지 확인해야 합니다.
결론: 단계를 건너뛰지 마세요
특히 서비스 데스크 분석가가 몇 명뿐인 경우 프로세스가 불필요하게 형식적으로 보일 수 있습니다. 그러나 팀 구조와 관계없이 인시던트 수명 주기는 여전히 동일합니다.
서비스 데스크 분석가가 한 명뿐이므로 수준 3 지원이 없다고 가정해 보겠습니다. 하지만 서비스 데스크 분석가의 지식을 능가하는 인시던트의 경우 수석 엔지니어든 외부 컨설턴트든 또는 여러분이든 맡아 해결해야 합니다.
결국 여러분이나 엔지니어를 통해 이미 수준 2 또는 수준 3 지원을 갖춘 셈입니다.
요점을 말씀드리자면, ITIL은 의미론에 관한 것처럼 보일 수 있지만 의미론에 사로 잡히지 마세요. 위에서 설명한 것처럼 간단한 IT 서비스 관리 프레임워크에 맞게 조직의 계층 구조 및 프로세스 워크플로를 조정할 수 있는 쉬운 방법을 찾으세요.
이렇게 하면 더 뛰어난 고객 서비스를 제공하고 비즈니스에 훨씬 더 많은 가치를 제공할 수 있습니다. (게다가 정신없는 상태를 방지할 수 있다는 점은 덤입니다!)
마지막으로 몇 가지 내용을 요약해 보겠습니다.
- 모든 인시던트를 로그합니다. 고유한 번호를 지정합니다. 그리고 중앙 집중식 지원 센터 시스템에서 날짜, 시간, 설명과 같은 중요한 세부 정보를 캡처합니다.
- 인시던트 업데이트를 전달할 내부 또는 외부 대상이 많은 경우 인시던트 커뮤니케이션을 위한 상태 페이지를 만드는 것을 고려하세요.
- 모든 인시던트에 범주(및 필요에 따라 하위 범주)를 할당합니다.
- 모든 인시던트에 우선 순위 수준을 부여하고 모든 우선 순위 수준을 SLA로 지정합니다.
- 인시던트 관제자, 주요 인시던트 관리자, 커뮤니케이션 리더와 같은 인시던트 대응자의 역할을 명확하게 정의해 둡니다.
- 가능하면 기술 자료 문서 및 인시던트 진단 스크립트로 전면 지원 팀을 지원하여 인시던트를 신속하게 해결합니다.
- 서비스 데스크에서 인시던트 진행률, 라우팅 및 상태를 항상 제어하는지 확인합니다.
- 인시던트 데이터를 캡처하는 데서 그치지 말고 데이터를 분석하세요! 인시던트의 수를 줄이고 위험을 완화할 수 있는 추세, 패턴 및 잠재적인 근본 문제를 찾아보세요.
작성자 소개
Nick Wright
Atlassian 서비스 운영 관리자
우리 팀과 저는 Atlassian의 클라우드 애플리케이션과 인프라가 최고 수준의 성능을 발휘하고 있는지 확인하고 있으며 빠르게 확장하면서 어떻게 수행하는지 공유하고 싶습니다. 저는 뉴질랜드 사람이지만 언어적 장애에도 불구하고 여전히 피쉬 앤 칩스를 발음할 수 있습니다. 업무 외 시간에는 자전거를 타거나 게임을 하거나 아내와 사랑스러운 딸과 함께 시간을 보냅니다.