중대 사건 관리: 개요

중대 사건 관리: 개요

지금은 월요일 아침이고 서비스 데스크는 매우 정상적으로 처리되고 있습니다. 갑자기, 중요 서비스가 다운되었는 경고 티켓을 받게 되고, 15분 이내에 동일한 문제를 신고하는 티켓이 쏟아져 들어오기 시작합니다. 그것은 귀사의 웹사이트가 다운된 것일 수도 있고, POS 소프트웨어가 정지한 것일 수도 있으며 또는 주식 거래소가 정지되었거나 비행기가 추락하는 등의 훨씬 더 큰 충격일 수도 있습니다. 귀하의 비즈니스가 수입 및/또는 명성의 손실을 유발하는 IT 문제로 심각한 영향을 받는다면, 귀하는 중대 사건에 직면한 것입니다.

중대 사건에 어떻게 대응 하느냐에 따라 사건의 영향을 최소화하고 서비스를 다시 원상으로 복구하는 데 있어서 차이가 발생합니다. 흔히 말하듯, 시간은 돈입니다. 그리고 이 경우에는 그 말이 더욱 더 절실하게 느껴집니다. 귀하의 조직에서 중대 사건 관리(MIM) 프로세스를 실행 중이라면, 귀하는 중대 사건에 대해 신속하게 대응하고 이를 해결할 수 있습니다. 만약 그러한 프로세스가 없다면, 중대 사건 대응 프로세스라고도 알려진 비상 대응 계획을 수립할 때입니다.

중대 사건에 따른 이해관계는 그 어느 때보다도 더 큽니다. Information Technology Intelligence Consulting의 연구 조사 에 따르면, 98%의 기업들이 만약 1시간 동안 서비스가 중단될 경우 최소 $100,000의 손실을 보게 된다고 합니다. 이러한 사실은 중대 사건을 효과적으로 그리고 효율적으로 다룰 수 있는 MIM 프로세스의 수립에 대한 중요성을 일깨워줍니다.

모든 조직은 중대 사건을 없애는 것을 목표로 삼지만, 결론부터 말하자면 중대 사건을 완전히 방지하기란 불가능하며 오직 할 수 있는 일은 그것에 대한 대비를 하는 것뿐입니다.

이 안내서에서, 우리는 효과적인 MIM 프로세스를 설정하는 방법, 조직의 MIM에 영향을 줄 수 있는 흔한 실수, MIM 프로세스를 개선하기 위한 모범 실무에 대해 살펴봅니다.

하지만 먼저 어떤 사건을 주요 사건으로 만드는 것은 무엇일까요?

중대 사건이란?

중대 사건이란

중대 사건은 전체 조직 또는 조직의 주요 부분에 영향을 주는 영향력이 크고 긴급한 문제입니다. 중대 사건은 거의 언제나 조직의 서비스를 이용할 수 없게 만들어, 해당 조직의 비즈니스에 타격을 주고 궁극적으로 재무상태에 영향을 줍니다. 중대 사건이 조직의 서비스에 영향을 줄 수 있는 방법에는 두 가지가 있습니다.

  • 고객이 조직의 서비스에 액세스하는 것을 차단. 2019년 7월 Cloudflare의 중단 사태는 중대 사건으로 고객이 영향을 받은 예입니다. 이 중대 중단 사태는 거의 절반의 인터넷에 영향을 주었으며 수 백만의 인터넷 사용자들이 다양한 서비스를 이용할 수 없었습니다.
  • 직원들이 작업을 제 시간에 마칠 수 있는 능력을 방해하여, 비즈니스의 혼란을 초래. 2019년 11월 IndiGo의 중단 사태는 항공사의 체크인 프로세스에 영향을 주어 장시간 지연을 초래했고 수 천명의 승객들에게 영향을 주었습니다.

서비스 데스크에 준비가 잘 되어 있다면 중대 사건을 평가할 수 있으며 중대 사건의 영향을 줄이거나 제어하는 솔루션 또는 차선책을 강구할 수 있습니다.

