Ⅰ-14. MTTR 계산 예시

컴퓨터 시스템의 장애 대응 성능을 평가할 때 MTTR(Mean Time To Repair/Restore)은 중요한 지표다.

하지만 MTTR을 단순히 여러 장애의 복구시간을 더해 평균낸 숫자로만 보면 실제 시스템의 복구 수준을 제대로 판단하기 어렵다.

같은 MTTR이라도 장애가 발생하는 방식, 복구시간의 편차, 장시간 장애의 존재 여부, 원인별 복구 특성에 따라 시스템의 실제 안정성은 크게 달라질 수 있기 때문이다.

따라서 MTTR은 계산 → 분석 → 해석 → 판단의 순서로 보는 것이 중요하다.

1. 기본적인 MTTR 계산

5회의 장애가 발생했고 각각의 복구시간이 다음과 같다고 가정해 보자.

장애	복구시간
장애 1	2시간
장애 2	4시간
장애 3	1시간
장애 4	3시간
장애 5	5시간

전체 복구시간은 다음과 같다.

2 + 4 + 1 + 3 + 5 = 15시간

장애 발생 횟수는 5회이므로,

MTTR = 전체 복구시간 ÷ 장애 발생 횟수

MTTR = 15 ÷ 5 = 3시간

따라서 이 시스템의 평균 복구시간은 3시간이다.

여기까지는 단순한 계산이다.

하지만 실제 운영에서는 이 3시간이라는 숫자만 보고 시스템의 복구 성능을 판단해서는 안 된다.

2. 같은 MTTR이라도 장애 특성은 다를 수 있다

다른 시스템에서 다음과 같은 복구시간이 발생했다고 가정해 보자.

1시간, 1시간, 1시간, 1시간, 11시간

전체 복구시간은 역시 15시간이고 장애도 5회이므로,

MTTR = 15 ÷ 5 = 3시간

앞의 사례와 MTTR은 동일하게 3시간이다.

그러나 실제 장애 특성은 전혀 다르다.

첫 번째 사례는 복구시간이 1~5시간 사이에 분포되어 있지만, 두 번째 사례는 대부분의 장애가 1시간 안에 복구되고 단 한 번의 장애가 11시간이나 지속되었다.

따라서 두 시스템을 단순히 “MTTR 3시간”이라는 숫자만으로 동일하게 평가하면 중요한 차이를 놓치게 된다.

우리의 관점에서는 여기서 평균값보다 복구시간의 분포와 최대 복구시간을 함께 확인해야 한다.

특히 11시간처럼 특정 장애 하나가 전체 평균을 크게 끌어올리는 경우에는 그 장애가 왜 장시간 지속되었는지를 별도로 분석해야 한다.

즉,

평균 MTTR → 복구시간의 분포 → 최대 복구시간 → 장시간 장애의 원인

순서로 분석하는 것이 실제 운영 판단에 더 유용하다.

3. 장애 발생부터 서비스 정상화까지의 시간도 확인해야 한다

장애가 발생했다고 해서 바로 복구작업이 시작되는 것은 아니다.

예를 들어 다음과 같은 상황을 생각해 보자.

• 10:00 장애 발생
• 10:10 장애 인지
• 11:00 원인 확인
• 11:20 복구작업 시작
• 12:00 복구작업 완료
• 12:20 서비스 정상화 확인

이 경우 실제 장비 또는 시스템에 대한 복구작업은 40분이다.

하지만 장애가 발생한 10:00부터 서비스가 정상화된 12:20까지는 2시간 20분이 걸렸다.

이 차이를 분석하지 않으면 다음과 같은 문제가 발생할 수 있다.

“수리 자체는 40분밖에 걸리지 않았으니 복구가 빠르다.”

하지만 실제 사용자는 2시간 20분 동안 정상적인 서비스를 이용하지 못했다.

우리의 관점에서는 이 경우 복구작업 시간만 볼 것이 아니라,

장애 발생 → 장애 인지 → 원인 분석 → 복구작업 → 서비스 정상화

각 단계에서 얼마나 시간이 소요되었는지를 확인해야 한다.

다만 MTTR의 시작과 종료 기준은 조직이나 시스템의 측정 정책에 따라 다를 수 있다.

따라서 중요한 것은 특정 계산법을 무조건 적용하는 것이 아니라 어디서부터 어디까지를 복구시간으로 정의했는지를 명확하게 정하고 동일한 기준으로 지속적으로 측정하는 것이다.

4. 여러 장애의 평균 복구시간 계산

