인시던트 관리에 사용되는 표현

인시던트 확인(ack)

인시던트 알림이 생성된 후 사용자는 대부분의 대기 중 알림 도구에서 알림을 확인(또는 “ack”)할 수 있습니다. 사용자가 이슈에 대한 책임을 맡고 해결을 위해 노력하고 있다는 의미입니다.

조치 가능한 알림

조치 가능한 알림은 이슈와 그로 인한 영향을 명확하게 설명하고, 팀이 즉시 조치를 취할 수 있도록 적시에 적절한 담당자에게 전달되는 알림입니다.

능동적 모니터링

능동적 모니터링 기능이 있는 시스템은 인시던트로 이어질 수 있는 성능 변화가 있는지 정기적으로 점검되거나 소프트웨어를 통해 자동으로 모니터링됩니다.

조치 후 검토(AAR)

조치 후 검토는 이벤트 이후에 이루어지는 구조화된 검토 프로세스입니다. 이 프로세스는 일반적으로 발생한 상황을 자세히 설명하고, 발생한 이유를 파악하며, 향후 동일하거나 비슷한 이벤트를 방지하기 위해 개선해야 할 영역을 정확히 찾아냅니다. 조치 후 검토는 일반적으로 사후 검토나 인시던트 발생 후 검토라고도 합니다.

합의된 서비스 시간(AST)

합의된 서비스 시간은 서비스를 사용할 수 있을 것으로 예상되는 시간으로, 일반적으로 연간 시간으로 측정됩니다. 이러한 합의는 일반적으로 공급업체와 고객 간의 SLA(서비스 수준 계약)에 요약되어 있습니다. 고가용성 서비스는 일반적으로 99.99%의 가동 시간을 보장하므로 연간 1시간 미만의 가동 중지 시간이 허용됩니다.

알림

모니터링 도구가 IT 환경의 변화, 위험이 높은 조치 또는 장애를 식별할 때 생성되는 알림이나 경고입니다.

알림 소음

알림 소음은 짧은 시간 안에 알림이 너무 많이 올 때 발생하는 것으로, 대응자가 영향을 받는 서비스와 작업의 우선 순위를 지정하는 방법을 정확하게 파악하기 어렵게 만듭니다. 알림 소음은 알림 피로를 유발하는 요인이 될 수 있습니다.

알림 피로

알림 피로는 인시던트 대응자가 알림의 양 또는 빈도에 부담을 느낄 때 발생합니다. 대응자는 지속적인 알림을 일반화하는 경향이 있으므로 알림 피로는 대응 속도를 늦추거나 아예 대응하지 않도록 만드는 경우가 많습니다.

상시 서비스

지속적으로 가동될 것으로 예상되는 서비스입니다.

자산/자산 관리

비즈니스 가치가 있는 모든 시스템이나 네트워크의 구성 요소입니다. 자산 관리는 작업자나 팀이 업데이트 또는 시스템 제거의 영향을 파악하기 위해 그러한 구성 요소를 조사하는 것입니다.

감사

시스템 또는 프로세스의 가용성 및 사용뿐만 아니라 정책, 가이드라인 및 모범 사례를 준수하고 있는지에 대해 공식적으로 이루어지는 검사입니다.

가용성

제품 또는 시스템을 사용할 수 있으며 예상대로 작동하는 경우입니다. 시스템 가동 시간이라고도 합니다.

백아웃

서비스를 신뢰할 수 있는 이전의 상태나 기준선으로 복원하는 방법입니다. 일반적으로 업데이트 또는 릴리스로 인해 시스템에서 필수적인 부분이 중단될 때 적용되는 빠른 해결입니다.

백업

원본이 손상되거나 분실된 경우 사용할 수 있는 저장된 데이터 복사본 또는 중복 시스템입니다.

기준선

예상되는 동작에 대한 참조점입니다. 기준선은 팀이 변경 및 개선 사항을 측정하는 데 도움이 됩니다.

벤치마크

진행률을 측정하거나 결과를 비교하기 위해 기준선과 같은 역할을 하는 참조점입니다. 예를 들어, 업계의 표준이 99.99%의 가동 시간이라면 이는 경쟁업체 및 고객 기대치와 비교하여 스스로를 측정하는 데 사용하는 벤치마크가 될 수 있습니다.

