Close

더 나은 인시던트 관리를 위한 길은 여기에서 시작됩니다

MTBF, MTTR, MTTA 및 MTTF

가장 일반적인 몇 가지 인시던트 메트릭 파악하기

오늘날과 같이 상시 가동 서비스를 유지하는 환경에서는 서비스 중단과 기술 인시던트가 그 어느 때보다 중요합니다. 장애와 가동 중지 시간은 심각한 결과를 초래합니다. 기한을 맞추지 못하고, 비용 지불이 늦어지고, 프로젝트가 지연됩니다.

그렇기 때문에 회사에서 가동 시간, 가동 중지 시간, 그리고 팀이 얼마나 빠르고 효과적으로 이슈를 해결하고 있는지에 대한 메트릭을 수치화하고 추적하는 것이 중요합니다.

업계에서 가장 많이 추적하는 메트릭으로는 MTBF(장애 전 평균 시간), MTTR(복구, 수리, 대응 또는 해결에 걸리는 평균 시간), MTTF(평균 장애 시간), MTTA(평균 확인 시간) 등이 있으며, 이는 기술 팀이 인시던트 발생의 빈도와 팀이 인시던트로부터 얼마나 빠르게 복구하는지 파악하는 데 도움이 되는 일련의 메트릭입니다.

많은 전문가들은 메트릭이 그 자체로는 그다지 유용하지 않다고 주장합니다. 그 이유는 이러한 메트릭이 인시던트가 어떻게 해결되는지, 무엇이 효과가 있고 그렇지 않은지, 이슈가 어떻게, 언제, 그리고 왜 에스컬레이션 또는 디에스컬레이션되는지와 같은 복잡한 질문에 대해 설명하지 않기 때문입니다.

하지만 MTTR, MTBF 및 MTTF는 더 심층적이고 중요한 질문으로 이어지는 대화를 시작하는 좋은 기준선이나 벤치마크가 될 수 있습니다.

인시던트 관리 핸드북

전문가가 주요 인시던트에 대응하는 방식

무료 인시던트 관리 핸드북을 받으세요. Atlassian이 주요 인시던트를 관리하는 데 사용하는 모든 도구와 기술을 알아보세요.

MTTR에 대한 고지 사항

MTTR에 대해 이야기할 때 MTTR이 하나의 의미를 가진 단일 메트릭이라고 가정하기 쉽습니다. 하지만 사실 MTTR은 잠재적으로 네 가지 다른 측정값을 나타낼 수 있습니다. R은 수리(Repair), 복구(Recovery), 대응(Respond) 또는 해결(Resolve)을 의미할 수 있으며, 이 네 가지 메트릭은 겹치기도 하지만 저마다의 의미와 미묘한 차이가 있습니다.

따라서 팀이 MTTR 추적에 대해 이야기하고 있다면, 어떤 MTTR을 말하는 것이며 어떻게 정의하는지 명확히 하는 것이 좋습니다. 성공과 실패를 추적하기 전에, 팀은 정확히 어떤 것을 추적하고 있는지에 대해 합의를 이루고 모두가 같은 항목에 대해 이야기하고 있다는 것을 알도록 해야 합니다.

MTBF: 평균 장애 간격

평균 장애 간격이란 무엇입니까?

MTBF(평균 장애 간격)는 기술 제품에 발생하는 수리 가능한 장애 사이의 평균 시간입니다. 제품의 가용성과 안정성을 추적하는 데 사용되는 메트릭입니다. 장애 발생 사이의 시간이 길수록 시스템의 안정성이 높아집니다.

대부분의 회사의 목표는 MTBF를 최대한 높게 유지하는 것이며 이슈 사이에 수십만, 심지어는 수백만 시간을 유지하려고 하기도 합니다.

평균 장애 간격을 계산하는 방법

MTBF는 산술 평균을 사용하여 계산됩니다. 기본적으로, 계산하려는 기간(6개월, 1년, 5년일 수도 있음)의 데이터를 가져와서 그 기간의 총 가동 시간을 장애 발생 횟수로 나눕니다.

