Ⅰ-13. MTTR(평균 수리시간)과 장애 복구시간 분석

1. MTTR은 무엇을 의미하는가

MTTR은 Mean Time To Repair의 약자로 일반적으로 평균 수리시간을 의미한다.

수리 가능한 시스템에서 여러 장애를 처리하는 데 실제로 소요된 수리시간을 평균하여 장애 대응 능력을 평가하는 지표로 활용한다.

기본적인 계산식은 다음과 같다.

MTTR = 총 수리시간 ÷ 수리 횟수

예를 들어 동일한 시스템에서 4회의 장애가 발생했고, 각 장애의 실제 수리시간이 다음과 같았다고 가정해 보자.

장애	실제 수리시간
1회	1시간
2회	2시간
3회	3시간
4회	4시간
합계	10시간

따라서

MTTR = 10시간 ÷ 4회 = 2.5시간

이다.

즉, 이 시스템은 관측된 4회의 장애에서 평균 2.5시간의 수리시간이 필요했다는 의미다.

여기서 중요한 것은 2.5시간이 장애 발생부터 서비스 정상화까지 걸린 전체 시간이라고 자동으로 해석해서는 안 된다는 점이다.

MTTR의 정확한 값은 조직이나 분석 기준에서 수리시간을 어디에서 시작하고 어디에서 종료하는지 정의한 뒤 계산해야 한다.

2. MTTR과 장애 복구시간은 같은 용어가 아니다

MTTR을 “장애가 발생해서 서비스가 정상화될 때까지 걸린 모든 시간”이라고 단순하게 이해하면 실제 장애 분석에서 혼동이 발생한다.

예를 들어 서버 장애가 발생한 후 다음과 같은 과정이 진행될 수 있다.

장애 발생 → 장애 감지 → 담당자 인지 → 원인 진단 → 수리 → 재가동 → 검증 → 서비스 정상화

이 가운데 실제 부품을 교체하는 데 20분이 걸렸더라도 장애 감지와 진단에 1시간이 필요했다면 전체 서비스 복구까지 걸린 시간은 20분보다 훨씬 길다.

따라서 다음을 구분해서 기록하는 것이 중요하다.

수리시간 ≠ 전체 장애시간 ≠ 서비스 복구시간

3. MTTR 관련 용어를 혼동하지 않아야 한다

장애 대응 과정에서는 MTTR과 함께 여러 시간 지표가 사용된다.

하지만 이것들을 모두 MTTR의 하위 종류라고 보는 것은 적절하지 않다.

대표적으로 다음과 같이 구분하는 것이 명확하다.

용어	의미	측정 구간
MTTD	Mean Time To Detect	장애 발생 → 장애 감지
MTTA	Mean Time To Acknowledge	장애 감지 → 담당자 인지·대응 시작
MTTR	Mean Time To Repair	정의된 수리 시작점 → 수리 완료
Mean Time To Restore/Recovery	평균 서비스 복구시간	장애 발생 또는 감지 → 서비스 복구
Mean Time To Resolve	평균 문제 해결시간	장애 인지 → 문제 해결 완료

여기서 특히 주의할 점은 MTTD와 MTTA는 MTTR의 다른 이름이 아니라 별도의 지표라는 것이다.

또한 MTTR 역시 모든 조직에서 동일한 측정 범위를 사용하는 것은 아니다.

어떤 조직은 실제 수리 작업시간을 MTTR로 관리하고, 어떤 조직은 장애 복구까지의 시간을 MTTR이라고 표현하기도 한다.

따라서 전문적인 분석에서는 단순히 “MTTR이 30분이다”라고 기록하는 것보다 MTTR의 시작점과 종료점을 함께 정의하는 것이 중요하다.

4. 이 글에서는 MTTR의 범위를 어떻게 정의할 것인가

이번 컴퓨터 시스템 분석에서는 MTTR을 무조건 “전체 장애시간”으로 사용하지 않는다.

MTTR = 정의된 수리 작업에 소요된 평균 시간

으로 기본 개념을 설명하고,

서비스 운영 측면에서는 별도로

장애 복구시간 = 장애 발생 또는 감지 이후 서비스가 정상화될 때까지의 시간

을 구분해서 분석한다.

이렇게 구분하면 부품을 실제로 수리하는 데 걸린 시간과 사용자가 서비스를 다시 이용할 수 있게 된 시간을 혼동하지 않을 수 있다.

특히 가용도 분석에서는 실제 서비스 중단시간이 중요하므로 MTTR과 서비스 복구시간의 측정 범위를 반드시 확인해야 한다.

