서비스 복구 시간 뜻: 실패한 배포에서 돌아오는 시간

서비스 복구 시간은 내보낸 변경이 서비스를 망가뜨렸을 때 되살리기까지 얼마나 걸리는지를 잽니다. 소프트웨어를 내보내는 팀의 성과를 재는 지표 가운데 하나입니다. 이 지표를 만든 연구 프로그램은 2023년에 이름을 실패한 배포 복구 시간으로 바꿨습니다.

쉽고 빠른 이해

서비스 복구 시간은 배포한 변경이 서비스를 망가뜨렸을 때 다시 돌아오기까지 걸린 시간입니다. 새 버전을 올린 뒤 결제가 멎었습니다. 이전 버전으로 되돌리자 9분 만에 결제가 살아났습니다. 서비스 복구 시간은 그 9분입니다.

복구 시간을 안 재면 얼마나 자주 깨지는지만 보입니다. 깨질 때마다 몇 분 만에 돌아오는 팀과 며칠씩 멎는 팀이 같은 수로 보입니다.

도는 순서:

내보낸 뒤 바로 손을 대야 했던 배포를 골라냅니다
그 배포마다 서비스가 돌아오기까지 걸린 시간을 잽니다
정한 기간의 시간들을 중앙값 같은 한 값으로 줄입니다

대가는 시계를 언제 켜고 끌지가 정해져 있지 않다는 것입니다. 배포가 나간 때부터 재느냐 실패를 알아챈 때부터 재느냐에 따라 같은 실패도 값이 달라집니다. 도구가 다른 팀끼리는 값을 나란히 견주기 어렵습니다.

상세

정비소에서 차에 새 부품을 갈아 끼웠더니 시동이 안 걸립니다. 옛 부품을 다시 끼우든 새 부품을 손보든 차가 다시 굴러가기까지 걸린 시간을 잽니다. 길에서 못이 박혀 타이어가 터진 일은 이 시간에 안 들어갑니다.

서비스 복구 시간은 배포 하나가 실패해 바로 손을 대야 했을 때, 서비스가 다시 돌아오기까지 걸린 시간입니다. 새 버전을 올린 뒤 결제가 멎었습니다. 이전 버전으로 되돌리자 9분 만에 살아났습니다. 이 값은 그 9분입니다.

같은 횟수로 깨져도 몇 분 만에 돌아오는 팀과 며칠씩 멎는 팀은 사용자가 겪는 시간이 다릅니다. 얼마나 자주 깨지나만 세서는 이 차이가 안 보입니다. 복구 시간이 그 차이를 잽니다.

DORA(DevOps Research and Assessment)는 소프트웨어를 만들어 내보내는 팀을 여러 해 조사해 온 연구 프로그램입니다. Google Cloud 가 운영합니다. 복구 시간은 DORA 가 소프트웨어 배달 성능을 잴 때 쓰는 지표입니다.

소프트웨어 배달 성능은 변경을 얼마나 빨리, 얼마나 탈 없이 프로덕션에 내보내는지를 묶어 부르는 말입니다. 프로덕션은 사용자가 쓰는 운영 환경입니다.

이름이 둘입니다. 2023년 전까지는 서비스 복구 시간(time to restore service)이나 MTTR(mean time to recover, 평균 복구 시간)로 불렀습니다. 2023년에 정의를 좁히면서 실패한 배포 복구 시간(failed deployment recovery time)으로 바꿨습니다. 이 사전은 옛 이름을 표제어로 씁니다. 내용은 2023년에 좁힌 새 정의를 따릅니다.

세는 대상 — 바로 손을 대야 했던 배포

복구 시간이 세는 실패는 배포가 낸 실패뿐입니다. 변경을 프로덕션에 내보낸 뒤 서비스가 떨어져 바로 손을 대야 했던 배포가 대상입니다. 데이터센터 정전처럼 배포와 무관하게 멎은 시간은 세지 않습니다.