그러면 24시간 기간을 평가하려고 하는데 두 개의 별도의 인시던트에서 2시간의 가동 중지 시간이 발생했다고 가정해 보겠습니다. 총 가동 시간은 22시간이므로 이 값을 2로 나누면 11시간이 나옵니다. 따라서 MTBF는 11시간입니다.

안정성을 추적하는 데 사용하는 메트릭이기 때문에, MTBF는 예정된 유지 관리 중에 예상되는 가동 중지 시간은 고려하지 않습니다. 그보다는 예상치 못한 서비스 중단 및 이슈에 초점을 맞춥니다.

평균 장애 간격의 유래

MTBF는 시스템 장애가 비용 측면에서뿐만 아니라 생명에도 특히 중대한 결과를 초래하는 항공 산업에서 비롯된 용어입니다. 그 이후로 이 약어는 다양한 기술 및 기계 산업에 영향을 주었으며 특히 제조 분야에서 자주 사용됩니다.

평균 장애 간격을 사용하는 방법 및 시기

MTBF는 가장 안정성이 높은 제품을 사용하고 싶거나, 가장 안정성이 높은 비행기를 조종하거나, 공장에서 가장 안전한 제조 장비를 선택하려는 구매자에게 유용합니다.

내부 팀의 경우, 이슈를 파악하고 성공과 실패를 추적하는 데 도움이 되는 메트릭입니다. 또한 회사에서 고객이 부품을 교체하거나, 시스템을 업그레이드하거나, 유지 관리를 위해 제품을 점검해야 하는 시점에 대해 정보 기반의 권장 사항을 마련하는 데도 도움이 될 수 있습니다.

MTBF는 수리 가능한 시스템의 장애를 측정하는 메트릭입니다. 시스템 교체가 필요한 장애의 경우 보통 MTTF(평균 장애 시간)라는 용어를 사용합니다.

예를 들어, 자동차 엔진을 생각해 보세요. 예정되지 않은 엔진 정비 사이의 시간을 계산할 때는 평균 장애 간격인 MTBF를 사용하고, 전체 엔진 교체 사이의 시간을 계산할 때는 MTTF(평균 장애 시간)를 사용해야 할 것입니다.

각 점검이나 수리 사이의 시간을 계산할 때 MTBF(평균 장애 간격)를 사용하는 것을 시각적으로 보여주는 예시입니다.

MTTR: 평균 수리 시간

평균 수리 시간이란 무엇입니까?

MTTR(평균 수리 시간)은 시스템(일반적으로 기술적 또는 기계적)을 수리하는 데 걸리는 평균 시간입니다. 수리 시간과 테스트 시간이 모두 포함됩니다. 이 메트릭은 시스템이 다시 완전히 작동할 때까지의 시간을 측정합니다.

평균 수리 시간을 계산하는 방법

주어진 기간 동안 수리에 소요된 총 시간을 합산하고 그 시간을 수리 횟수로 나누면 MTTR을 계산할 수 있습니다.

예를 들어, 일주일 동안 수리를 진행할 것으로 예상되는 상황에서 그 기간 동안 10회의 중단이 발생했고 시스템은 4시간 동안 수리가 이루어졌다고 가정해 보겠습니다. 4시간은 240분이므로 240을 10으로 나눈 값은 24입니다. 즉, 이 경우의 평균 수리 시간은 24분입니다.

평균 수리 시간의 한계

평균 수리 시간이 시스템 중단 자체의 시간과 항상 같은 것은 아닙니다. 제품 장애나 시스템 중단 후 몇 분 안에 수리가 시작되는 경우가 있는 반면, 이슈가 감지된 시점과 수리가 시작되는 시점 사이에 차이가 있는 경우도 있습니다.

유지 관리 직원이 이슈를 얼마나 빨리 수리할 수 있는지 추적할 때 가장 유용한 메트릭입니다. 시스템 알림이나 수리 전 지연은 모두 인시던트 관리 프로그램의 성공과 실패를 평가할 때 중요한 요소지만, 이와 관련된 문제를 파악하기 위한 것은 아닙니다.

평균 수리 시간을 사용하는 방법 및 시기

MTTR은 지원 및 유지 관리 팀이 수리를 순조롭게 진행하기 위해 사용하는 메트릭입니다. 목표는 수리 프로세스와 팀의 효율성을 높여 이 수치를 최대한 낮추는 것입니다.