중대 사건의 4단계

중대 사건에는 4가지 단계가 있는 것으로 알려져 있습니다.

중대 사건의 4단계

중대 사건 관리 프로세스

MIM 프로세스가 중대 사건의 비즈니스 영향을 최소화시키는 데 도움을 주므로 이것은 조직에 필수적인 것입니다. MIM 프로세스는 주로 다음의 단계로 구성됩니다.

1. 파악

파악

1. 파악

중대 사건 선언:

첫 번째 단계는 가능한 중대 사건을 파악하는 것입니다. 조직들은 위협을 파악할 수 있는 다수의 방법을 수립해야 합니다. 중대 사건은 비정상적인 티켓을 발견할 때 테크니션들이 플래그 표시를 하거나, 네트워크 문제를 자동으로 플래그 표시하고 티켓을 생성하여 서비스 데스크에 경고할 수 있는 네트워크 모니터링 도구와 같은 솔루션으로 탐지할 수 있습니다. 또한 조직들은 서비스 데스크 직원이 의심스러운 중대 사건에 플래그 표시를 할 수 있도록 전용 직통 전화를 설치할 수 있습니다.

이해관계자들에게 통보:

중대 사건이 파악되면, 모든 핵심 이해관계자들에게 전달해야 합니다. 다음 네 그룹이 중대 사건을 전달받아야 합니다.

  • 기술팀: 즉시 기술팀에 통보하여 해당 문제를 해결하기 위한 조치에 대한 결정을 시작할 수 있도록 해야 합니다.
  • 경영진: CIO와 같은 상부 경영진에게 중대 사건을 알리면 책임감을 갖게 됩니다. 또한 경영진에게 중대 사건의 해결을 위해 취해지는 모든 단계를 알려야 합니다.
  • 주요 이해관계자들: 부서장들과 서비스 레벨 비즈니스 경영진 또한 중대 사건에 대해 알아야 하고 정기적인 상황 업데이트를 받아야 합니다.
  • 사용자: 사용자들은 중대 사건 때문에 어느 서비스를 이용할 수 없는지를 알아야 합니다.

2. 억제

억제

2. 억제

중대 사건팀 조직:

중대 사건팀 또는 MIT는 테크니션, 서비스 레벨 관리팀장 그리고 다른 주요 이해관계자들로 구성되며, 때로는 고도로 숙련된 외부 전문가를 초빙하여 중대 사건을 다루게 할 수도 있습니다. MIT는 함께 협력하여 중대 사건의 해결책을 찾고 운영을 정상으로 복구합니다.

컨퍼런스 브릿지 수립:

컨퍼런스 콜로 더 잘 알려진 컨퍼런스 브릿지는 효과적인 문제해결과 중앙화된 커뮤니케이션으로 도움을 줍니다. 컨퍼런스 브릿지는 MIT의 구성원들 사이에서 명확하고 빠른 커뮤니케이션 채널 역할을 합니다.

지정 상황실 준비:

지정 상황실을 갖춤으로써 MIT의 모든 구성원들이 모여 사건의 문제를 해결할 수 있습니다. 이를 통해 협업 노력이 증가하고, MIT가 더 빠르게 해결책을 구하는 데 도움을 줍니다.

근원 문제를 파악하기 위한 문제 티켓 만들기:

문제 티켓을 만들어 중대 사건의 근본 원인을 발견하고 이해할 수 있습니다. 이를 통해 중대 사건의 원인을 해결함으로써 향후 유사한 중대 사건을 방지할 수 있습니다.

3. 해결

해결

3. 해결

변경으로 해결 계획 실행:

중대 사건에 대한 해결책을 변경으로 실행함으로써 해당 해결책을 적절하게 문서화하고 실행하는 것이 좋습니다. 해결책을 변경으로 실행하면 잘못 계획된 해결책이 다른 서비스에 지장을 주는 위험을 최소화할 수 있습니다.

4. 유지 관리

유지 관리

4. 유지 관리