손을 대는 방법으로는 넷이 꼽힙니다.

손질	하는 일
롤백	이전 버전으로 되돌린다
핫픽스	급히 고친 것을 내보낸다
fix forward	되돌리지 않고 고친 새 버전을 앞으로 내보낸다
패치	문제 난 부분만 고쳐 덧댄다

어느 손질로 돌아왔든 서비스가 돌아오기까지가 이 값입니다. dora.dev 안내는 내보낸 변경이 작을수록 실패했을 때 되살리기도 더 쉽다고 적습니다.

세는 대상은 변경 실패율이 세는 실패와 같습니다. 변경 실패율은 내보낸 뒤 바로 손을 대야 했던 배포의 비율입니다. 변경 실패율이 얼마나 자주 깨지나를 센다면, 복구 시간은 깨진 배포에서 얼마나 걸려 돌아오나를 잽니다.

시계를 켜고 끄는 때

DORA 의 정의 한 줄은 시계를 끄는 때를 복구(recover)한 때로만 적습니다. 원인을 끝까지 찾아 없애는 일은 그 한 줄에 들어 있지 않습니다.

시계를 켜는 때는 그 한 줄에 아예 적혀 있지 않습니다. 값을 내는 도구마다 켜는 때가 다릅니다. 끄는 때도 도구마다 다르게 잡습니다.

배포가 나간 때부터 재는 도구가 있습니다. 인시던트를 연 때부터 재는 도구도 있습니다. 인시던트는 서비스가 멎거나 떨어진 사고를 가리키는 말입니다. 끄는 때는 손질을 마친 때로 보는 쪽과 인시던트·버그 보고를 닫은 때로 보는 쪽이 갈립니다. 누가 어디서 켜고 끄는지는 아래 이견 절에 모았습니다.

여러 건을 한 값으로

실패한 배포마다 복구 시간이 하나씩 나옵니다. 기간을 정해 그 시간들을 한 값으로 줄여야 지난달과 이번 달을 견줄 수 있습니다.

줄이는 방법으로는 평균과 중앙값이 있습니다. 중앙값은 값들을 크기순으로 줄 세웠을 때 한가운데 오는 값입니다. 오래 걸린 한 건이 섞이면 둘이 크게 벌어집니다.

10분 · 10분 · 3일      // 세 건의 복구 시간
평균    하루를 넘는다    // 긴 한 건이 끌어올린다
중앙값  10분

2019년 DORA 리포트는 설문 응답의 분포가 정규분포가 아니어서 중앙값을 냈다고 적었습니다. 정규분포는 평균을 가운데 두고 양쪽으로 고르게 퍼진 종 모양 분포입니다. 아래 예시 절의 계측 도구 둘도 중앙값으로 줄입니다.

배경

빨리 내보내면 그만큼 자주 깨진다는 통념이 있습니다. 이 통념을 따져 보려면 빠르기와 탈 없음을 따로 재야 합니다.

DORA 는 2015년에 지표를 두 무리로 묶었습니다. 빨리 내보내나를 보는 처리량과, 탈 없이 내보내나를 보는 안정성입니다. 복구 시간은 변경 실패율과 함께 안정성 쪽에 들어갔습니다. 이 묶음으로 잰 연구는 잘하는 팀이 두 쪽을 다 잘한다고 보고했습니다.

그때 이름은 MTTR 이나 서비스 복구 시간이었습니다. 설문은 「서비스 인시던트나 사용자에게 영향을 주는 결함이 났을 때 서비스를 되살리는 데 대개 얼마나 걸리나」를 물었습니다. 이 물음은 소프트웨어 변경이 낸 실패와 지진이 데이터센터를 멈춘 실패를 가르지 못했습니다. MTTR 의 M 이 평균(mean)인지 중앙값(median)인지도 헷갈린다는 말이 나왔습니다.