MTTR: 평균 복구 시간

평균 복구 시간이란 무엇입니까?

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

DevOps 연구 및 평가(DORA)에서 언급한 것과 같이, DevOps 팀의 안정성을 측정하는 데 사용할 수 있는 주요 DevOps 메트릭입니다.

평균 복구 시간을 계산하는 방법

평균 복구 시간은 특정 기간의 가동 중지 시간을 모두 합산한 후 그 값을 인시던트의 개수로 나누어 계산합니다. 24시간 동안 두 개의 별도의 인시던트로 인해 시스템이 30분 동안 가동 중지되었다고 가정해 보겠습니다. 30을 2로 나눈 값은 15이므로 MTTR은 15분입니다.

평균 복구 시간의 한계

이 MTTR은 전체 복구 프로세스의 속도를 측정한 것입니다. 속도가 원하는 만큼 빠릅니까? 경쟁업체와 비교하여 어떻습니까?

문제가 있는지 알아보는 데 도움이 되는 높은 수준의 메트릭입니다. 하지만 프로세스 내에서 문제가 어디에서 발생하는지 진단하고 싶은 경우(알림 시스템의 이슈인지, 팀이 해결하는 데 너무 많은 시간을 할애하는지, 누군가 해결 요청에 대응하는 데 너무 오래 걸리는지) 더 많은 데이터가 필요할 것입니다. 왜냐하면 장애와 복구 사이에는 여러 가지 일이 발생하기 때문입니다.

알림 시스템과 관련된 문제일 수 있습니다. 장애와 알림 사이에 지연이 있습니까? 알림이 적절한 담당자에게 전달되기까지 예상보다 오래 걸립니까?

진단과 관련된 문제일 수도 있습니다. 문제가 무엇인지 빠르게 알아낼 수 있습니까? 개선 가능한 프로세스가 있습니까?

아니면 수리와 관련된 문제일 수도 있습니다. 유지 관리 팀이 최대한 효율적으로 운영됩니까? 시간이 오래 걸린다면 어떤 방해 요소 때문에 그렇습니까?

이러한 질문에 답하기 위해서는 MTTR보다 더 깊이 살펴봐야 하지만, 평균 복구 시간은 복구 프로세스에 더 심층적인 조사가 필요한 문제가 있는지 진단하는 데 출발점이 될 수 있습니다.

평균 복구 시간을 사용하는 방법 및 시기

MTTR은 전반적인 복구 프로세스의 속도를 평가하는 데 좋은 메트릭입니다.

MTTR: 평균 해결 시간

평균 해결 시간이란 무엇입니까?

MTTR(평균 해결 시간)은 장애를 완전히 해결하는 데 걸리는 평균 시간입니다. 여기에는 장애 감지, 문제 진단, 이슈 수리에 소요되는 시간뿐만 아니라 장애가 다시 발생하지 않도록 하는 데 소요되는 시간도 포함됩니다.

이 메트릭은 해결을 처리하는 팀의 책임을 장기적인 성능 개선으로 확대합니다. 비유하자면 단순히 불을 끄는 것과 불을 끈 다음 집에 내화 처리 시공을 하는 것의 차이입니다.

MTTR과 고객 만족도 사이에는 강한 상관 관계가 있으므로 주의를 기울여야 할 메트릭입니다.

평균 해결 시간을 계산하는 방법

MTTR을 계산하려면 추적하려는 기간의 전체 해결 시간을 합산하고 인시던트의 수로 나눕니다.

따라서 24시간 동안 하나의 인시던트로 인해 시스템이 총 2시간 동안 가동이 중단되었으며 시스템 중단이 다시 발생하지 않도록 하기 위해 팀이 2시간을 더 할애했다면, 이슈 해결에 총 4시간이 소요된 것입니다. 즉, MTTR이 4시간이라는 뜻입니다.

평균 해결 시간 추적에 대한 참고 사항

MTTR은 대부분 업무 시간을 기준으로 계산됩니다(따라서 어느 날 퇴근 시간에 이슈를 해결하고 다음날 아침에 근본적인 이슈를 해결하는 데 시간을 들이면 MTTR에는 사무실에 없던 16시간이 포함되지 않습니다). 여러 지역에서 24시간 근무하는 팀이 있거나 업무 시간 이후에 근무하는 대기 중 직원이 있다면, 이 메트릭에 대한 시간을 추적하는 방법을 정의하는 것이 중요합니다.