실행 후 검토 수행:

중대 사건이 정말로 해결되었는지 확인하기 위해 일정 기간에 걸쳐 사건을 적재하는 것이 중요합니다. 만약 근본 문제가 해결되지 않고 남아 있으면, 다른 중대 사건으로 이어질 수 있습니다.

명확한 문서 생산:

중대 사건을 해결하는 전체 프로세스를 문서화하면 조직이 향후 유사한 사건에 대비하는 데 도움을 줍니다. 과거의 사건을 적합하게 문서화함으로써, 해당 조직은 다른 유사한 중대 사건에 직면했을 때 즉시 시도해보고 테스트해본 해결책을 실행함으로써 그 영향을 줄일 수 있습니다.

메트릭스 측정:

서비스 데스크의 성능을 측정하면 서비스 데스크와 MIM 프로세스의 효과성을 측정하는 데 도움이 됩니다. 일부 중요한 측정 메트릭스는 평균 인지 시간(MTTA), 평균 해결 시간(MTTR), 중대 사건의 전체 수 및 중대 사건에 대한 평균 다운타임입니다.

효과적인 중대 사건 관리 프로세스에 대한 모든 상자에 체크표시하십시오

ITIL 중대 사건 관리 프로세스 플로우 차트

ITIL 중대 사건 관리 프로세스 플로우 차트

중대 사건 관리의 역할과 책임

중대 사건 관리의 역할과 책임

중대 사건의 경우 해당 사건을 다루고 해결할 일단의 특수 전문가를 필요로 합니다. MIM 역할:

서비스 데스크 테크니션:

서비스 데스크 테크니션은 중대 사건에 대한 일차 방어선입니다. 이들은 사건 티켓을 분석하고 이를 사건 관리자에게 상승시킵니다. 또한 서비스 데스크 테크니션은 해결책의 실행에 관여합니다.

중대 사건 관리자:

중대 사건 관리자는 중대 사건의 소유자입니다. 이들의 역할에는 해당 사건을 중대 사건으로 선언하고 MIM 프로세스가 수반되며 해당 사건이 신속하게 해결될 것을 보장하는 것이 포함됩니다 . 이들은 중대 사건에 관한 정보에 대한 주요 연락 포인트로 행동하고 MIT를 관리합니다.

MIT:

MIT는 중대 사건을 분석하고 위협을 처리할 행동 계획을 구성할 책임이 있는 전문팀입니다. MIT는 서비스 데스크 테크니션, 서비스 레벨 관리 인력, 기술 직원, 기타 관련이 있는 이해관계자, 상황에 따라 외부 컨설턴트 등으로 구성되는 것이 이상적입니다.

기술 직원:

조직의 기술 직원을 구성하는 sysadmins, 네트워크 관리자, 정보 보안 직원을 포함하는 인프라와 운영의 유지에 대한 책임을 지는 전문화된 인력. 기술 직원은 중대 사건을 문제 해결하고 중대 사건 해결책의 실행에 대한 책임을 주로 맡습니다.

변경 관리자:

변경 관리자는 중대 사건에 대한 교정을 실행하기 위해 만들어지는 변경의 소유자입니다. 변경 관리자는 변경 티켓에 대한 완전한 소유권을 가지며 그에 대한 책임을 집니다.

문제 관리자:

만약 중대 사건에 대한 대응으로 문제가 만들어지는 경우, 문제 관리자는 문제 티켓을 소유합니다. 문제 관리자는 해당 사건의 근본 원인을 확인하려 하고 다시 발생하지 않도록 하거나, 또는 적어도 다음에 그러한 사건이 발생한 경우 조직이 대비를 할 수 있도록 합니다.

외부 컨설턴트 또는 제3자 업체:

일부 경우, 중대 사건에는 사건을 이해하고 문제해결하기 위한 고도로 전문화된 인력 필요할 수 있습니다. 중대 사건 관리자는 필요한 인력을 파악하고 이들을 MIT에 추가시켜 중대 사건의 영향을 줄이도록 지원합니다.