버그

비정상적인 동작이나 장애를 일으킬 수 있는 소프트웨어, 코드, 프로그램 등의 예기치 않은 문제입니다.

비즈니스 영향 분석(BIA)

비즈니스 영향 분석은 주요 인시던트로 인한 서비스 중단 및 가동 중지 시간의 잠재적인 영향을 체계적으로 평가하는 것입니다. BIA의 목표는 각 서비스가 비즈니스에 미치는 영향을 파악하고 인시던트 발생 시 복구를 위한 요구 사항을 정의하는 것입니다.

용량

네트워크 간에 전송되거나 서비스를 통해 전달될 수 있는 정보의 최대량입니다. 용량 초과는 인시던트의 일반적인 전조 증상입니다.

변경

IT 서비스, 구성, 네트워크 또는 프로세스에 대한 모든 변경 사항입니다. 변경 관리라고 알려진 관행에서 추적되는 경우가 많습니다.

변경 기록

수명 주기의 시작부터 현재 상태에 이르기까지 IT 서비스, 구성, 네트워크 또는 프로세스의 변경 사항에 대한 포괄적인 기록입니다.

변경 관리

중요한 시스템 및 서비스를 변경/업데이트하는 동안 중단을 최소화하는 데 중점을 둔 IT 관행입니다. 일부 팀의 경우 기술적인 측면부터 직원 및 프로세스 측면에 이르기까지 변화의 모든 측면을 포함합니다. ITIL 4 가이드라인을 기반으로 하는 다른 팀의 경우 변경 관리는 변경의 인적 또는 문화적 측면을 관리하는 데 초점을 맞추고, 변경 제어라는 또다른 관행은 위험 평가, 일정 및 변경 권한 부여에 중점을 둡니다.

ChatOps

인시던트 관리에 채팅 및 공동 작업 도구를 사용하는 관행입니다. Atlassian의 Sean Regan은 다음과 같이 설명합니다.

“ChatOps는 사용자, 도구, 프로세스 및 자동화를 투명한 워크플로로 연결해주는 공동 작업 모델입니다. 이 워크플로는 필요한 작업, 진행 중인 작업 및 완료된 작업을 사용자, 봇 및 관련 도구가 갖춰진 영구적인 위치에 연결합니다."

종료된 상태

필요한 조치를 모두 취하고 이슈가 종료되면 인시던트는 종료된 상태가 됩니다.

수동 대기(점진적 복구)

수동 대기는 시스템이 다른 시스템의 백업 역할을 할 때 사용됩니다. 기본 시스템에 장애가 발생하면 시스템에서 문제를 해결하는 동안 수동 대기 시스템이 기본 시스템을 대체합니다. 컴퓨팅 하드웨어를 교체하고 설정해야 하는 경우 기본 시스템의 장애로 인해 점진적 복구(몇 주씩 걸릴 수 있는 복구)가 필요할 때 특히 유용한 전략입니다.

수동 시작

수동 시작은 실행하고 있지 않은 애플리케이션을 시작하는 데 “웜” 상태 또는 이미 실행 중인 애플리케이션보다 시간이 더 오래 걸리는 경우에 발생합니다.

커뮤니케이션 리더

인시던트 발생 시 커뮤니케이션을 담당하는 팀원입니다.

규정 준수

규정과의 정렬입니다. 모니터링 시스템은 컴플라이언스 이슈를 모니터링하고 시스템이 컴플라이언스를 준수하지 않을 경우 알림을 트리거하도록 프로그래밍되는 경우가 많습니다.

구성 요소 장애 영향 분석(CFIA)

한 구성 요소 또는 구성이 예상대로 작동하지 않는 경우 서비스에 미치는 영향을 확인하는 프로세스입니다.

동시성

시스템 내에서 동일한 작업이 동시에 얼마나 많이 이루어지는지 측정합니다. 예: 동일한 작업에 액세스하거나 동일한 트랜잭션을 수행하는 사용자는 몇 명입니까?

컨트롤

위험을 관리하고 제품 또는 서비스가 예상대로 작동하도록 보장하며 컴플라이언스를 보호하는 절차 및 정책입니다.

