인시던트 관리 데이터 템플릿
인시던트 관리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- Jira Service Management 데이터 추출 안내
인시던트 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
시작 시간
EventTimestamp
|
활동이 발생한 정확한 날짜와 시간입니다. | ||
|
설명
이 속성에는 인시던트 생애주기의 각 활동이 발생한 시각이 기록됩니다. 프로세스 단계별 소요 시간, 처리 주기, 대기 시간을 계산하는 데 필요합니다. 정확한 타임스탬프가 있으면 성과를 자세히 분석하고 SLA를 모니터링하며 병목을 찾을 수 있습니다. 해결 시간과 진단 시간 등 모든 성과 지표는 이 타임스탬프를 바탕으로 계산합니다.
중요한 이유
타임스탬프는 시간 기반 지표를 계산하고 프로세스 소요 시간을 파악하며 성과 병목을 찾는 데 필요합니다.
확보 방법
Jira 이슈의 변경 내역이나 기록에 각 항목의 'created' 날짜로 저장됩니다.
예시
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
인시던트 ID
IncidentId
|
Jira Service Management에서 각 인시던트 티켓을 고유하게 식별하는 값입니다. | ||
|
설명
Jira에서 이슈 키라고도 하는 인시던트 ID는 접수된 각 인시던트를 고유하게 식별합니다. 생성부터 최종 종료까지 관련된 모든 활동, 댓글, 상태 변경을 연결합니다. process mining에서는 이 ID를 바탕으로 개별 인시던트의 전체 생애주기를 재구성하고 프로세스 전반을 분석합니다.
중요한 이유
관련 이벤트를 하나의 케이스로 연결하는 기본 식별자이며, process mining 분석의 토대가 됩니다.
확보 방법
Jira Service Management에서 이슈에 사용하는 표준 'Key' 필드입니다(예: 'ITSM-123').
예시
INC-10234HELPDESK-5678OPS-9901
|
|||
|
활동
ActivityName
|
인시던트에서 발생한 특정 이벤트 또는 상태 변경의 이름입니다. | ||
|
설명
활동은 인시던트 관리 생애주기의 개별 단계나 이벤트를 나타냅니다. 예를 들면 '인시던트 생성', '인시던트 할당', '해결 방안 제안' 등이 있습니다. 일반적으로 Jira 이슈의 기록이나 변경 내역에 저장된 상태 전환 또는 특정 업데이트 이벤트에서 가져옵니다. 활동의 순서와 소요 시간을 분석하면 실제 프로세스 흐름과 병목, 편차를 파악할 수 있습니다.
중요한 이유
활동은 프로세스 맵의 기본 구성 요소로, 인시던트 생애주기를 시각화하고 분석하는 데 사용됩니다.
확보 방법
Jira 이슈 기록과 변경 내역에서 가져오며, 상태 전환과 주요 필드 업데이트를 담습니다.
예시
인시던트 담당자 지정조사 시작인시던트 해결
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
소스 시스템에서 데이터를 마지막으로 새로 고친 시각입니다. | ||
|
설명
이 속성에는 데이터셋을 마지막으로 업데이트한 시각이 기록됩니다. 분석 시 데이터가 최신 상태인지 확인할 수 있습니다. 최신 정보에 따라 신속히 판단해야 하는 모니터링 대시보드에서 특히 중요합니다. 일반적으로 한 번의 데이터 추출 작업에 포함된 모든 이벤트에 같은 값이 적용됩니다.
중요한 이유
데이터가 얼마나 최신인지 알려 주므로 분석의 적시성과 정확성을 판단하는 데 도움이 됩니다.
확보 방법
데이터 변환 과정에서 추가하는 데이터 추출 작업의 타임스탬프입니다.
예시
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
소스 시스템
SourceSystem
|
데이터를 추출한 시스템입니다. | ||
|
설명
이 속성은 데이터의 출처를 나타냅니다. 여기서는 Jira Service Management가 해당합니다. 여러 시스템의 데이터를 결합해 프로세스 전체를 살펴볼 때 특히 유용합니다. 소스 시스템을 지정하면 데이터 계보를 명확히 하고 데이터 품질이나 추출 문제를 진단하는 데 도움이 됩니다. 이 모델에서는 값이 고정됩니다.
중요한 이유
데이터 출처를 명확히 하고 추적할 수 있도록 합니다. 여러 시스템을 함께 분석할 때 특히 유용합니다.
확보 방법
데이터 추출 과정에서 추가하는 고정값입니다.
예시
Jira Service ManagementJira Cloud
|
|||
|
담당 그룹
AssignmentGroup
|
인시던트 처리를 맡은 팀 또는 그룹입니다. | ||
|
설명
담당 그룹은 인시던트 처리를 맡은 팀을 나타냅니다. 'L1 헬프데스크'와 같은 지원 단계별 팀, '네트워크 운영'과 같은 전문 팀, 개발팀 등이 해당할 수 있습니다. 담당 그룹 간 전환을 분석하면 에스컬레이션과 업무 인계가 어떻게 이루어지는지 파악할 수 있습니다. 이를 통해 팀별 성과를 측정하고 병목과 팀 간 의존성을 확인할 수 있습니다.
중요한 이유
팀 성과와 처리량을 분석하고 지원 단계 또는 전문 그룹 간 업무 흐름을 파악하는 데 필요합니다.
확보 방법
Jira에서 'Team' 또는 'Assignment Group'과 같은 사용자 지정 필드로 구현하는 경우가 많습니다. Jira Components나 Project Roles를 바탕으로 값을 도출할 수도 있습니다.
예시
1차 지원팀인프라팀데이터베이스 관리자
|
|||
|
담당자
Assignee
|
현재 인시던트 처리를 맡은 사용자입니다. | ||
|
설명
담당자는 특정 시점에 인시던트 처리를 책임지는 에이전트 또는 사용자입니다. 담당자 변경을 추적하면 업무 인계와 업무량 분포를 분석하고, 특정 프로세스 단계에 참여한 담당자를 파악할 수 있습니다. 이 속성은 지원팀 내 개인별 성과와 리소스 배분에 관한 질문에 답하는 데 도움이 됩니다.
중요한 이유
개인별 업무량을 추적하고 특정 담당자와 관련된 병목을 찾으며, 인계가 해결 시간에 미치는 영향을 분석하는 데 도움이 됩니다.
확보 방법
Jira 이슈의 표준 'Assignee' 필드입니다.
예시
John SmithEmily JonesServiceDeskAgent1
|
|||
|
상태
Status
|
생애주기에서 인시던트가 현재 진행 중인 단계입니다. | ||
|
설명
상태 필드는 정의된 워크플로에서 인시던트의 현재 상태를 나타냅니다. 예를 들면 '열림', '진행 중', '고객 응답 대기', '해결됨' 등이 있습니다. 상태 변경은 process mining에 사용할 활동 로그를 생성하는 주요 데이터입니다. 각 상태에 머문 시간을 분석하면 병목을 찾고 인시던트가 가장 오래 지체되는 구간을 파악할 수 있습니다.
중요한 이유
인시던트 진행 상황을 직접 보여 주며, 프로세스 단계와 대기 시간을 파악하는 주요 데이터입니다.
확보 방법
Jira 이슈의 표준 'Status' 필드입니다.
예시
진행 중고객 응답 대기해결됨종료됨
|
|||
|
생성 날짜
CreatedDate
|
시스템에서 인시던트를 처음 생성한 날짜와 시간입니다. | ||
|
설명
이 속성은 인시던트 생애주기의 공식 시작 시점을 나타냅니다. 전체 해결 시간과 같은 지표를 계산하는 기준 타임스탬프입니다. 인시던트별 생성 날짜는 고정값이며 process mining 분석에서 전체 케이스의 시작점으로 사용됩니다.
중요한 이유
전체 처리 주기와 SLA 측정의 시작점으로 사용됩니다.
확보 방법
Jira 이슈의 표준 'Created' 필드입니다.
예시
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
우선순위
Priority
|
해결의 긴급성을 나타내는 인시던트 우선순위입니다. | ||
|
설명
우선순위는 인시던트에 대응해야 하는 속도를 결정합니다. 일반적으로 영향도와 긴급도를 함께 고려하며 SLA 목표에도 직접 영향을 줍니다. 우선순위별로 인시던트를 분석하면 우선순위가 낮은 인시던트보다 높은 인시던트를 더 신속히 처리하는지, 우선순위 기준이 일관되게 적용되는지 확인할 수 있습니다. 프로세스 성과를 필터링하고 비교할 때 중요한 기준입니다.
중요한 이유
SLA 성과를 분석하고 가장 중요한 인시던트에 리소스가 적절히 배정되는지 확인하는 데 필요합니다.
확보 방법
Jira 이슈의 표준 'Priority' 필드입니다.
예시
최고높음보통낮음
|
|||
|
해결 날짜
ResolutionDate
|
인시던트가 해결됨으로 표시된 날짜와 시간입니다. | ||
|
설명
이 속성에는 인시던트가 처음 해결 상태로 전환된 시각이 기록됩니다. 실제 처리가 끝난 시점을 나타내며 해결까지 걸린 시간을 계산하는 기준이 됩니다. 해결 날짜와 생성 날짜를 비교하면 프로세스 효율성을 측정할 수 있습니다. SLA 준수 여부를 판단할 때도 중요한 값입니다.
중요한 이유
해결 프로세스의 종료 시점을 나타내며 전체 처리 시간과 SLA 성과를 계산할 수 있습니다.
확보 방법
Jira 이슈의 표준 'Resolved' 필드입니다.
예시
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
SLA 위반
SlaBreach
|
인시던트 해결 시간이 SLA 목표를 초과했는지 나타내는 표시입니다. | ||
|
설명
이 계산된 불리언 속성은 인시던트가 '해결까지 걸리는 시간' SLA를 위반했는지 나타냅니다. 'IncidentResolutionCycleTime'이 'TimeToResolutionTarget'보다 크면 참입니다. 이 표시를 사용하면 데이터를 쉽게 필터링하고 집계해 전체 SLA 위반율 KPI를 계산할 수 있습니다. SLA 성과 모니터링 대시보드에서 주요 결과 지표로 사용됩니다.
중요한 이유
SLA 성과를 위반 또는 준수로 명확히 구분해 위반율을 계산하고 문제가 있는 영역을 찾기 쉽게 합니다.
확보 방법
('IncidentResolutionCycleTime' > 'TimeToResolutionTarget') 조건으로 계산합니다.
예시
truefalse
|
|||
|
고객 요청 유형
CustomerRequestType
|
고객이 서비스 포털을 통해 제출한 요청의 구체적인 유형입니다. | ||
|
설명
이 필드는 Jira Service Management 포털에 표시되는 고객 관점의 요청 유형을 분류합니다(예: '시스템 문제 신고'). 내부 '이슈 유형'과 다를 수 있으며, 고객이 이해하기 쉬운 분류를 제공합니다. 이 속성을 분석하면 고객이 문제를 인식하고 신고하는 방식을 파악해 포털 설계와 서비스 제공을 개선할 수 있습니다.
중요한 이유
고객 관점에서 인시던트 유형을 살펴볼 수 있어 수요 분석과 고객 경험 개선에 유용합니다.
확보 방법
Jira Service Management 프로젝트 전용 'Customer Request Type' 필드입니다.
예시
IT 지원 받기 > 시스템 문제 신고이메일 > 액세스 요청
|
|||
|
구성 요소
Component
|
인시던트의 영향을 받은 시스템, 애플리케이션 또는 인프라 영역입니다. | ||
|
설명
구성 요소는 Jira 프로젝트의 이슈를 '사용자 인터페이스', '데이터베이스', 'API'와 같은 세부 영역으로 분류하는 단위입니다. 구성 요소별로 인시던트를 분석하면 시스템의 어느 부분에서 문제가 자주 발생하는지 파악할 수 있습니다. 이 정보는 근본 원인 분석에 유용하며 서비스 개선이나 기술 부채 감소를 위한 작업의 방향을 정하는 데 도움이 됩니다.
중요한 이유
영향을 받은 제품이나 시스템 영역을 기준으로 필터링하고 분석해 문제가 집중되는 기술 영역을 찾을 수 있습니다.
확보 방법
Jira 이슈의 표준 'Components' 필드입니다.
예시
인증 서비스보고 대시보드모바일 앱
|
|||
|
근본 원인 범주
RootCauseCategory
|
인시던트의 근본 원인을 분류한 값입니다. | ||
|
설명
이 속성에는 인시던트가 발생한 근본 원인이 기록됩니다. 예를 들면 '소프트웨어 결함', '하드웨어 장애', '사용자 오류' 등이 있습니다. 일반적으로 조사를 마친 뒤 입력하며, 효과적인 문제 관리와 재발 방지에 필요합니다. 근본 원인 범주를 분석하면 시스템의 취약점을 찾고 개선 과제의 우선순위를 정할 수 있습니다. 근본 원인이 '알 수 없음'인 비율이 높다면 조사 프로세스를 개선해야 할 수 있습니다.
중요한 이유
근본 원인을 분석해 인시던트 발생 원인을 찾아 해결함으로써 사후 대응에서 사전 예방으로 전환할 수 있습니다.
확보 방법
거의 항상 Jira의 사용자 지정 필드입니다. 필드 이름과 선택 항목은 조직별 설정에 따라 크게 달라집니다.
예시
구성 오류네트워크 장애소프트웨어 버그
|
|||
|
신고자
Reporter
|
인시던트를 처음 생성하거나 신고한 사용자입니다. | ||
|
설명
신고자는 인시던트를 처음 등록한 사용자이며, 최종 사용자나 다른 시스템일 수 있습니다. 신고자별로 인시던트를 분석하면 문제를 자주 겪는 사용자나 부서를 찾을 수 있습니다. '고객 응답 대기', '고객 회신'과 같은 활동을 분석하면 특히 커뮤니케이션 양상을 파악하는 데 도움이 됩니다.
중요한 이유
인시던트 발생 출처와 특정 사용자 또는 부서와 관련된 양상을 분석하고 고객 응답 지연을 파악하는 데 도움이 됩니다.
확보 방법
Jira 이슈의 표준 'Reporter' 필드입니다.
예시
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
심각도
Severity
|
인시던트가 비즈니스에 미치는 영향의 정도입니다. | ||
|
설명
심각도는 인시던트가 비즈니스에 미치는 영향을 나타냅니다. 한 명의 사용자에게만 영향을 주는 경우부터 중요 시스템 전체가 중단되는 경우까지 포함합니다. 우선순위가 처리 순서를 정한다면 심각도는 전반적인 비즈니스 영향을 보여 줍니다. 심각도별 분석을 통해 비즈니스에 큰 영향을 주는 인시던트의 처리 성과를 파악할 수 있으며, 더 세밀한 분석을 위해 우선순위와 함께 사용하는 경우가 많습니다.
중요한 이유
비즈니스 영향을 기준으로 분석해 운영에 가장 큰 피해를 주는 인시던트에 집중할 수 있습니다.
확보 방법
일반적으로 Jira의 사용자 지정 필드이며, 표준 시스템 필드에는 포함되지 않습니다. Jira Service Management 프로젝트 설정을 확인하세요.
예시
치명적심각경미미미
|
|||
|
업무 인계 횟수
HandoffCount
|
인시던트가 다른 그룹이나 사용자에게 재할당된 횟수입니다. | ||
|
설명
이 계산 지표는 인시던트 생애주기 동안 'Assignee' 또는 'AssignmentGroup' 필드가 변경된 횟수를 셉니다. 인계가 잦으면 프로세스 비효율, 최초 문의 해결 실패, 지식 부족을 나타낼 수 있으며 해결 시간이 길어질 수 있습니다. 이 KPI를 분석하면 할당 절차를 간소화하고 팀 협업을 개선할 수 있습니다.
중요한 이유
재할당으로 발생하는 프로세스의 마찰과 비효율을 수치화해 개선 기회를 찾을 수 있습니다.
확보 방법
이슈 변경 내역에서 'Assignee' 또는 'AssignmentGroup' 필드의 변경 횟수를 세어 계산합니다.
예시
015
|
|||
|
연결된 문제 ID
LinkedProblemId
|
이 인시던트와 연결된 문제 티켓의 식별자입니다. | ||
|
설명
더 큰 근본 문제의 징후로 발생한 인시던트는 문제 티켓과 연결하는 경우가 많습니다. 이 필드에는 연결된 문제의 ID가 저장됩니다. 연결 관계를 분석하면 인시던트와 문제의 연관성을 파악하고 문제 관리 프로세스의 효과를 측정하며 영구적인 수정이 필요한 반복 인시던트를 찾을 수 있습니다.
중요한 이유
인시던트와 근본 문제를 연결해 조직이 원인을 얼마나 효과적으로 해결하고 재발을 방지하는지 분석할 수 있습니다.
확보 방법
이 정보는 Jira 이슈의 'Issue Links' 섹션에 저장됩니다.
예시
PROB-123PROB-456없음
|
|||
|
이슈 유형
IssueType
|
인시던트, 서비스 요청, 문제 등 이슈의 유형입니다. | ||
|
설명
Jira는 이슈 유형을 사용해 작업을 구분합니다. 인시던트 관리에서는 주로 '인시던트' 유형을 사용하지만 '하위 작업'과 같은 유형도 관련될 수 있습니다. 이 속성으로 데이터셋을 필터링해 인시던트만 포함하면 올바른 프로세스를 대상으로 분석할 수 있습니다.
중요한 이유
서비스 요청이나 변경과 같은 다른 작업 유형과 구분해 인시던트만 분석하도록 범위를 설정합니다.
확보 방법
Jira 이슈의 표준 'Issue Type' 필드입니다.
예시
인시던트IT 지원버그
|
|||
|
재작업 여부
IsRework
|
인시던트가 재개되는 등 재작업을 거쳤는지 나타내는 표시입니다. | ||
|
설명
이 계산된 불리언 속성은 프로세스의 이전 단계로 되돌아간 인시던트를 식별합니다. 해결된 뒤 다시 열린 경우가 대표적입니다. 재작업 반복은 비효율과 고객 불만의 주요 원인입니다. 이 표시를 사용하면 재작업 비율을 쉽게 계산하고 인시던트가 처음부터 제대로 해결되지 않는 이유를 분석할 수 있습니다.
중요한 이유
반복 작업이 필요한 인시던트를 표시해 프로세스 품질 문제와 비효율을 드러내고 재작업 분석을 지원합니다.
확보 방법
이벤트 로그에서 '해결됨' -> '재개됨'과 같은 특정 상태 전환 순서를 찾아 계산합니다.
예시
truefalse
|
|||
|
해결 목표 시간
TimeToResolutionTarget
|
인시던트 해결에 적용되는 SLA 목표 시간입니다. | ||
|
설명
이 속성은 특정 우선순위나 유형의 인시던트를 해결해야 하는 최대 시간을 정의합니다. 실제 해결 시간을 이 기준과 비교해 SLA 준수 여부를 판단합니다. 일반적으로 우선순위, 심각도, 이슈 유형 등을 고려한 규칙에 따라 값이 설정됩니다. SLA 성과 모니터링 대시보드에 필요한 기준입니다.
중요한 이유
SLA 준수 여부를 측정하는 기준이며, 인시던트 SLA 위반율 KPI를 계산하는 바탕이 됩니다.
확보 방법
Jira Service Management의 SLA 설정에서 가져옵니다. '해결까지 걸리는 시간'과 같은 구체적인 목표를 확인해야 합니다.
예시
4시간8시간3일
|
|||
|
해결 유형
Resolution
|
인시던트를 해결한 최종 결과 또는 사유입니다. | ||
|
설명
해결 유형 필드는 인시던트가 해결 상태로 변경된 이유를 설명합니다. 일반적인 유형으로는 '수정 완료', '중복', '조치하지 않음', '재현 불가' 등이 있습니다. 해결 유형의 분포를 분석하면 접수된 보고의 품질과 해결 프로세스의 효과를 파악할 수 있습니다. 예를 들어 '중복'으로 처리된 건이 많다면 인시던트 생성이나 분류 단계에 문제가 있을 수 있습니다.
중요한 이유
인시던트 처리 결과의 맥락을 제공해 해결 유형을 분류하고 인시던트 종료 방식의 추세를 파악할 수 있습니다.
확보 방법
Jira 이슈의 표준 'Resolution' 필드입니다. 일반적으로 이슈가 'Done' 상태 범주로 전환될 때 설정됩니다.
예시
완료수정 완료중복수정하지 않음
|
|||
인시던트 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
고객 응답 대기
|
지원팀이 고객의 정보 제공이나 조치를 기다리는 시점을 나타냅니다. 일반적으로 '고객 응답 대기'와 같은 전용 대기 상태로 전환될 때를 기준으로 추정합니다. | ||
|
중요한 이유
이 대기 시간을 별도로 구분하는 것은 정확한 SLA 측정에 중요합니다. 대기 시간은 해결 시간 계산에서 제외되는 경우가 많습니다. 또한 고객 응답 지연을 분석하는 데 도움이 됩니다.
확보 방법
이슈의 상태 변경 이력에서 추정합니다. 상태가 '고객 응답 대기' 또는 이와 유사한 상태로 변경된 시점에 해당하는 이벤트입니다.
기록
'고객 응답 대기' 상태로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
인시던트 담당자 재지정
|
최초 담당자 지정 후 인시던트가 다른 담당자나 그룹으로 이관될 때 발생합니다. '담당자' 또는 '담당 그룹' 필드의 변경을 기준으로 추정합니다. | ||
|
중요한 이유
재지정 추적은 인계 과정을 분석하는 데 중요합니다. 재지정이 잦으면 프로세스 비효율, 지식 격차 또는 부정확한 초기 배정을 나타내며, 해결이 지연될 수 있습니다.
확보 방법
'담당자' 필드에 처음 값이 입력된 후 발생한 업데이트를 이슈 이력에서 찾아 추정합니다. 변경이 발생할 때마다 담당자 재지정 이벤트로 기록합니다.
기록
최초 담당자 지정 후 '담당자' 필드가 변경된 기록을 확인합니다.
이벤트 유형
inferred
|
|||
|
인시던트 생성
|
인시던트 보고가 접수되고 Jira에 새 이슈가 생성되면 인시던트 생명주기가 공식적으로 시작됩니다. 시스템에 '인시던트' 유형의 새 이슈가 등록될 때 이 이벤트를 명시적으로 기록합니다. | ||
|
중요한 이유
이 이벤트는 프로세스의 주요 시작점입니다. 이 활동부터 해결까지 걸리는 시간을 분석하면 전체 처리 주기와 SLA 준수율을 측정할 수 있습니다.
확보 방법
Jira의 인시던트 이슈에 기록된 '생성' 타임스탬프에서 명시적으로 가져오는 이벤트입니다. 이슈 생성 이벤트는 해당 이슈의 이력에 기록됩니다.
기록
이슈 생성 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
인시던트 종료
|
인시던트가 해결되고 검증된 후 티켓을 최종적으로 행정 종료하는 활동입니다. '종료됨' 상태로 전환된 시점을 기준으로 추정합니다. | ||
|
중요한 이유
프로세스의 최종 이벤트입니다. '해결됨'에서 '종료됨'까지 걸리는 시간을 분석하면 행정 처리나 사용자 확인 과정의 지연을 파악할 수 있습니다.
확보 방법
이슈의 상태 변경 이력에서 추정합니다. 상태가 최종 상태인 '종료됨'으로 전환된 시점에 해당합니다.
기록
'종료됨' 상태로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
인시던트 해결
|
인시던트가 성공적으로 해결되고 서비스가 복구되었음을 확인하는 활동입니다. 대개 '해결됨' 상태로 전환되는 시점과 일치합니다. | ||
|
중요한 이유
이 시점은 프로세스의 주요 성공 기준입니다. 여기까지 걸리는 시간은 가장 일반적으로 사용하는 KPI인 해결 시간(TTR)을 나타냅니다.
확보 방법
'해결됨' 상태로 변경된 기록에서 추정합니다. 많은 워크플로에서 '해결안 제시'와 같은 이벤트이며, 주요 해결 시점을 나타냅니다.
기록
'해결됨' 상태로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
조사 시작
|
지정된 담당자가 인시던트 진단을 위해 실제 작업을 시작했음을 나타냅니다. 일반적으로 인시던트 이슈의 상태가 '열림' 또는 '신규'에서 '진행 중'으로 변경될 때를 기준으로 추정합니다. | ||
|
중요한 이유
이 주요 시점은 해결을 위한 실제 작업이 시작되는 때를 나타냅니다. 이 활동까지 걸리는 시간을 측정하면 초기 대기열 지연과 리소스 가용성 문제를 파악할 수 있습니다.
확보 방법
이슈의 상태 변경 이력에서 추정합니다. '진행 중'과 같이 실제 작업이 시작된 상태로 전환된 시각을 이벤트 타임스탬프로 사용합니다.
기록
'진행 중' 상태로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
해결안 제시
|
해결책을 찾아 적용했으며 인시던트가 확인 또는 최종 검증을 기다리는 상태를 나타냅니다. '해결됨' 상태로 전환된 시점을 기준으로 추정합니다. | ||
|
중요한 이유
지원팀의 실제 작업이 끝났음을 나타내는 주요 시점입니다. 이때 SLA 측정이 중단되는 경우가 많습니다.
확보 방법
이슈의 상태 변경 이력에서 추정합니다. 상태가 '해결됨' 또는 이에 해당하는 상태로 전환된 시각을 이벤트 타임스탬프로 사용합니다.
기록
'해결됨' 상태로 전환된 타임스탬프를 확인합니다.
이벤트 유형
inferred
|
|||
|
고객 응답
|
고객이 요청된 정보를 제공해 인시던트 처리를 재개할 수 있음을 나타냅니다. 상태가 '고객 응답 대기'에서 진행 중 상태로 바뀔 때를 기준으로 추정합니다. | ||
|
중요한 이유
이 활동은 고객으로 인해 발생한 지연이 끝나는 시점을 나타냅니다. '고객 응답 대기'부터 이 이벤트까지 걸린 시간을 분석하면 평균 고객 응답 시간을 확인할 수 있습니다.
확보 방법
이슈의 상태 변경 이력에서 추정합니다. 고객이 댓글을 추가하는 등의 이유로 상태가 '고객 응답 대기'에서 '진행 중'과 같은 상태로 바뀔 때 발생합니다.
기록
'고객 응답 대기'에서 '진행 중'으로 상태가 변경된 기록을 감지합니다.
이벤트 유형
inferred
|
|||
|
댓글 추가
|
사용자가 인시던트 티켓에 댓글을 추가하는 소통 또는 메모 활동을 나타냅니다. 댓글이 게시될 때마다 명시적으로 기록합니다. | ||
|
중요한 이유
댓글 빈도를 분석하면 소통 방식, 협업 효율성, 인시던트의 복잡성을 파악할 수 있습니다. 소통이 지나치게 많이 필요한 인시던트도 확인할 수 있습니다.
확보 방법
명시적으로 기록되는 이벤트입니다. Jira는 모든 댓글의 작성자와 타임스탬프를 저장하며, 이슈의 댓글 이력이나 API에서 확인할 수 있습니다.
기록
이슈에 추가된 각 댓글의 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
문제 티켓에 연결
|
근본 원인 분석을 위해 인시던트를 '문제' 이슈에 연결할 때 발생합니다. '문제' 유형의 이슈에 '관련 있음' 또는 '원인 제공' 링크가 생성되면 명시적으로 기록합니다. | ||
|
중요한 이유
이 연결을 추적하면 조직이 인시던트 완화에서 근본 원인 분석과 예방으로 얼마나 효과적으로 전환하는지 파악할 수 있습니다.
확보 방법
이슈의 링크 이력에 명시적으로 기록되는 이벤트입니다. 링크가 생성될 때마다 타임스탬프가 기록되며, '문제' 유형의 이슈에 연결된 링크만 필터링할 수 있습니다.
기록
'문제' 유형의 이슈에 링크가 생성된 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
인시던트 담당자 지정
|
인시던트를 처리할 지원 담당자 또는 그룹을 처음 지정하는 활동입니다. '담당자' 또는 '담당 그룹' 필드에 처음으로 값이 입력된 시점을 추적해 기록합니다. | ||
|
중요한 이유
최초 응답 및 담당자 지정까지 걸리는 시간을 측정합니다. 이는 SLA 지표의 주요 구성 요소이며, 조사가 시작되기 전의 지연을 파악하는 데 도움이 됩니다.
확보 방법
이슈 이력에서 이전 값이 '미지정'인 '담당자' 필드의 첫 변경을 찾아 추정합니다.
기록
이슈 이력에서 '담당자' 필드의 첫 업데이트를 감지합니다.
이벤트 유형
inferred
|
|||
|
인시던트 우선순위 지정
|
인시던트의 우선순위 및/또는 심각도를 설정하는 활동으로, 긴급도와 비즈니스 영향을 결정합니다. 일반적으로 이슈 생성 후 '우선순위' 또는 '심각도' 필드에 처음으로 값이 입력되거나 값이 변경된 시점을 기준으로 추정합니다. | ||
|
중요한 이유
우선순위 지정 과정을 추적하면 인시던트를 신속하고 일관되게 평가하는지 분석할 수 있습니다. 이 단계가 지연되면 SLA 산정과 리소스 배분에 직접 영향을 줄 수 있습니다.
확보 방법
모든 필드의 변경 사항을 추적하는 이슈 이력 로그에서 추정합니다. 이슈 생성 후 '우선순위' 또는 사용자 지정 '심각도' 필드가 처음으로 변경된 기록을 확인합니다.
기록
이슈 이력에서 '우선순위' 필드의 첫 변경을 감지합니다.
이벤트 유형
inferred
|
|||
|
인시던트 재개
|
문제가 재발하거나 해결책이 효과가 없어 이전에 해결된 인시던트가 다시 활성화된 상황을 나타냅니다. 상태가 '해결됨' 또는 '종료됨'에서 열린 상태로 변경될 때를 기준으로 추정합니다. | ||
|
중요한 이유
재개된 인시던트는 해결 품질을 직접 보여주며 재작업을 나타내는 주요 지표입니다. 이 이벤트를 분석하면 성급한 종료와 효과가 없는 해결책을 찾을 수 있습니다.
확보 방법
이슈의 상태 변경 이력에서 추정합니다. 상태가 '해결됨' 또는 '종료됨'과 같은 최종 상태에서 '열림' 또는 '진행 중'으로 돌아갈 때 기록합니다.
기록
'해결됨' 또는 '종료됨'에서 열린 상태로 상태가 변경된 기록을 감지합니다.
이벤트 유형
inferred
|
|||
|
임시 해결책 제공
|
영구적인 해결책을 마련하는 동안 서비스를 복구하기 위해 임시 조치를 적용하는 활동입니다. 상태 변경이나 특정 댓글을 기준으로 추정할 수 있습니다. | ||
|
중요한 이유
임시 해결책을 제공하기까지 걸리는 시간은 서비스 복구 속도를 보여주는 주요 지표입니다. 임시 완화 조치와 영구적인 해결을 구분하는 데 도움이 됩니다.
확보 방법
대개 추정으로 확인합니다. '임시 해결책 제공' 상태로 전환되거나 '임시 해결책'과 같은 특정 키워드가 포함된 공개 댓글이 추가된 기록을 활용할 수 있습니다.
기록
특정 상태 전환이나 댓글의 키워드를 확인합니다.
이벤트 유형
inferred
|
|||
|
전문 팀으로 에스컬레이션
|
고급 지원을 위해 인시던트를 전문 팀(예: 2차 지원팀, 개발팀)으로 에스컬레이션했음을 나타냅니다. 사용자 지정 '지원 팀' 필드의 변경이나 특정 담당자 재지정을 기준으로 추정합니다. | ||
|
중요한 이유
전문 지식이 필요한 인시던트를 확인하고 지원 단계 간 이동을 추적합니다. 이를 통해 전문 팀 내 병목을 찾고 에스컬레이션 패턴을 분석할 수 있습니다.
확보 방법
담당 팀을 나타내는 사용자 지정 필드의 변경을 추적하거나, '담당자'가 알려진 전문 그룹의 구성원으로 변경된 기록을 찾아 이슈 이력에서 추정합니다.
기록
'담당 팀' 사용자 지정 필드의 변경 또는 특정 담당자 변경을 감지합니다.
이벤트 유형
inferred
|
|||
데이터 추출 안내
시작할 준비가 되셨나요?
이 데이터 템플릿으로 인시던트 관리 현황을 파악하고 비효율을 찾아 해결 시간을 단축하세요. 지금 프로세스 최적화를 시작해 보세요.
인시던트 관리를 최적화하고 더 빠르게 해결하세요
프로세스를 간소화해 MTTR을 35% 줄이고 사용자 만족도를 높이세요.
신용카드 불필요 • 5분 만에 설정