RACI 매트릭스

RACI 매트릭스는 프로세스에서 다양한 이해관계자의 책임을 정의합니다. 아래의 표는 MIM 프로세스를 통해 중대 사건 이해관계자의 역할과 책임을 정의합니다.

프로세스/역할서비스 데스크 테크니션중대 사건 관리자MIT기술 직원변경 관리자문제 관리자외부 컨설턴트
파악
중대 사건 선언CARCIII
이해관계자들에게 통보CARIIII
억제
MIT 구성IR/ACCICI
컨퍼런스 브릿지 수립IARCICI
지정 상황실 준비IARIICI
근원 문제를 파악하기 위한 문제 티켓 만들기IARCIII
해결
변경 으로 해결 계획 구현IIIRACC
유지 관리
구현 후 검토 수행ICIRACI
명확한 문서 생산CARCCCC
메트릭스 측정IARIIIC

* R - 책임 있는, A - 의무가 있는, C - 상담하는, I - 정보에 입각한

중대 사건 관리에서 흔히 저지르는 5가지 실수

중대 사건 관리에서 흔히 저지르는 5가지 실수

다음은 MIM 프로세스를 방해할 수 있는 5가지 흔한 실수입니다.

  1. 수작업 커뮤니케이션과 에스컬레이션:

    현재까지 MIM에 대한 가장 큰 어려움은 커뮤니케이션입니다. 중대 사건이 발생한 경우, 다양한 이해관계자들에게 사건의 상태, 심각도, 사건 해결을 위해 수행해야 하는 문제해결을 통보해야 합니다. 이 모든 것을 수작업으로 커뮤니케이션하는 것은 힘든 작업이며, 일관적이지 않은 커뮤니케이션으로 이어져 상황을 더욱 악화시킬 뿐입니다. 이 프로세스를 자동화함으로써, 전체 티켓 수명 주기 내내 주요 이해관계자들에게 통보하고, 중대 사건관리자는 모든 주의를 문제 해결에 기울일 수 있습니다.

  2. 중대 사건 신고에 대한 비효과적인 채널:

    모든 서비스 데스크는 랩톱 문제에서부터 서비스 요청에 이르기까지 하루에 수십 개 또는 심지어 수 백 개의 티켓을 접수하며, 이러한 산더미 같은 티켓 중에 몇 개의 잠재적인 중대 사건이 있을 수 있습니다. 중대 사건을 신고하는 별도의 채널을 설정하지 않으면 중대 사건을 파악하는 것이 지연됩니다.

  3. 노력의 중복:

    작업을 체계적인 방법으로 위임하지 않으면 MIT 내에서 노력이 중복될 수 있습니다. 작업을 할당하고 MIT에 각 구성원이 어떤 작업을 하는지를 통보하는 것이 중요합니다.

  4. 잘못된 문서화:

    적절한 문서화가 이루어지지 않을 경우 MIT가 유사한 중대 사건이 발생할 때마다 매번 쓸데 없이 시간을 낭비해야 하므로, 중대 사건을 해결하는 것이 지연되고 불필요한 다운타임을 초래하게 됩니다.

  5. 근본 원인 분석 실패:

    사건 관리와 마찬가지로, MIM은 주된 초점이 문제를 해결하고 가능한 최단시간 내에 서비스를 가동시키는 것이므로 범위가 근시안적일 수 있습니다. 문제 관리와 병합하여 근본 원인을 파악하지 않는다면, 중대 사건의 근본 원인으로 인해 해당 조직은 계속해서 중대 사건에 취약하게 될 것입니다.

5가지 중대 사건 관리 모범 실무

5가지 중대 사건 관리 모범 실무