핵심 서비스

사용자/고객을 위한 핵심 기능을 제공하는 서비스입니다.

대책

시스템을 보호하거나 작업을 복원하기 위해 취하는 특정 대응 조치입니다.

고객 대상 서비스

고객이 사용하고 상호 작용하는 서비스입니다.

Cynefin 프레임워크

관리자가 가장 효과적인 대응을 구성할 수 있도록 인시던트 관리 프로세스에 맞게 조정된 의사 결정 구조입니다. 프레임워크는 인시던트의 복잡성에 따라 상황을 다섯 가지 범주로 나누고, 각 범주에는 고유한(서로 다른) 일련의 다음 단계가 있습니다.

대시보드

깔끔하고 정확한 형식으로 제공되는 컨텍스트 정보와 함께 다양한 도구의 정보를 어떻게 표시할지 구성하도록 시스템, 알림 및 인시던트를 하나의 화면으로 시각화한 것입니다.

종속성

작동하기 위해 서로 의존하는 두 서비스, 프로세스 또는 구성 간의 관계입니다.

사용 중단

기능 또는 도구의 서비스가 중단되거나, 더 이상 사용되지 않거나, 더 이상 업데이트되지 않는 경우입니다.

진단

인시던트와 그 근본 원인을 파악하는 프로세스와 결과입니다.

진단 증상

인시던트의 진단으로 이어지는 증상이나 징후입니다.

가동 중지 시간/서비스 중단

서비스가 예상대로 작동하지 않거나 사용할 수 없는 시간입니다.

긴급 변경

일반적으로 인시던트 해결의 일부로 신속하게 배포되는 업데이트나 패치입니다. 긴급 변경은 승인을 기다리는 데 따른 위험이 변경을 배포하는 데 따른 위험보다 크기 때문에 변경 승인 프로세스를 건너뛰는 경우가 많습니다.

인에이블링 서비스

핵심 서비스가 작동하는 데 필요하지만 그 자체로 고객에게 직접 제공되지는 않는 서비스입니다.

테스트 환경*

서비스, 기능, 프로세스, 구성 항목 등이 예상되는 기능에 대해 테스트되는 인프라입니다. 테스트 환경은 프로덕션에 맞춰 세밀하게 제어됩니다.

프로덕션 환경

서비스를 고객에게 제공하는 인프라입니다. 이 환경의 산출물은 제공되며 라이브 환경이라고도 합니다.

오류

구성 항목 또는 서비스의 장애를 유발하는 실수입니다. 설계, 처리 과정의 실수거나 사람의 실수일 수 있습니다.

에스컬레이션

인시던트 관리를 관련된 기술이나 경험을 갖춘 팀 또는 개인에게 할당하는 프로세스입니다. 기능적 에스컬레이션은 알림 또는 인시던트를 더 많은 전문 지식을 갖춘 개인이나 팀에게 전달하는 경우입니다. 계층적 에스컬레이션은 그러한 알림이나 인시던트를 신입 직원에서 선임 직원에게 전달하는 경우입니다.

이벤트

주목할 만한 시스템 또는 서비스 상황입니다. 이벤트는 일반적으로 사용자의 작업이나 인시던트로 인해 발생합니다.

예외 보고서

핵심 성과 지표(KPI)가 임계값을 초과하거나 기대치를 충족하지 못할 때 생성되는 보고서입니다.

내결함성

내결함성은 구성 항목이나 개별 부분에 문제가 생기더라도 서비스가 계속 작동할 수 있는 능력을 나타냅니다.

결함 트리 분석

인시던트를 발생시킨 이벤트를 파악하고 향후 인시던트로 이어질 수 있는 이벤트를 예측하는 데 사용되는 기술입니다. 주요 인시던트의 근본 원인을 찾는 데 자주 사용됩니다.

1차적 지원

인시던트에 가장 먼저 대응할 것으로 예상되는 대응자입니다. 일반적으로 대기 중 담당자입니다.

고침

수리를 위한 작업 또는 방법입니다.

고정 자산

고정 자산은 사무실, 컴퓨터 또는 라이선스와 같이 비즈니스의 물리적이고 가치가 있는 장기적인 부분입니다.