2023년 DORA 는 물음을 좁혔습니다. 「프로덕션에 낸 변경이 서비스를 떨어뜨려 핫픽스·롤백·fix forward·패치 같은 손질이 필요했을 때」 되살리는 데 얼마나 걸리나로 바꿨습니다. 이름도 실패한 배포 복구 시간으로 고쳤습니다.

근거는 가설 둘이었습니다. 하나는 말을 좁히면 비슷한 실패끼리 견줄 수 있다는 것입니다. 다른 하나는 나머지 세 배달 지표와 통계상 더 잘 맞물리리라는 것입니다.

나머지 셋은 변경 리드 타임·배포 빈도·변경 실패율입니다. 변경 리드 타임은 커밋부터 프로덕션 배포까지 걸린 시간입니다. 배포 빈도는 정한 기간의 배포 횟수입니다. 셋 모두 배포를 두고 잽니다. 옛 물음은 배포와 무관한 사고까지 물었습니다. 새 물음은 복구 시간도 배포가 낸 실패를 두고 묻게 맞췄습니다.

예시

GitLab

GitLab 은 코드 저장소와 배포 파이프라인을 함께 주는 개발 플랫폼입니다. 복구 시간을 옛 이름인 time to restore service 로 보여 줍니다. 프로덕션 환경에서 인시던트가 열려 있던 시간의 중앙값으로 잽니다. 기간 안의 인시던트마다 열려 있던 초를 셉니다. 프로젝트·그룹 화면에서는 일 단위로 보여 줍니다.

이 계산은 전제 셋을 깝니다.

인시던트를 GitLab 안에서 추적한다
모든 인시던트가 프로덕션 환경에 걸려 있다
인시던트와 배포가 하나 대 하나로 묶인다. 인시던트 하나는 프로덕션 배포 하나에만 걸린다. 프로덕션 배포 하나에는 인시던트가 많아야 하나 걸린다

셋째 전제 때문에 인시던트마다 프로덕션 배포가 하나씩 짝지어집니다.

인시던트를 바깥 도구에서 받을 수도 있습니다. PagerDuty 는 장애 경보를 받아 당번에게 알리는 서비스입니다. 웹훅을 걸면 PagerDuty 인시던트마다 GitLab 인시던트가 자동으로 생깁니다. 웹훅은 일이 생기면 정해 둔 주소로 알림을 보내는 장치입니다.

경보가 울리면 인시던트를 만들게 걸어 둘 수도 있습니다. 회복 경보가 오면 그 인시던트를 닫게 합니다. 그러면 시계는 경보가 울린 때 켜집니다. 회복 경보가 온 때 꺼집니다.

Four Keys

Four Keys 는 DORA 팀이 GitHub 에 올린 계측 프로젝트입니다. 지금은 관리되지 않습니다. Google 이 공식 지원하는 제품도 아닙니다. 실패 하나마다 그 실패를 낸 배포부터 손질까지 걸린 시간을 잽니다. 손질한 때는 그 실패에 걸린 버그·인시던트 보고를 닫은 때로 봅니다.

시각은 four_keys.incidents 표에 모읍니다.

칸	담는 값
`incident_id`	실패 인시던트의 식별자
`changes`	그 실패를 낸 배포들의 식별자 목록
`time_created`	`changes` 에 든 배포 시각 가운데 가장 이른 것
`time_resolved`	인시던트를 해결한 시각

값을 내는 쿼리입니다.

SQL

select
  # ### median time to resolve
  percentile_cont(
    timestamp_diff(time_resolved, time_created, hour), 0.5
  ) over() as med_time_to_resolve,
from four_keys.incidents
# limit to 3 months
where time_created > timestamp(date_sub(current_date(), interval 3 month))

time_created 에서 time_resolved 까지를 시간 단위로 뺍니다. 그 값들의 0.5 분위를 냅니다. 0.5 분위는 줄 세운 값들의 절반 지점, 곧 중앙값입니다. 최근 석 달 안에 생긴 인시던트만 봅니다.