다음은 MIM에 접근하는 최고의 방법들입니다.

  1. 중대 사건을 신고하는 다수의 채널 사용:

    중대 사건의 취급에 대해 말할 때, 시간이 핵심입니다. 조직이 중대 사건을 감지하는 순간 바로 그것을 파악하고 분류하는 것이 매우 중요합니다. 사용자들에게 사건을 신고하는 다수의 방법을 제공함으로써 전체 프로세스를 더 빠르게 만들고 더 액세스를 쉽게 할 수 있습니다. 이메일 또는 웹 포털을 통해 티켓을 만들게 하거나, 전용 직통 전화를 설치하여 의심이 가는 중대 사건을 신고하게 할 수 있습니다. 네트워크 모니터링 소프트웨어를 설치하여 비정상적인 현상을 감지함으로써 중대 사건을 선제적으로 처리할 수 있습니다.

  2. 서비스 데스크 프로세스 자동화:

    중대 사건의 영향을 제어하는 데 있어 속도와 효율성은 중대한 역할을 합니다. 다양한 서비스 데스크 프로세스를 자동화함으로써 테크니션들을 이해관계자들에 대한 통보와 같은 반복적인 업무로부터 해방시켜 이를 달성하게 도울 수 있습니다. 알림 시스템을 자동화하고 중대 사건 워크플로를 수립하는 것은 서비스 데스크 프로세스를 자동화시켜 해결 시간을 개선하고 MIM 프로세스를 구조화시키는 데 좋은 방법입니다.

  3. 즉각적이고 타당한 커뮤니케이션을 위해 노력:

    조직의 경영진과 중요 이해관계자들에게 모든 중대 사건을 알리는 것이 중요합니다. 루프에서의 관리 유지는 중대 사건을 교정하는 데 필요한 승인과 권한을 받는 데 도움을 줍니다. 즉각적인 커뮤니케이션으로 중대 사건의 모든 관련자들이 같은 내용을 파악하게 되어 매끄럽고 효과적인 협업이 가능해집니다. 또한, 최종 사용자들은 가능한 다운타임에 대해 통보받게 되므로 그에 대비할 수 있게 됩니다.

  4. 명확한 문서화:

    중대 사건 관리자는 명확한 문서화를 통해 중대 사건을 교정하느라 완료한 모든 작업, 그 영향, 영향을 받은 서비스와 중대 사건에 관한 기타 주요 정보를 기록할 수 있습니다. 이 문서화는 ROI를 포함하여 MIM 프로세스를 이용함으로써 얻는 혜택을 경영진에게 보여주는 데 중요합니다. 명확한 문서화는 또한 향후의 유사 중대 사건에도 도움을 줄 수 있습니다.

  5. ITOM 소프트웨어와의 견고한 통합 활용:

    ITOM 소프트웨어와의 통합이 견고할 경우 IT 부서에서 중대 사건을 선제적으로 취급할 수 있습니다. 반응적인 중대 사건의 식별은 중대 사건이 진행 중이라는 레드 플래그를 제기하는 티켓의 홍수에 달려 있습니다. 한편, ITOM 통합을 활용하는 선제적인 MIM 프로세스에는 네트워크와 서비스를 모니터하는 시스템이 있으며, 중대 사건이 될 가능성이 있는 변칙적인 사건에 자동으로 플래그 표시할 수 있습니다.

고유의 모범 중대 사건 관리 프로세스 실무를 설정하는 방법 배우기

중대 사건 관리의 메트릭스와 KPI

MIM에 대해 말할 때, 다음은 추적해야 할 일부 중요한 메트릭스와 KPI입니다.

KPI수식의견
평균 해결 시간(MTTR)중대 사건이 신고된 때부터 해결될 때까지의 평균 시간.이것은 서비스 데스크가 얼마나 신속하게 중대 사건을 해결했는가를 나타냅니다.
평균 인지 시간(MTTA)중대 사건에 대응하는 평균 시간.MTTA가 짧을수록 서비스 데스크가 중대 사건에 빨리 대응함을 나타냅니다.
평균 고장 간격(MTBF)고장 사이의 평균 시간. 총 가동 시간을 총 고장 수로 나누어 계산합니다.이것은 IT 인프라의 성능을 나타냅니다. MTBF가 클수록 IT 인프라가 잘 수행되고 있음을 알려줍니다.
평균 탐지 시간(MTTD)중대 사건이나 비정상을 탐지하는 데 걸리는 평균 시간.이것은 중대 사건이 얼마나 빨리 파악되는가를 측정합니다. MTTD가 작을수록 서비스 데스크가 중대 사건을 빠르게 탐지한다는 신호입니다.
중대 사건의 퍼센트 증가 또는 감소첫 번째 달과 관련하여 추후에 문제의 퍼센트 증가.이는 중대 사건 발생의 추세를 파악하는 데 도움이 됩니다.