5. 장애 복구시간 단계표

실제 장애 대응은 하나의 시간으로 이루어지지 않는다.

다음과 같이 단계별로 나누어 기록하면 어느 과정에서 복구가 지연되는지 확인할 수 있다.

단계	시작	종료	의미	관련 지표
① 장애 발생	정상 상태	장애 발생	시스템 또는 서비스에 이상 발생	장애 발생시각
② 장애 감지	장애 발생	장애 인지	모니터링 또는 사람이 장애를 발견	MTTD
③ 대응 시작	장애 감지	담당자 대응	담당자가 장애를 확인하고 대응 시작	MTTA
④ 원인 진단	대응 시작	원인 확인	로그·상태·구성 등을 분석하여 원인 파악	진단시간
⑤ 복구 준비	원인 확인	작업 준비 완료	부품·인력·권한·백업 등 확보	준비시간
⑥ 수리·조치	수리 시작	수리 완료	부품 교체, 설정 변경, 재시작 등	MTTR
⑦ 시스템 복구	수리 완료	시스템 정상 동작	OS·데이터·서비스 등을 정상 상태로 복구	복구시간
⑧ 검증	시스템 복구	정상 확인	데이터·로그·연결·성능 등을 확인	검증시간
⑨ 서비스 정상화	정상 확인	사용자 이용 가능	실제 서비스 제공 상태 확인	서비스 복구시간
⑩ 근본원인 조치	장애 대응	재발방지 조치 완료	원인 제거 및 재발 방지	해결시간

이 표에서 MTTR은 ⑥ 수리·조치 구간으로 정의한 경우의 예시다.

조직에서 MTTR을 서비스 정상화까지의 시간으로 정의한다면 측정 구간은 달라질 수 있다.

따라서 표의 핵심은 특정 용어를 억지로 고정하는 것이 아니라 각 시간의 시작점과 종료점을 명확하게 기록하는 것이다.

6. 실제 장애 사례로 계산해 보면 차이가 명확해진다

서버에서 장애가 발생했고 다음과 같은 상황이었다고 가정해 보자.

• 02:00 장애 발생
• 02:05 장애 감지
• 02:10 담당자 대응 시작
• 03:00 원인 확인
• 03:20 수리 시작
• 03:40 수리 완료
• 04:00 시스템 정상 확인
• 04:20 서비스 정상화

이 경우 각 시간은 서로 다르다.

장애 발생 → 장애 감지 = 5분

장애 감지 → 대응 시작 = 5분

대응 시작 → 원인 확인 = 50분

수리 시작 → 수리 완료 = 20분

수리 완료 → 시스템 정상 확인 = 20분

시스템 정상 확인 → 서비스 정상화 = 20분

그리고

장애 발생 → 서비스 정상화 = 2시간 20분

이다.

따라서 이 사례에서 실제 수리시간을 기준으로 MTTR을 정의했다면 20분이고, 서비스 복구시간을 별도로 관리한다면 2시간 20분이 된다.

둘 중 어느 숫자가 “맞는 MTTR”인지를 논쟁하기보다 조직에서 MTTR을 어떤 구간으로 정의했는지를 먼저 확인해야 한다.

7. 왜 이러한 구분이 중요한가

만약 위 사례에서 “MTTR이 20분이므로 장애 대응이 빠르다”고만 판단한다면 실제 서비스가 2시간 20분 동안 영향을 받은 사실을 놓칠 수 있다.

반대로 서비스 정상화까지 걸린 2시간 20분을 모두 수리시간이라고 기록하면 실제 수리 작업 자체는 20분이었다는 사실을 알 수 없게 된다.

따라서 장애 분석에서는 최소한 다음 세 가지를 구분해서 보는 것이 좋다.

① 장애 발생부터 서비스 정상화까지의 전체 장애시간

② 실제 수리·조치에 걸린 시간

③ 각 단계에서 발생한 대기·진단·검증 시간

이렇게 해야 복구가 늦어진 원인을 정확하게 찾을 수 있다.

8. MTTR을 줄이는 것과 전체 복구시간을 줄이는 것은 다를 수 있다

예를 들어 다음과 같은 장애가 발생했다고 하자.

감지 5분 → 진단 2시간 → 부품 확보 3시간 → 수리 30분 → 검증 20분

여기서 MTTR을 실제 수리시간으로 정의한다면 수리시간은 30분이다.

하지만 서비스 복구까지는 훨씬 긴 시간이 필요하다.