해가 지지 않는 일정

팀이 한밤중에 대기 근무를 할 필요 없이 연중무휴 24시간 서비스를 제공하기 위해 시간대에 따라 대기 근무 책임을 돌아가면서 맡는 고객 지원 또는 인시던트 관리 방법입니다.

포렌식 조사

인시던트의 원인을 파악하기 위한 목적으로 컴퓨터 시스템에 대해 수행하는 증거 기반의 과학적인 조사입니다.

기능적

서비스가 예상대로 작동할 수 있을 때 기능적인 것이라고 표현합니다.

점진적 복구

점진적 복구는 평소보다 오래 걸리는 복구 프로세스입니다(몇 시간이 아니라 몇 주). 이 경우에는 일반적으로 수동 대기(백업 시스템)가 온라인 상태로 전환되어 영향을 받는 시스템을 대신합니다.

상시 대기

상시 대기는 장애 발생 시 IT 서비스를 지원하기 위해 중복 자산을 동시에 실행하는 복구 옵션입니다. 활성 시스템에 장애가 발생하면 상시 대기 시스템이 이미 실행 중이며 팀에서 조치를 취하거나 가동 중지 시간 없이도 그 자리를 대신할 수 있습니다. 즉시 복구라고도 합니다.

핫픽스

문제를 해결하거나 버그를 수정하기 위해 소프트웨어에 적용되는 업데이트입니다. 고객이 보고한 이슈를 해결하는 데 자주 사용됩니다.

영향

서비스 중단, 인시던트 또는 변경으로 인한 비용(돈, 시간, 평판)을 측정한 것입니다. 가동 중지 시간 비용이라고도 합니다.

조치 불가능한 알림

대응자가 조치를 취하도록 권한을 부여하지 않는 알림입니다. 알림에 컨텍스트 정보가 없거나, 잘못된 담당자에게 라우팅되었거나, 범위가 명확하지 않다는 의미인 경우가 많습니다. 조치 불가능한 알림은 알림 피로를 유발할 수 있습니다.

인시던트

서비스 중단 또는 서비스 품질을 저하를 야기하기 때문에 긴급한 대응이 필요한 이벤트입니다. ITIL 또는 ITSM 관행을 따르는 팀에서는 이 대신 주요 인시던트라는 용어를 사용하기도 합니다.

인시던트 대응

팀이 인시던트에 대응하는 방식입니다. 일반적으로 인시던트 대응은 인시던트가 발생하기 전에 규칙, 역할 및 모범 사례를 정의해 놓은 사전 설정된 프로세스입니다.

인시던트 관리

DevOps 및 IT 운영 팀이 예기치 않은 이벤트 또는 서비스 중단에 대응하고 서비스를 운영 상태로 복원하는 프로세스입니다.

인시던트 관제자

인시던트 관제자는 인시던트 대응 관리를 담당하는 IT 또는 DevOps 팀원입니다. 관제자는 인시던트 관리 팀의 책임자로, 모든 인시던트 결정에 대한 최고 수준의 통제권과 최종 결정권을 가지고 있습니다. 인시던트 관리자라고도 합니다.

인시던트 수명 주기

인시던트가 만들어지고 감지되며 해결되기까지의 수명입니다.

I/O 메트릭

입력 및 출력을 측정하는 메트릭의 모음입니다. 범주의 일반적인 메트릭으로는 IO 대기(CPU가 IO 요청을 기다리는 시간)와 IOPS(초당 IO 요청 수)가 있습니다.

인시던트 대응 오케스트레이션

팀이 빠르고 효과적으로 문제를 파악하고, 적합한 담당자에게 알리고, 사업부 간 커뮤니케이션을 지원하고, 여러 팀 간에 공동 작업하여 인시던트를 관리할 수 있는 Opsgenie 기능입니다.

인시던트 기록

특정 인시던트 동안 사용된 프로세스와 세부 정보를 기록한 것입니다.

인시던트 대응자

인시던트의 조사와 해결을 담당하는 개인 및/또는 팀입니다.

인시던트 이해 관계자/관찰자