평균 해결 시간을 사용하는 방법 및 시기

MTTR은 보통 예정된 서비스 요청이 아니라 예기치 않은 인시던트에 대해 이야기할 때 사용됩니다.

MTTR: 평균 대응 시간

평균 대응 시간이란 무엇입니까?

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

평균 대응 시간을 계산하는 방법

MTTR을 계산하려면 알림을 받은 시점부터 제품이나 서비스가 다시 정상적으로 작동할 때까지의 전체 대응 시간을 합산하고, 그런 다음 인시던트의 수로 나눕니다.

예를 들어, 주 40시간 근무 중 4번의 인시던트가 발생했고 총 1시간을 할애했다면(알림부터 해결까지), 그 주의 MTTR은 15분입니다.

평균 대응 시간을 사용하는 방법 및 시기

MTTR은 사이버 보안 측면에서 팀이 시스템 공격을 무력화했는지 측정할 때 자주 사용됩니다.

MTTA: 평균 확인 시간

평균 확인 시간이란 무엇입니까?

MTTA(평균 확인 시간)는 알림이 트리거된 시점부터 이슈에 대한 작업이 시작되는 시점까지의 평균 시간입니다. 팀의 대응성과 알림 시스템의 효율성을 추적하는 데 유용한 메트릭입니다.

평균 확인 시간을 계산하는 방법

MTTA를 계산하려면 알림과 확인 사이의 시간을 합산하고 인시던트의 수로 나눕니다.

예를 들어, 인시던트가 10개 발생했고 10개 모두에 대해 알림과 확인 사이의 시간이 총 40분인 경우, 40을 10으로 나누면 평균 4분이 계산됩니다.

평균 확인 시간을 사용하는 방법 및 시기

MTTA는 대응성을 추적하는 데 유용합니다. 팀이 알림 피로를 겪고 있으며 대응하는 데 너무 오래 걸립니까? 이 메트릭을 사용하면 이슈에 플래그를 지정하는 데 도움이 됩니다.

MTTF: 평균 장애 시간

평균 장애 시간이란 무엇입니까?

MTTF(평균 장애 시간)는 기술 제품에 발생하는 수리 불가능한 장애 사이의 평균 시간입니다. 예를 들어, 브랜드 X의 자동차 엔진이 완전히 고장나서 교체해야 하기 전까지 평균 500,000시간이 걸린다면 엔진의 MTTF는 500,000이 될 것입니다.

이 계산법은 시스템이 일반적으로 얼마나 오래 지속되는지 파악하고, 새 버전의 시스템이 이전 버전보다 성능이 좋은지 확인하고, 고객에게 예상 수명과 시스템 점검을 계획할 시기에 대한 정보를 제공하는 데 사용됩니다.

평균 장애 시간을 계산하는 방법

평균 장애 시간은 산술 평균으로, 평가하는 제품의 총 작동 시간을 합산한 후 그 합계를 장치 수로 나누어서 계산됩니다.

예를 들어, 전구의 MTTF를 알아내려고 하는 경우를 가정해 보겠습니다. 브랜드 Y의 전구는 고장날 때까지 평균적으로 얼마나 오래 쓸 수 있을까요? 더 나아가, 테스트할 전구 4개의 샘플이 있다고 가정해 보겠습니다(통계적으로 유의미한 데이터를 원하는 경우 훨씬 더 많은 샘플이 필요하지만 간단한 계산을 위해 작은 값을 사용하겠습니다).

전구 A는 수명이 20시간이고 전구 B는 18시간, 전구 C는 21시간이며 전구 D는 21시간입니다. 전구 시간을 모두 합하면 총 80시간입니다. 이 값을 4로 나누면 MTTF는 20시간이 됩니다.

전구의 MTTF를 알아내는 시각적 예시입니다. 전구를 사용한 총 시간을 전구의 개수로 나눈 값이 MTTF(평균 장애 시간)입니다

평균 장애 시간의 문제점