이 경우 수리 작업을 30분에서 10분으로 줄이는 것보다 부품 확보에 필요한 3시간을 줄이는 것이 전체 장애시간 감소에 훨씬 큰 효과를 낸다.

따라서 장애 복구 분석에서는 MTTR 하나만 보고 개선 방향을 결정해서는 안 된다.

어느 단계가 전체 복구시간을 가장 많이 차지하는가?

이 질문이 더 중요할 수 있다.

9. 장애 감지시간과 MTTR은 별도로 개선해야 한다

장애가 발생했는데 시스템이 이를 늦게 발견한다면 실제 복구 작업은 늦게 시작된다.

따라서 자동 모니터링과 장애 알림은 전체 장애시간을 줄이는 데 중요한 역할을 한다.

다만 이것을 MTTR 자체와 혼동해서는 안 된다.

장애를 발견하는 시간은 MTTD

담당자가 인지하고 대응을 시작하는 시간은 MTTA

정의된 수리구간에 필요한 시간은 MTTR

으로 구분하면 장애 대응 과정이 훨씬 명확해진다.

10. 진단시간은 MTTR과 별도로 관리할 필요가 있다

컴퓨터 장애에서는 동일한 증상이 서로 다른 원인에서 발생할 수 있다.

예를 들어 서버가 갑자기 재부팅되었다면 다음과 같은 원인을 검토할 수 있다.

• 전원 문제
• 메모리 오류
• CPU 과열
• 메인보드 이상
• 저장장치 오류
• 운영체제 오류
• 드라이버 충돌
• 펌웨어 문제

원인을 찾는 데 3시간이 걸리고 실제 부품 교체에는 20분밖에 걸리지 않았다면 복구 지연의 핵심은 수리기술이 아니라 진단과 분석 과정이다.

따라서 장애 데이터를 분석할 때는 MTTR과 함께 진단시간도 별도로 기록하는 것이 좋다.

11. 예비 부품이 없으면 수리시간 외에 대기시간이 발생한다

장애 원인을 정확하게 찾아냈더라도 필요한 부품이 없다면 실제 복구는 지연된다.

예를 들어 서버의 전원공급장치가 고장났는데 동일한 부품이 현장에 없다면,

원인 확인 → 부품 대기 → 수리

라는 추가 시간이 발생한다.

따라서 MTTR을 실제 수리 작업시간으로 관리한다면 부품 대기시간이 MTTR에 포함되는지 별도로 정의해야 한다.

운영 측면에서는 오히려 부품 대기시간 자체를 별도의 지연시간으로 기록하는 것이 개선 원인을 찾는 데 유리할 수 있다.

12. 이중화에서는 서비스 복구와 장비 수리를 더욱 분리해야 한다

이중화 시스템에서는 서버 A가 장애를 일으켜도 서버 B가 즉시 서비스를 이어받을 수 있다.

이 경우 사용자가 체감하는 서비스 중단시간은 매우 짧거나 없을 수 있다.

그러나 장애가 발생한 서버 A는 여전히 수리가 필요하다.

따라서 다음을 구분해야 한다.

서비스 복구시간

사용자가 서비스를 다시 이용할 수 있게 되는 데 걸린 시간

장비 수리시간

장애 장비를 정상 상태로 되돌리는 데 필요한 시간

예를 들어 서버 A 장애 후 서버 B로 10초 만에 전환되었지만 서버 A 수리에 2시간이 걸렸다면,

서비스 영향 = 매우 짧음

장비 수리 = 2시간

으로 기록할 수 있다.

이 차이를 구분해야 이중화의 효과를 제대로 평가할 수 있다.

13. MTTR과 가용도는 연결되지만 같은 지표는 아니다

수리 가능한 시스템에서는 단순화된 조건에서 다음 관계를 사용할 수 있다.

가용도 = MTBF ÷ (MTBF + MTTR)

이 식에서는 MTTR이 짧아질수록 가용도가 높아지는 관계를 확인할 수 있다.

그러나 여기서 사용하는 MTTR이 실제 서비스 중단시간과 반드시 동일하다고 볼 수는 없다.

특히 이중화 시스템에서는 장비 수리시간은 길더라도 서비스는 계속 제공될 수 있기 때문이다.

따라서 실제 가용도를 분석할 때는 가용도 계산에 사용한 장애·복구시간의 정의를 별도로 명시하는 것이 중요하다.

14. MTTR 평균값만으로 장애 대응능력을 판단하면 안 된다

MTTR은 평균값이므로 일부 장시간 장애의 특성을 충분히 보여주지 못할 수 있다.