DORA 리포트의 성과 구간

DORA 는 설문 응답으로 팀을 엘리트·높음·중간·낮음 네 등급으로 나눕니다. 리포트는 등급마다 응답한 복구 시간 구간을 표로 냅니다.

등급	2019	2023	2024
엘리트	한 시간 미만	한 시간 미만	한 시간 미만
높음	하루 미만	하루 미만	하루 미만
중간	하루 미만	하루에서 한 주 사이	하루 미만
낮음	한 주에서 한 달 사이	한 달에서 여섯 달 사이	한 주에서 한 달 사이

이 표는 등급마다 답한 값을 옮긴 것입니다. 복구 시간으로 등급을 가르는 기준표가 아닙니다. 리포트의 표에는 변경 리드 타임·배포 빈도·변경 실패율 열이 함께 실려 있습니다. 2019년과 2024년의 높음과 중간이 복구 시간에서는 똑같이 「하루 미만」인 것도 오타가 아닙니다. 두 등급은 복구 시간 하나로 갈리지 않습니다. 등급을 가르는 계산은 자료에 없습니다(미확인).

2019년 값은 상세에 적은 대로 응답의 중앙값입니다. 구간은 해마다 다릅니다. 같은 「중간」이어도 2023년과 2024년이 가리키는 구간이 다릅니다.

2024년 리포트는 엘리트 등급이 낮음 등급보다 실패한 배포에서 2293배 빠르게 복구한다고 보고했습니다.

경계

데이터센터 정전으로 멎었다 돌아온 시간도 이 값에 드나. 지금 정의로는 안 듭니다.

2023년 개정이 가르려던 것이 이 경우입니다. 옛 물음은 소프트웨어 변경이 낸 실패와 지진이 데이터센터를 멈춘 실패를 가르지 못했습니다. 새 정의는 프로덕션에 낸 변경이 서비스를 떨어뜨린 뒤 되살리는 시간에만 맞춥니다. 정전에는 그것을 낸 배포가 없으니 셀 대상이 아닙니다.

세는 범위를 겹쳐 그리면 이렇습니다.

flowchart TD
    subgraph S1["서비스가 멎은 사고 전체"]
        subgraph S2["복구 시간이 세는 범위"]
            A["프로덕션에 낸 변경이 서비스를 떨어뜨린 실패"]
        end
        B["데이터센터 정전·지진처럼 배포와 무관한 사고"]
    end

안쪽 상자만 셉니다. DORA 는 두 실패를 가르지 않던 예전의 time-to-restore(서비스 복구 시간)와 구별하려고 새 이름을 붙였습니다. 2023년 전 리포트의 복구 시간에는 두 실패가 섞여 있을 수 있습니다.

이견

출처마다 갈리는 것이 둘입니다. 복구 시간을 어느 무리에 두나, 그리고 시계를 언제 켜고 끄나입니다.

처리량 쪽과 안정성 쪽

DORA 는 2015년부터 2023년까지 복구 시간을 안정성 쪽에 두었습니다. 2019년 리포트는 안정성을 복구 시간과 변경 실패율로 잰다고 적었습니다. 2023년 리포트에 실린 Dave Farley 의 기고도 변경 실패율과 실패한 배포 복구 시간을 안정성 지표로 묶습니다. GitLab 의 DORA 지표 문서도 이 값을 「실패 뒤 서비스가 얼마나 빨리 회복되나」를 보는 안정성 지표로 둡니다.

2024년 리포트와 지금의 dora.dev 안내는 복구 시간을 처리량 쪽으로 옮겼습니다. 거기서 복구 시간은 변경 리드 타임·배포 빈도와 한 무리입니다.

