평균 복구 시간

평균 복구 시간은 고장 난 서비스를 다시 쓸 수 있게 되돌리는 데 평소 얼마나 걸리는지를 수 하나로 알려 줍니다. 사고마다 걸린 시간을 모아 평균을 낸 값입니다. 고장이 얼마나 드문지가 아니라 났을 때 얼마나 빨리 걷어내는지를 봅니다.

쉽고 빠른 이해

평균 복구 시간은 사고가 나서 서비스가 돌아오기까지 걸린 시간을 여러 건 모아 평균 낸 수입니다. 지난달 사고 셋이 각각 12분, 25분, 3시간 남짓이었다면 평균은 한 시간을 조금 넘습니다.

이 값이 없으면 「요즘 사고 대응이 나아졌다」가 느낌으로만 남습니다. 경보를 다듬고 되돌리기를 자동으로 만들어도 그 손질이 시간을 줄였는지 확인할 방법이 없습니다. 한 팀이 같은 기준으로 재서 추세를 볼 때 쓰는 값입니다. 다른 팀과 견주는 데는 쓰지 않습니다.

도는 순서:

시계를 언제 켜고 언제 끌지를 미리 정합니다
사고가 끝날 때마다 그 사이의 시간을 적어 둡니다
정한 기간의 시간을 모두 더해 사고 건수로 나눕니다

대가는 긴 사고 한 건이 이 값을 통째로 흔든다는 것입니다. 사고가 몇 건 안 되면 더 그렇습니다. 그래서 이 값 하나만 보지 않고 가운데 값과 사고 건수를 같이 봅니다.

상세

집 정전을 떠올리면 쉽습니다. 이 동네가 정전을 얼마나 드물게 겪는지가 아니라, 겪을 때 불이 다시 들어오기까지 몇 분이 걸리는지를 여러 번 재서 평균을 냅니다.

이름이 가리키는 것

영어로는 MTTR 이라고 씁니다. Mean Time To Recovery 를 줄인 것입니다.

같은 네 글자를 Mean Time To Repair 로 푸는 곳도 있습니다. 이쪽은 고장 난 것을 고치는 데 든 시간을 뜻해서 서비스가 돌아온 때와 어긋날 수 있습니다. 예비 장비로 넘겨 서비스를 먼저 살리고 고장 난 장비는 다음 날 고치는 경우가 그렇습니다.

한국어 표제어는 「복구」를 씁니다. 무엇을 고쳤는지가 아니라 서비스가 돌아왔는지를 기준으로 삼는다는 뜻입니다.

시계를 켜고 끄는 때

값이 갈리는 곳은 나눗셈이 아니라 시계입니다. 같은 사고라도 어느 때에 시계를 켜느냐에 따라 시간이 크게 달라집니다.

켜는 때의 후보는 둘입니다. 고장이 시작된 때부터 재면 아무도 알아채지 못하고 흘려보낸 시간까지 들어갑니다. 고장을 알아챈 때부터 재면 알아챈 뒤의 시간만 들어갑니다.

끄는 때도 둘입니다. 서비스가 정상으로 돌아온 때에 끄면 사용자가 겪은 시간을 잽니다. 원인까지 없앤 때에 끄면 뒤처리에 든 시간도 함께 잽니다. 급한 불만 끄고 며칠 뒤에 뿌리를 뽑는 일이 흔해서 둘의 차이가 큽니다.

flowchart TD
    subgraph 켜기["시계를 켜는 두 후보"]
        A["고장이 시작된 때"] --> B["고장을 알아챈 때"]
    end
    subgraph 끄기["시계를 끄는 두 후보"]
        D["서비스가 정상으로 돌아온 때"] --> E["원인까지 없앤 때"]
    end
    B --> D

어느 쪽을 골라도 됩니다. 다만 한 번 정했으면 바꾸지 않아야 지난달과 이번 달을 견줄 수 있습니다. 기준을 적어 두지 않은 값은 오르내려도 무엇이 변한 것인지 알 수 없습니다.

계산

계산 자체는 나눗셈 한 번입니다. 정한 기간의 사고마다 복구에 걸린 시간을 더하고, 그 기간의 사고 건수로 나눕니다.

12분 + 25분 + 188분     // 합 225분
225분 ÷ 사고 3건        // 평균 75분

어느 사고까지 셀지도 기준에 들어갑니다. 사용자에게 드러나지 않은 작은 사고까지 셀지, 심각도가 일정 기준을 넘은 것만 셀지에 따라 수가 달라집니다.

재는 이유와 줄일 세 구간

고장을 아예 없애는 것은 목표가 될 수 없습니다. 장비도, 기대고 있는 바깥 서비스도 언젠가는 멎습니다. 그래서 운영은 두 축으로 나뉩니다. 얼마나 드물게 나느냐와, 나면 얼마나 빨리 돌아오느냐입니다.

앞쪽 축은 평균 고장 시간(MTBF, Mean Time Between Failures)이 맡습니다. 고장과 고장 사이가 얼마나 길었는지를 재는 값입니다. 뒤쪽 축을 이 값이 맡습니다.

가용성은 둘이 함께 정합니다. 고장이 잦아도 복구가 곧 끝나면 쓸 수 있던 시간의 몫은 그대로 남습니다.