전구와 같은 예시를 통해 보면, MTTF는 아주 합리적인 메트릭입니다. 마지막 전구가 고장날 때까지 전구를 교체하고, 그 정보를 사용하여 전구의 복원력에 대한 결론을 내릴 수 있습니다.

그러나 그만큼 빨리 고장나지 않는 것들을 측정하는 경우에는 어떨까요? 몇 년씩 사용하도록 만들어진 것이라면 어떻게 될까요? 그런 경우에는 MTTF가 자주 사용되기는 하지만 그다지 좋은 메트릭이 되지는 못합니다. 왜냐하면 제품이 고장날 때까지 사용하는 대신, 정해진 기간 동안 제품을 사용하고 고장난 횟수를 측정하는 경우가 대부분이기 때문입니다.

예를 들어, 브랜드 Z의 태블릿에 대한 MTTF 통계를 얻으려고 하는 경우를 가정해 보겠습니다. 태블릿은 몇 년은 거뜬히 사용하도록 만들어졌습니다. 하지만 브랜드 Z는 6개월에 대한 데이터만 수집할 수 있습니다. 그래서 6개월 동안 태블릿 100대를 테스트합니다. 정확히 6개월 만에 태블릿 1대가 고장난다고 해 보겠습니다.

총 작동 시간(6개월 x 태블릿 100대)을 곱하면 600개월이라는 결과가 나옵니다. 1대의 태블릿에서만 장애가 발생했으므로 1로 나누면 MTTR은 600개월, 즉 50년입니다.

브랜드 Z의 태블릿을 1대당 평균 50년 동안 사용할 수 있다는 의미일까요? 그럴 가능성은 거의 없습니다. 그래서 이런 경우에는 메트릭이 효과를 잃게 됩니다.

평균 장애 시간을 사용하는 방법 및 시기

MTTF는 수명이 짧은 제품 및 시스템(예: 전구)의 평균 수명을 평가할 때 효과적입니다. 또한 완전한 제품 장애를 평가하는 경우에만 사용할 수 있습니다. 수리가 필요한 인시던트 사이의 시간을 계산하는 경우, MTBF(평균 장애 간격)라는 약어를 선택하세요.

MTBF, MTTR, MTTF 및 MTTA 비교

그렇다면 인시던트 관리를 추적하고 개선하려면 어떤 측정값이 더 좋습니까?

정답은 모두 다입니다.

가끔 같은 의미로 사용되긴 해도, 각 메트릭은 서로 다른 인사이트를 제공합니다. 여러 메트릭을 함께 사용하면 팀이 인시던트 관리에서 얼마나 성공적인지, 그리고 팀이 어떤 부분을 개선할 수 있는지에 대해 더 완전한 관점을 제공할 수 있습니다.

MTBF, MTTR, MTTA 및 MTTF를 함께 사용하여 인시던트 관리를 개선할 수 있는 방법을 보여주는 그림

평균 복구 시간은 시스템을 얼마나 빨리 다시 가동할 수 있는지 알려줍니다.

평균 대응 시간을 함께 사용하면 복구 시간 중 팀에서 사용한 시간이 얼마인지, 그리고 알림 시스템이 사용한 시간이 얼마인지 알 수 있습니다.

평균 수리 시간까지 사용하면 팀이 수리와 진단에 각각 얼마나 많은 시간을 할애하는지 확인하게 됩니다.

평균 해결 시간을 더하면 이슈로 인한 실제 가동 중지 시간을 넘어서 이슈 수정 및 해결의 완전한 범위를 파악하게 됩니다.

평균 장애 간격도 사용하면 더 큰 그림을 볼 수 있게 되며, 팀이 향후 이슈를 방지하거나 줄이는 데 얼마나 성공적인지 알 수 있습니다.

그런 다음 평균 장애 시간을 활용하면 제품 또는 시스템의 전체 수명 주기를 파악할 수 있습니다.

Jira Service Management는 팀이 KPI를 추적하고 인시던트 관리 관행을 모니터링 및 최적화할 수 있도록 보고 기능을 제공합니다.

논의되는 제품
Jira Service Management 로고

알림을 중앙에서 관리하여 적시에, 적절한 담당자에게 알림

다음 단계
Severity levels