2024년 리포트는 처리량 무리를 「평소 변경과 실패에 대응한 변경을 가리지 않고 모든 종류의 변경을 내보내는 속도」를 재는 무리로 설명합니다. 롤백·핫픽스 같은 손질도 실패에 대응해 내보내는 변경입니다. 리포트가 무리를 다시 나눈 까닭으로 든 말은 「These differences」(이런 차이들)입니다. 그 차이가 무엇인지는 자료에 없습니다(미확인).

남은 쪽은 변경 실패율과 배포 재작업률입니다. 배포 재작업률은 계획에 없이 프로덕션 인시던트 때문에 나간 배포의 비율입니다. 이쪽 무리는 배포가 뜻하지 않게 바로 추가 일을 낳을 가능성을 잽니다. 그 무리 이름을 2024년 리포트는 stability(안정성)라고 씁니다. dora.dev 안내는 instability(불안정성)라고 씁니다.

누가	복구 시간을 둔 무리	같은 무리의 이웃
DORA 2015~2023년	안정성	변경 실패율
GitLab DORA 지표 문서	안정성	변경 실패율
DORA 2024년 리포트 · dora.dev 안내	처리량	변경 리드 타임 · 배포 빈도

시계를 켜는 때와 끄는 때

정의 한 줄은 켜는 때를 적지 않습니다. 끄는 때도 「복구」라는 낱말 하나뿐입니다. 값을 내는 쪽마다 켜는 때와 끄는 때가 갈립니다.

누가	켜는 때	끄는 때
DORA 2019년 리포트	사용자에게 영향을 준 인시던트를 탐지한 때	손질을 마친 때
GitLab	프로덕션 환경에 인시던트가 열린 때	그 인시던트가 닫힌 때
Four Keys	실패를 낸 배포가 나간 때	걸린 버그·인시던트 보고를 닫은 때
dora.dev 안내 · DORA 2023·2024년 리포트	적지 않음	복구한 때

한 실패를 시간 순서로 놓고 켜는 때를 달면 이렇습니다.

flowchart TD
    A["변경을 배포함"] --> B["실패를 알아챔<br/>탐지 · 인시던트 열림"]
    B --> C["서비스가 돌아옴"]
    K1["Four Keys 가 시계를 켜는 때"] -.-> A
    K2["DORA 2019년 리포트 · GitLab 이 시계를 켜는 때"] -.-> B

첫 칸과 둘째 칸 사이가 아무도 실패를 모르고 지나간 시간입니다. 켜는 때가 이를수록 같은 실패도 값이 길게 나옵니다. Four Keys 처럼 배포가 나간 때부터 재면 그 시간까지 들어갑니다. 탐지한 때나 인시던트를 연 때부터 재면 그 시간은 빠집니다.

끄는 때도 마찬가지입니다. 손질을 마친 때나 복구한 때에서 끄는 쪽이 있습니다. 인시던트나 버그 보고를 닫은 때에서 끄는 쪽도 있습니다. 끄는 때가 늦을수록 값이 길게 나옵니다.

켜는 때나 끄는 때가 다른 값끼리는 나란히 놓고 견주기 어렵습니다. 같은 도구로 같은 기준을 지켜 잰 값끼리는 오르내림을 견줄 수 있습니다.

서비스 복구 시간

상세

세는 대상 — 바로 손을 대야 했던 배포

시계를 켜고 끄는 때

여러 건을 한 값으로

배경

예시

GitLab

Four Keys

DORA 리포트의 성과 구간

경계

이견

처리량 쪽과 안정성 쪽

시계를 켜는 때와 끄는 때

관련 항목

이 값과 한 묶음으로 보는 배달 성능 지표

실패한 배포를 되살리는 손질

복구를 앞당기려고 배포에 미리 심어 두는 수단

실패를 알아채는 데 쓰는 감시 수단

복구에 사람이 붙는 사고 대응 절차

이 값을 계산해 보여 주는 도구

이름이 헷갈리는 이웃 지표

여러 건을 한 수로 줄일 때 쓰는 통계값

이 지표를 굴리는 개발 방식