복구시간을 분 단위로 관리하는 경우에도 계산 방법은 동일하다.

예를 들어 4회의 장애가 발생했고 복구시간이 다음과 같다고 하자.

• 장애 1: 30분
• 장애 2: 90분
• 장애 3: 60분
• 장애 4: 120분

전체 복구시간은,

30 + 90 + 60 + 120 = 300분

장애 발생 횟수는 4회이므로,

MTTR = 300 ÷ 4 = 75분

따라서 평균 복구시간은 75분이다.

그러나 여기서도 75분이라는 평균값만 기록하는 것으로 분석을 끝내서는 안 된다.

120분이 걸린 장애가 왜 발생했는지, 30분 만에 복구된 장애와 어떤 차이가 있었는지까지 확인해야 실제 복구 성능을 개선할 수 있다.

5. MTTR 감소가 가용도에 미치는 영향

MTTR은 시스템 가용도와도 밀접한 관계가 있다.

예를 들어 MTBF가 1,000시간이고 MTTR이 10시간이라고 가정하면,

가용도 = MTBF ÷ (MTBF + MTTR)

가용도 = 1,000 ÷ (1,000 + 10)

약 **99.01%**가 된다.

이때 MTTR을 10시간에서 5시간으로 줄이면,

가용도 = 1,000 ÷ (1,000 + 5)

약 **99.50%**가 된다.

즉, 고장 발생 간격이 동일하더라도 장애가 발생했을 때 복구하는 데 걸리는 시간을 줄이면 시스템의 가용도를 높일 수 있다.

우리의 관점에서 보면 MTTR 개선은 단순히 “수리를 빨리했다”는 의미가 아니라 서비스 중단시간을 줄여 시스템의 실제 사용 가능 시간을 높이는 활동으로 볼 수 있다.

6. MTTR을 해석할 때 함께 확인해야 할 항목

MTTR을 제대로 분석하려면 다음 항목을 함께 확인하는 것이 좋다.

분석 항목	확인 내용
평균 복구시간	전체적인 복구 성능
최소 복구시간	가장 빠르게 복구된 장애
최대 복구시간	장시간 장애 여부
복구시간 분포	특정 장애에 시간이 집중되는지 여부
장애 발생 횟수	장애 자체가 증가하거나 감소했는지
장애 원인별 MTTR	어떤 원인에서 복구가 오래 걸리는지
장애 인지시간	장애를 얼마나 빨리 발견했는지
원인 분석시간	원인 파악에 얼마나 시간이 걸렸는지
실제 복구시간	조치 자체에 소요된 시간
서비스 정상화 확인시간	사용자가 실제 서비스를 다시 이용할 수 있게 된 시점
장시간 장애 횟수	심각한 서비스 중단이 반복되는지
재발 여부	같은 원인의 장애가 다시 발생하는지

이렇게 보면 MTTR은 단순한 하나의 숫자가 아니라 장애 대응 과정 전체를 분석하기 위한 출발점이라는 것을 알 수 있다.

7. MTTR이 낮아졌다고 항상 좋은 것은 아니다

MTTR이 감소했다는 결과만 보고 시스템이 개선되었다고 판단하는 것도 주의해야 한다.

예를 들어 장애가 발생할 때마다 시스템을 재부팅하거나 부품을 교체해 빠르게 서비스를 복구했다고 하자.

이 방법으로 MTTR은 낮아질 수 있다.

하지만 장애의 근본 원인을 해결하지 못했다면 같은 장애가 다시 발생할 가능성이 남아 있다.

이 경우에는,

복구는 빨라졌지만 장애가 반복되는 시스템

이 될 수 있다.

우리의 관점에서 좋은 MTTR 개선은 단순히 복구시간을 줄이는 것이 아니다.

장애를 빠르게 복구하면서 동시에 원인을 분석하고 재발 가능성까지 낮추는 것이 더 중요한 개선이다.

따라서 MTTR이 감소했다면 다음 질문을 함께 해야 한다.

• 왜 복구시간이 줄었는가?
• 단순히 임시조치가 빨라진 것인가?
• 원인 분석시간도 줄었는가?
• 같은 원인의 장애가 다시 발생하고 있지는 않은가?
• 장시간 장애가 감소했는가?
• 실제 서비스 중단시간도 감소했는가?

8. MTTR 개선 전후를 비교하는 방법

예를 들어 개선 전과 개선 후의 장애 데이터를 다음과 같이 비교할 수 있다.

항목	개선 전	개선 후
MTTR	120분	75분
최대 복구시간	360분	180분
장애 발생 횟수	5회	5회
장시간 장애	2회	0회