인시던트가 직무/업무 수행 능력에 영향을 미치기 때문에 인시던트에 대해 계속 정보를 제공받아야 하는 개인입니다. 인시던트 해결에 영향을 줄 수도, 주지 않을 수도 있지만 적극적인 대응자는 아닙니다.

중간 복구

웜 대기라고도 하는 이 유형의 복구는 일반적으로 24~72시간이 걸립니다. 복구 시간이 비교적 긴 이유는 일반적으로 데이터 복원 및/또는 하드웨어 및 소프트웨어 구성에 있습니다.

정보 기술 인프라 라이브러리(ITIL)

IT 서비스에 대해 널리 인정되는 모범 사례를 문서화한 집합입니다.

정보 기술 서비스 관리(ITSM)

고객에게 IT 서비스를 제공하는 데 필요한 프로세스 및 절차의 모든 측면입니다. 설계부터 제공, 인시던트 관리에 이르기까지 서비스 수명 주기의 모든 측면이 포함됩니다.

Kepner Tregoe 방법(KT 방법)

이슈에 대한 최종 결정과 별도로 문제를 평가하는, 근본 원인 분석 및 의사 결정 방법입니다.

핵심 성과 지표(KPI)

시스템 또는 제품의 성공을 측정한 것입니다. KPI는 사전에 결정되고 정기적으로 추적되며 예상되는 임계값에서 벗어날 경우 알림을 생성하는 경우가 많습니다. 예를 들어, MTBF(평균 장애 간격)가 점점 짧아지기 시작하면 팀이 문제를 파악하고 살펴볼 수 있도록 알림이 생성될 수 있습니다.

알려진 오류

해결 방법이 이미 있는 기존 이슈입니다.

지연

데이터 전송 중에 발생한 지연입니다.

logs

서비스 또는 애플리케이션과 관련된 모든 이벤트의 기록입니다. 전송된 데이터, 시간 및 날짜, 인시던트, 변경 사항, 오류 등이 포함됩니다.

유지 관리 용이성

변경 사항이 서비스 또는 기능에 얼마나 쉽게 성공적으로 적용될 수 있는지를 나타내는 척도입니다.

수동 해결 방법

자동이 아닌 수동으로 구현되는 해결 방법입니다.

평균 장애 간격(MTBF)

기술 제품에 발생하는 수리 가능한 장애 사이의 평균 시간입니다. 평균 서비스 인시던트 간격(MTBSI)이라고도 합니다.

평균 확인 시간(MTTA)

알림이 트리거된 시점부터 이슈에 대한 작업이 시작될 때까지의 평균 시간입니다.

평균 장애 시간(MTTF)

기술 제품에 발생하는 수리 불가능한 장애 사이의 평균 시간입니다.

평균 수리 시간(MTTR)

시스템(일반적으로 기술 또는 기계)을 수리하는 데 걸리는 평균 시간입니다. 수리 시간과 테스트 시간이 모두 포함됩니다.

평균 복구 시간(MTTR)

제품 또는 시스템 장애에서 복구하는 데 걸리는 평균 시간입니다. 시스템 또는 제품에 장애가 발생한 시점부터 다시 완전히 작동하는 시점까지의 전체 중단 시간이 포함됩니다.

평균 해결 시간(MTTR)

장애가 다시 발생하지 않도록 하는 데 소요되는 시간을 포함하여 장애를 완전히 해결하는 데 걸리는 평균 시간입니다.

평균 대응 시간(MTTR)

해당 오류에 대해 처음 알림을 받은 시점부터 제품 또는 시스템 장애에서 복구하는 데 걸리는 평균 시간입니다. 알림 시스템의 지연 시간은 포함되지 않습니다.

모델/모델링

실제 시스템, 서비스, 애플리케이션 등을 나타낸 것입니다.

모니터링

서비스 또는 프로세스가 예상대로 작동하는지 반복적으로 확인하는 프로세스입니다.

정상적인 변화

정의된 및 사전 승인된 프로세스가 없는 긴급하지 않은 변경입니다.

대기 일정

인시던트 및 서비스 중단에 신속하게 대응할 수 있도록 밤낮으로 항상 대기하는 담당자를 두는 일정입니다. 대기 일정은 의료 및 기술 분야 모두에서 흔하게 사용됩니다.

운영 브리지