중대 사건 시나리오

중대 사건 시나리오

우선순위가 높은 모든 사건들이 전부 중대 사건은 아니라는 점을 명심해야 합니다. MIM 프로세스에는 별도의 MIT를 실행하는 것과 같은 규모가 있는 리소스의 수용이 포함되기 때문에, 중대 사건을 신중하게 분류해야 합니다.

출처: https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

2019년 Cloudflare 사태는 무엇이 중대 사건인지를 알 수 있는 아주 좋은 사례입니다. 이 경우, 웹 애플리케이션 방화벽(WAF)에 대한 관리 규칙을 업데이트하는 표준 운영 절차가 HTTP/HTTPS 트래픽에 전담 사용되는 CPU의 사용을 Cloudflare의 네트워크에 있는 서버 전체에서 거의 100% 가까이 급증시켰습니다. 이 사태는 Cloudflare의 트래픽의 80퍼센트를 감소시키는 결과를 초래했고, 전 세계 수 백만 명의 인터넷 사용자들이 영향을 받았습니다.

영향도: 크게

이 사태의 결과로 Cloudflare의 고객들(그리고 그들의 고객들)은 Cloudflare 도메인을 방문할 때 502 오류 페이지를 봐야 했습니다. 502 오류는 아직 이용 가능한 CPU 코어를 보유하고 있지만 HTTP/HTTPS 트래픽을 담당하는 프로세스에 도달할 수는 없었던 프론트-엔드 Cloudflare 웹 서버가 생성했습니다. 27분의 다운타임 동안 적어도 전체 인터넷의 절반이 액세스가 불가능했었을 것으로 추정됩니다.

긴급도: 높음

Cloudflare의 모든 웹사이트에 액세스가 불가능하여 수 천곳의 조직과 수 백만의 사용자들에 대한 서비스 장애가 발생했습니다. 이 사태는 Cloudflare의 내부 운영에도 영향을 미쳐, Cloudflare 직원이 회사의 변경관리 도구 및 내부 제어판과 같은 다양한 서비스에 액세스할 수 없게 되었습니다. 정상 서비스 운영을 재개하기 위해서는 이 사태를 처리해야만 했습니다.

탐지에서 해결까지의 이벤트 타임라인:

WAF 관리 규칙은 13:42에 실행되었습니다. 3분 후, Cloudflare의 네트워크 운영 도구가 트래픽의 감소를 플래깅하기 시작했습니다. Cloudflare 서비스의 다른 많은 종단간 테스트에 문제가 발생하기 시작했습니다. 최종 사용자는 다양한 502 오류를 목격했습니다. Cloudflare는 세계 각국의 도시에 있는 접속 포인트에서 CPU 소진의 보고를 받았습니다.

사이트 신뢰성 엔지니어링 팀, 런던 엔지니어링 팀, 다른 관련 팀들이 문제 해결을 위해 소집되었고 마침내 해결책을 제시했습니다. 14:00경, WAF가 사건의 원인인 것으로 파악되었습니다. 14:07경, 글로벌 WAF 킬이 시행되어 트래픽 수준을 정상으로 되돌렸습니다.

14:52경, Cloudflare는 이 사태의 원인을 파악하여 시정 조치를 취함으로써, WAF가 다시 전 세계적으로 사용 가능하게 된 것에 100% 만족했습니다.

용어집

용어집

변경:

서비스에 직간접적 영향을 줄 수 있는 것의 추가, 수정 또는 제거.

변경 관리:

최소한의 혼란과 충돌로 변경을 완료하는 프로세스.

에스컬레이션:

기능 또는 계층 필요에 따라 티켓의 소유권을 이전하는 행위.

이벤트:

서비스 또는 자산의 관리에 대한 중요성을 갖는 사건.

실패:

서비스나 자산이 합의된 SLA에 따라 기능하지 않는 사건.

계층적 에스컬레이션:

소유권을 수직적으로 더 높은 계층의 서비스 데스크 테크니션 또는 관련 승인부서로 이전하는 행위.

영향도:

사건의 심각도 측정.

사건:

IT 서비스에 대한 계획되지 않은 방해나 IT 서비스의 수준 감소. 서비스에 영향을 미치지 않는다 할지라도 항목 구성의 실패 또한 사건임(예: 미러 세트 중 하나의 디스크 오류).

사건 관리:

모든 사건의 수명 주기를 관리하여 가능한 신속하게 정상 서비스 운영을 복원하고 비즈니스에 대한 영향을 최소화하는 프로세스.

사건 우선순위 배정:

사건에 우선순위를 배정하고 중대 사건의 구성 요소를 정의함.

중대 사건:

영향이 크고 긴급성 또한 높은 사건으로 일반 사건 관리와 별개의 프로세스가 필요함.

중대 사건 관리자:

MIT와 MIM 프로세스의 실행에 대한 책임을 지는 사람.

평균 인지 시간(MTTA)

서비스 데스크가 얼마나 빨리 사건을 인지하는가를 측정.

평균 탐지 시간(MTTD)

서비스나 구성 항목에 대한 잠재적 위협을 얼마나 빨리 탐지하는 가를 측정.

평균 고장 간격(MTBF)

서비스 또는 자산이 얼마나 자주 고장나는 지에 대한 측정.

평균 수리/해결/대응/복구 시간 (MTTR):

고장 후 서비스가 얼마나 빨리 복구되는 가에 대한 측정.

정상 서비스 운영:

서비스 수준 계약 (SLA)을 준수하는 서비스 운영.

문제:

하나 이상의 사건을 유발한 원인 또는 잠재적 원인.

RACI 매트릭스:

교차 기능적 또는 부서간 프로젝트와 프로세스에 있어서의 역할과 책임을 정의합니다.

서비스 데스크:

서비스 제공사와 조직의 사용자 간의 커뮤니케이션 포인트.

서비스 데스크 관리자:

서비스 데스크의 일상 활동을 감독하고 그 성과에 대한 책임을 지는 사람.

서비스 레벨 목표 (SLO):

서비스 제공자의 목적을 정의하며, 그 성능을 측정하는 수단.

SLA:

서비스의 기대수준 및 서비스가 제공되는 예상 시간에 관해 서비스 제공자와 고객 간에 체결하는 계약.

긴급도:

사건을 얼마나 빨리 해결해야 하는 가에 대한 측정.

ITSM이 사업 운영에 진정한 힘을 실어줄 수 있는 다양한 방법 발견.

이제 중대 사건에 대한 개요를 배웠고 MIM 프로세스를 설정하는 방법을 알았으므로, 견고한 사건 관리 프로세스를 실행하여 조직의 서비스 데스크가 일반 사건과 중대 사건 모두를 취급할 수 있도록 준비시켜야 합니다. 당사의 사건 관리 핸드북과 기타 ITSM 리소스의 무료 사본을 다운로드하세요.

  • 사건 관리 핸드북

    사건 관리 핸드북

  • 더 스마트한 ITSM을 위한 브레이니 북(Brainy Book)

    더 스마트한 ITSM을 위한 브레이니 북(Brainy Book)

  • ITIL 히어로의 핸드북

    ITIL 히어로의 핸드북

 
'무료 ITSM 리소스 받기' 를 클릭하면 개인정보 보호정책에 따른 개인 정보 처리에 동의하는 것입니다.