예를 들어 대부분의 장애가 10분 이내에 복구되더라도 한 번의 대규모 장애가 20시간 지속되었다면 평균값 하나만으로는 이 위험을 제대로 표현하기 어렵다.

따라서 다음 항목을 함께 확인하는 것이 좋다.

• 평균 복구시간
• 최대 복구시간
• 장애별 복구시간 분포
• 장시간 장애 횟수
• 장애 유형별 복구시간
• 서비스 영향 범위

평균은 전반적인 경향을 보여주지만 최악의 장애 상황을 대신 설명해 주지는 않는다.

15. MTTR을 낮추는 핵심은 병목을 찾는 것이다

MTTR 개선을 단순히 “수리 속도를 높이는 작업”으로 생각하면 개선 방향을 잘못 잡을 수 있다.

예를 들어 실제 수리시간은 20분인데 진단에 2시간, 부품 확보에 3시간이 걸린다면 수리 담당자의 작업속도를 높이는 것만으로는 전체 복구시간을 크게 줄이기 어렵다.

따라서 다음과 같이 접근해야 한다.

장애 발생

→ 감지시간 확인

→ 대응 시작시간 확인

→ 진단시간 확인

→ 대기시간 확인

→ 실제 수리시간 확인

→ 검증시간 확인

→ 서비스 정상화시간 확인

이렇게 전체 시간을 분해해야 실제 병목을 찾을 수 있다.

16. 빠른 복구와 근본원인 제거는 별개의 문제다

장애를 빠르게 복구했다고 해서 장애 원인이 해결된 것은 아니다.

예를 들어 서버가 반복적으로 다운될 때마다 자동 재시작하여 서비스를 1분 만에 복구한다면 서비스 복구시간은 짧게 나타날 수 있다.

하지만 같은 장애가 계속 발생한다면 시스템의 근본적인 안정성이 개선된 것은 아니다.

따라서 장애 대응에서는

현재 장애를 빠르게 복구하는 것

과

동일 장애의 재발 원인을 제거하는 것

을 분리해서 관리해야 한다.

17. 장애 유형별 MTTR을 비교하면 개선 우선순위를 찾을 수 있다

모든 장애를 하나의 평균값으로 관리하면 특정 장애 유형의 문제가 가려질 수 있다.

예를 들어 다음과 같이 구분할 수 있다.

• 전원 장애
• 저장장치 장애
• 메모리 장애
• 네트워크 장애
• 운영체제 장애
• 데이터베이스 장애
• 서버 하드웨어 장애
• 데이터센터 설비 장애

특정 유형에서 MTTR이 지속적으로 높게 나타난다면 그 장애의 진단 절차, 부품 공급, 담당 인력 또는 복구 절차를 우선적으로 개선할 수 있다.

18. 핵심 정리

MTTR은 Mean Time To Repair, 즉 평균 수리시간을 의미하지만, 실제 현장에서는 조직과 분석 목적에 따라 측정 범위가 달라질 수 있다.

따라서 “MTTR이 30분이다”라는 숫자만으로는 충분하지 않다.

어디에서 측정을 시작했고, 어디에서 종료했는가를 함께 확인해야 한다.

또한 다음 지표들은 서로 구분해야 한다.

MTTD = 장애 감지까지 걸린 평균 시간

MTTA = 장애 인지 후 대응을 시작하기까지의 평균 시간

MTTR = 정의된 수리구간에 필요한 평균 시간

그리고 서비스 운영에서는 별도로 장애 발생 또는 감지부터 서비스 정상화까지의 복구시간을 관리할 수 있다.

따라서 컴퓨터 시스템의 장애를 제대로 분석하려면

장애 발생 → 감지 → 대응 → 진단 → 복구 준비 → 수리 → 시스템 복구 → 검증 → 서비스 정상화

의 전체 과정을 기록하고, 각 단계에서 시간이 얼마나 소비되었는지를 확인해야 한다.

결국 MTTR 분석의 핵심은 평균 수리시간이라는 숫자 하나를 만드는 것보다 장애 복구 과정에서 실제 병목이 어디에 있는지를 찾아내는 것이다.

그리고 Ⅰ-12에서 살펴본 MTBF와 연결하면,

MTBF = 고장이 발생하는 간격

MTTR = 정의된 수리구간의 평균 시간

가용도 = 고장과 복구의 결과로 실제 서비스가 유지된 정도

라는 관계로 이해할 수 있다.

따라서 시스템의 안정성을 제대로 판단하려면 고장 빈도, 수리시간, 서비스 복구시간, 이중화 여부와 실제 서비스 영향까지 함께 분석해야 한다.