IT 서비스 모니터링이 이루어지는 물리적인 위치입니다.

운영 리더

일상적인 운영을 감독하는 책임자입니다. 경우에 따라 인시던트 해결을 주도하는 인시던트 관리자(또는 인시던트 관제자)가 될 수도 있습니다.

결과

IT 관련 이벤트, 프로세스 또는 변경의 결과입니다. 팀은 예상 결과와 실제 결과에 대해 논의하는 경우가 많습니다.

영향 값 분석

인시던트가 비즈니스에 미치는 영향을 파악하는 데 사용되는 분석입니다. 일반적으로 가동 중지 시간 비용, 인시던트 기간, 사용자에게 미치는 영향 및 영향을 받는 사용자 수를 고려합니다.

수동적 모니터링

서비스 기능이 능동적으로 또는 수동으로 모니터링되지 않고 자동으로 모니터링되는 것입니다.

평상시

서비스 및 운영이 중단 없이 예상대로 작동할 때를 말합니다.

성능 저하

이벤트 또는 인시던트로 인해 시스템 성능이 얼마나 저하되었는지 측정합니다.

계획된 가동 중지 시간

유지 관리 또는 업데이트 목적으로 IT 서비스를 의도적으로 사용할 수 없게 만든 기간입니다.

플레이북

팀이 특정 문제, 인시던트 또는 목표를 해결하기 위해 취할 수 있는 “플레이” 또는 특정 조치의 모음입니다.

사후 검토/인시던트 발생 후 분석/인시던트 발생 후 검토

인시던트가 해결된 후 인시던트를 파악하는 프로세스입니다. 사후 검토의 목표는 대응 프로세스를 개선하고 향후 인시던트를 예방하며 가장 최근에 발생한 인시던트의 원인을 파악하는 것입니다.

우선 순위

인시던트를 해결해야 하는 순서입니다. 우선 순위가 높은 항목은 우선 순위가 낮은 항목보다 긴급도가 높아야 합니다. 우선 순위는 긴급도, 심각도 및 비즈니스에 미치는 잠재적인 영향에 따라 결정됩니다.

문제 기록

문제 기록은 감지에서 해결에 이르기까지 이슈의 모든 측면을 다루는 문서입니다.

예상되는 서비스 중단

향후의 유지 관리 또는 테스트가 정상적인 서비스 수준에 미치는 영향을 설명하는 문서입니다.

QA

새로운 기능부터 사용 방법 가이드에 이르기까지 IT와 관련된 모든 항목의 표준을 충족하는지 확인하기 위한 테스트 프로세스입니다.

품질 관리 시스템

품질 보증을 제공하기 위해 마련된 프레임워크 또는 시스템입니다.

대응적 모니터링

이벤트 또는 인시던트에 대응하여 이루어지는 모니터링입니다.

복구

서비스를 기준선의 기능 및 상태로 되돌리는 프로세스입니다.

복구 지점 목표

복구 중에 허용되는 최대 데이터 손실입니다.

복구 시간 목표

서비스 중단에 허용되는 최대 시간입니다.

릴리즈

사용자에게 배포된 변경입니다.

릴리즈 관리

변경의 계획, 설계, 테스트, 일정, 문제 해결 및 배포입니다.

복원력

시스템이 장애를 방지하고 인시던트 발생 시 빠르게 복구할 수 있는 능력입니다.

대응 시간

알림이 생성된 시점부터 팀에서 최초 작업을 수행할 때까지의 시간입니다.

위험 평가

자산의 가치, 잠재적 위협 및 위협의 잠재적 영향을 평가하여 자산의 위험을 파악하는 프로세스입니다.

위험 관리

위협을 파악하고 제어하여 위협을 처리하는 프로세스입니다.

근본 원인

근본 원인은 보통 서비스 또는 애플리케이션 장애를 유발하는 하나의 원인으로 간주됩니다. 하지만 여러 요소가 상호 연결되어 장애에 기여하는 경우가 많기 때문에, 이 용어가 인시던트 관리에 도움이 되는지 여부에 대한 논의가 이루어지기 시작했으며 많은 팀에서는 근본 원인들이라는 복수형 표현으로 바꿨습니다.

런북