이 값을 줄이는 일은 어디를 건드릴지가 또렷합니다. 복구에 드는 시간이 세 구간으로 나뉘고, 구간마다 손댈 곳이 다르기 때문입니다.

시간이 드는 구간	짧게 만드는 손질
고장을 알아채기까지	모니터링 · 경보
사람이 손을 대기까지	온콜 당번 편성 · 호출 규칙
손을 대고 나서 돌아오기까지	롤백 · 기능 플래그 · 런북

가운데 구간은 누가 호출을 받고 깨어나느냐에 달려 있습니다. 정해진 사람이 차례로 대기하며 호출을 받는 당번을 온콜이라고 부릅니다.

마지막 구간에 적은 셋은 손을 댄 뒤 무엇을 할지 고르는 시간을 줄입니다. 롤백은 배포한 것을 직전 판으로 되돌리는 것입니다. 기능 플래그는 배포를 통째로 되돌리지 않고 문제가 된 기능만 꺼 두는 스위치입니다. 런북은 이런 사고에는 이렇게 한다를 미리 적어 둔 문서입니다.

세 구간을 합한 것이 사고 한 건의 복구 시간입니다. 이 값이 줄지 않을 때는 「대응이 오래 걸린다」로 뭉뚱그리지 말고 어느 구간이 긴지부터 봅니다.

평균이 숨기는 것

평균은 값 여럿을 수 하나로 줄입니다. 그 과정에서 유난히 큰 값이 묻힙니다. 복구 시간은 대부분 짧고 가끔 아주 긴 값이라 그 묻힘이 특히 큽니다.

평균이 같은 두 팀을 나란히 놓으면 드러납니다.

	첫째 사고	둘째 사고	셋째 사고	평균
가 팀	70분	75분	80분	75분
나 팀	5분	5분	215분	75분

가 팀은 어떤 사고든 한 시간 남짓이면 걷어냅니다. 나 팀은 대개 몇 분이면 끝나지만 한 번은 세 시간 넘게 멎어 있었습니다. 사용자가 겪은 일은 전혀 다른데 수는 같습니다.

이 값 하나만 보지 않습니다. 사고를 시간 순으로 늘어놓고 한가운데 값인 중앙값을 같이 보거나, 오래 걸린 쪽 끝을 백분위수로 봅니다. 사고 건수도 같이 적습니다. 세 건의 평균과 서른 건의 평균은 무게가 다릅니다.

쓰는 곳과 안 쓰는 곳

한 팀이 같은 기준으로 재서 추세를 볼 때 값이 있습니다. 사후 분석에서 나온 후속 조치가 시간을 줄였는지는 이 추세로 확인합니다.

다른 팀이나 다른 서비스와 견주는 데는 쓰지 않습니다. 시계를 켜고 끄는 기준이 서로 다릅니다. 사고의 성격도 다릅니다. 결제가 멎은 한 시간과 추천 목록이 멎은 한 시간은 같은 한 시간이 아닙니다.

목표 수치로 못 박고 사람을 평가하는 데도 쓰지 않습니다. 이 값을 낮추는 가장 쉬운 길은 복구를 서두르는 것이 아니라 작은 사고를 사고로 안 세는 것이기 때문입니다. 그러면 기록만 사라지고 사고 대응은 그대로입니다.

헷갈리는 이웃 이름

가까운 이름이 셋 있습니다. 가르는 기준은 누가 정한 수인가와 무엇까지 세는가입니다.

복구 목표 시간(RTO, Recovery Time Objective)은 미리 정해 둔 약속입니다. 평균 복구 시간은 지나간 사고를 재서 나온 결과입니다. 약속이 한 시간이어도 결과는 세 시간일 수 있습니다.

DORA(DevOps Research and Assessment, 데브옵스 연구·평가)는 배포 성능을 재는 지표 묶음을 내놓은 곳입니다. 거기서 쓰는 서비스 복구 시간은 세는 대상이 좁습니다. 배포한 변경이 낸 실패에서 돌아오는 시간만 봅니다. 데이터센터 정전처럼 바깥에서 온 장애는 빼고 셉니다.

평균 고장 시간은 방향이 반대입니다. 고장과 고장 사이가 얼마나 길었는지를 잽니다. 이 값이 짧아지는 것과 그 값이 길어지는 것은 서로 다른 일이라, 하나가 나아져도 다른 하나는 그대로일 수 있습니다.

평균 복구 시간

상세

이름이 가리키는 것

시계를 켜고 끄는 때

계산

재는 이유와 줄일 세 구간

평균이 숨기는 것

쓰는 곳과 안 쓰는 곳

헷갈리는 이웃 이름

관련 항목

평균 복구 시간과 나란히 놓이는 DORA 의 배포 성능 지표

평균 복구 시간이 재고 있는 사고 대응 절차

복구를 앞당기려고 미리 깔아 두는 수단

평균 복구 시간과 짝을 이루는 신뢰성 지표

고장을 알아채는 데 쓰는 감시 수단

평균이 숨긴 것을 드러내는 통계값

복구를 미리 약속해 두는 기준

이 값을 자주 쓰는 개발 흐름