MTTR은 120분에서 75분으로 감소했다.

하지만 여기서 더 중요한 변화는 최대 복구시간이 360분에서 180분으로 줄었고 장시간 장애가 2회에서 0회로 감소했다는 점이다.

우리의 관점에서는 이런 변화가 단순히 평균값 하나가 감소한 것보다 실제 장애 대응 품질이 개선되었다는 근거로 더 의미가 있다.

반대로 MTTR은 감소했지만 최대 복구시간이나 장시간 장애가 증가했다면 평균값만 보고 개선되었다고 판단해서는 안 된다.

9. MTTR을 실제 운영 판단에 사용하는 방법

MTTR을 운영지표로 사용할 때는 다음과 같은 순서로 판단할 수 있다.

① 평균 복구시간을 계산한다.

전체 복구시간을 장애 발생 횟수로 나누어 기본적인 MTTR을 확인한다.

② 복구시간의 분포를 확인한다.

평균값 주변에 복구시간이 고르게 분포하는지, 특정 장애 하나가 평균을 크게 끌어올리는지 확인한다.

③ 최대 복구시간과 장시간 장애를 확인한다.

평균이 낮더라도 한 번의 장시간 장애가 서비스에 큰 영향을 줄 수 있기 때문이다.

④ 장애 원인을 구분한다.

하드웨어, 소프트웨어, 네트워크, 운영체제, 설정 오류 등 원인별로 MTTR을 구분하면 어느 영역의 대응이 느린지 파악할 수 있다.

⑤ 복구 과정의 어느 단계에서 시간이 지연되는지 확인한다.

장애 인지가 늦은 것인지, 원인 분석이 늦은 것인지, 실제 복구작업이 늦은 것인지 구분해야 한다.

⑥ 재발 여부를 확인한다.

복구시간이 줄었더라도 동일한 원인의 장애가 반복된다면 근본적인 개선이 이루어졌다고 보기 어렵다.

⑦ 실제 서비스 영향까지 확인한다.

최종적으로 중요한 것은 숫자 자체가 아니라 사용자가 서비스를 이용하지 못한 시간이 얼마나 줄었는가이다.

10. 고객이 직접 판단할 수 있는 MTTR 판단 기준

MTTR을 확인할 때 고객은 단순히 “몇 분인가?”만 볼 필요는 없다.

다음 질문을 통해 시스템의 실제 복구 성능을 판단할 수 있다.

• 평균 MTTR이 이전보다 감소했는가?
• 평균값을 특정 장시간 장애가 왜곡하고 있지는 않은가?
• 최대 복구시간은 얼마나 되는가?
• 장시간 장애가 얼마나 자주 발생하는가?
• 어떤 장애 원인에서 복구가 가장 오래 걸리는가?
• 장애 인지부터 원인 분석까지 시간이 오래 걸리고 있지는 않은가?
• 실제 복구작업보다 다른 단계에서 시간이 더 지연되고 있지는 않은가?
• MTTR이 낮아졌지만 같은 장애가 반복되고 있지는 않은가?
• 실제 서비스 중단시간도 함께 감소했는가?
• 평균값뿐 아니라 장애별 복구시간의 편차도 줄어들었는가?

이런 기준을 함께 보면 MTTR 숫자만 보고 시스템을 판단하는 것보다 훨씬 정확하게 복구 성능을 평가할 수 있다.

핵심정리

MTTR은 전체 복구시간 ÷ 장애 발생 횟수로 계산할 수 있지만, 평균값 하나만으로 시스템의 복구 성능을 판단해서는 안 된다.

우리의 분석에서는 먼저 평균 MTTR을 확인하고, 그다음 복구시간의 분포와 최대 복구시간, 장시간 장애, 장애 원인별 복구시간, 장애 인지와 원인 분석에 걸린 시간, 재발 여부, 실제 서비스 중단시간까지 함께 살펴봐야 한다.

특히 MTTR이 낮아졌다는 사실만으로 시스템이 안정되었다고 판단해서는 안 된다.

빠르게 복구하는 것과 같은 장애가 다시 발생하지 않도록 개선하는 것은 서로 다른 문제이기 때문이다.

따라서 좋은 MTTR 관리는 단순히 평균 복구시간을 낮추는 것이 아니라,

불필요한 지연을 줄이고 → 장애 원인을 빠르게 찾아내고 → 서비스를 신속하게 정상화하며 → 같은 장애의 재발 가능성까지 낮추는 것

으로 판단하는 것이 적절하다.