런북은 인시던트 관리에 대한 자세한 절차를 제공합니다. 일반적으로 시스템 관리자 또는 네트워크 운영 제어 (NOC) 팀에서 유지 관리합니다. 런북은 디지털 문서거나 인쇄된 문서일 수 있습니다.

범위

문제, 해결 방법, 프로젝트, 기능 등의 범위입니다.

2차적 지원

첫 번째 대응자의 능력을 넘어서는 이슈를 해결할 수 있는 추가적인 역량(시간, 경험, 지식, 리소스)을 갖춘 담당자입니다.

서비스 변경

서비스에 대한 업데이트, 수정, 사용 중단 또는 기타 변경 사항입니다.

Service desk

고객 지원 요청을 받아 고객과 IT 팀 간의 연락 담당자 역할을 하는 팀입니다.

서비스 장애 분석

서비스 장애 분석은 서비스 중단의 원인을 파악하기 위해 조사하는 프로세스입니다.

서비스 수준 계약(SLA)

가동 시간, 대응 및 책임과 같은 측정 가능한 메트릭에 대한 공급자와 고객 간의 계약입니다.

서비스 수준 계약 모니터링(SLAM) 차트

서비스 수준 목표치에 대한 진행률과 데이터가 기록된 문서입니다.

서비스 수준 목표(SLO)

가동 시간과 같은 특정 메트릭에 대한 SLA 내의 계약입니다.

심각도(SEV) 수준

서비스가 인시던트의 영향을 받는 정도입니다. 일반적으로 3~5개 계층으로 이루어진 심각도 수준 구조가 사용됩니다. 1은 심각도가 가장 높은 이슈, 3~5는 긴급도가 그다지 높지 않으며 심각도가 낮은 이슈를 나타냅니다.

단일 장애 지점

시스템 작동을 위해 의존하는 하나의 변수입니다. 예: 필수 구성 항목.

사양

IT 관련 구성의 요구 사항에 대한 공식적인 기록입니다.

사이트 신뢰성 엔지니어(SRE)

운영 업무를 맡는 소프트웨어 엔지니어입니다. SRE는 일반적으로 수동 작업의 자동화, SLO 관리 및 인시던트 관리를 담당합니다.

표준 변경

메모리 또는 스토리지 추가와 같이 위험도가 낮고 흔하게 반복되는 사전 승인된 변경입니다.

대기

인시던트 관리를 지원하는 데 사용할 수 있는 비활성 리소스입니다.

상태

서비스의 현재 상태입니다.

상태 페이지

인시던트에 대한 정기적인 상태 업데이트와 함께 서비스의 현재 상태를 알리기 위한 전용 홈입니다.

실무 전문가(SME)

특정 이슈, 서비스 등에 대한 구체적인 지식을 갖춘 개인입니다.

기술 스택

애플리케이션을 구성하는 프로그래밍 언어, 소프트웨어 및 구성 요소입니다. 기술 스택에는 프런트엔드(고객 대상)와 백엔드(개발자 대상)라는 두 가지 측면이 있습니다.

갈등 메트릭

한 세트 또는 포인트가 변경되면 다른 데이터 포인트에 부정적인 영향을 미치는 데이터입니다.

임계값

사전 정의된 수준이나 수치로, 초과 시 알림을 생성합니다. 예를 들어, 로그인 페이지의 로드 임계값은 3초일 수 있습니다. 페이지를 로드하는 데 시간이 오래 걸리면 알림이 생성됩니다.

일정

이벤트, 변경 사항, 수정 사항, 결과를 비롯해 각 항목이 인시던트 중에 발생한 시점에 대한 포괄적인 목록입니다.

추세 분석

시간과 관련된 패턴에 대한 조사입니다. 추세 분석에서는 과거 패턴을 통해 데이터의 미래 패턴을 예측할 수 있다고 가정합니다. 따라서 인시던트 방지를 위한 중요한 관행입니다.

차선책

기본 인시던트가 아직 해결되지 않았더라도 시스템 기능을 복구하고 실행하는 빠른 해결을 구현하는 성공적인 방법입니다.

작업 로드

IT 서비스를 제공하는 데 필요한 리소스입니다(인력 및 시스템 모두 포함).