변경 실패율

배포한 변경 가운데 프로덕션에서 곧바로 손을 대야 했던 것의 비율입니다. 배포를 얼마나 자주 내보내는지를 재는 값 옆에 놓입니다. 내보낸 것이 얼마나 흔들렸는지를 보는 자리입니다.

상세

옷가게 주인이 이번 달 판 옷 가운데 몇 벌이 탈이 났는지 세어 보려 합니다. 환불로 되돌아온 옷도, 손님이 그대로 입은 채 들러 솔기만 꿰맨 옷도 있습니다. 세기 전에 먼저 정할 것은 어디까지를 탈난 옷으로 칠 것인가입니다.

변경 실패율은 배포한 것 가운데 배포 직후 즉각적인 개입이 필요했던 것의 비율입니다. DORA(DevOps Research and Assessment, 데브옵스 연구·평가)는 그 개입이 변경을 되돌리는 롤백이나 문제를 급히 없애는 핫픽스로 이어질 공산이 크다고 적습니다. DORA 는 소프트웨어 전달의 불안정성을 두 값으로 잽니다. 변경 실패율이 그중 하나입니다.

나눗셈 자체는 단순합니다. 분모는 배포 횟수입니다. 분자는 그 가운데 실패로 친 배포의 수입니다. 값이 갈리는 자리는 셈법이 아니라 무엇을 실패로 셀 것인가입니다.

flowchart TD
    A["배포한다"] --> B{"배포 직후 즉각 손을 대야 했나"}
    B -->|아니다| C["배포 수에만 든다"]
    B -->|그렇다| D["실패한 배포로 센다"]
    C --> E["실패한 배포 수 나누기 전체 배포 수"]
    D --> E

적용 단위도 정해져 있습니다. DORA 는 이 값들이 응용이나 서비스 수준에서 쓰이도록 만들어졌다고 적습니다. 성격이 크게 다른 응용끼리 견주면 잘못 읽힐 수 있다고 덧붙입니다.

배경

소프트웨어를 얼마나 자주 그리고 얼마나 빨리 내보내는지만 재면 보이지 않는 것이 있습니다. 자주 내보내려고 무엇을 태웠는지가 그 값에는 안 남습니다. 내보낸 것이 프로덕션에서 그대로 서 있었는지는 따로 재야 드러납니다.

DORA 는 전달 성능을 두 묶음으로 나눕니다. 변경의 처리량을 보이는 값들과 변경의 불안정성을 보이는 값들입니다. 둘을 함께 놓아야 팀이 자기 전달 성능을 큰 틀에서 볼 수 있다고 적습니다. 속도와 안정성이 맞바꿈이 아니라는 것이 이 연구가 되풀이해 내놓은 결과입니다. 대부분의 팀에서 두 묶음의 값이 서로 상관된 것으로 나타났다고 적습니다.

이 이름은 첫 연구에서부터 있었습니다. 2014년 첫 조사는 IT 성능을 수치로 정의하려고 변수 넷을 놓았습니다. 배포 빈도 · 변경 리드 타임 · 평균 복구 시간(mean time to recover) · 변경 실패율입니다. 그런데 그해 통계 분석에서 변경 실패율은 나머지 셋과 하나의 잠재 구성 개념을 이룰 만큼 유의하게 상관되지 않았습니다. 그래서 그해의 IT 성능 정의는 나머지 셋만으로 섰습니다. 표기는 지금도 한 자리에 고정돼 있지 않습니다. DORA 자신의 문서 안에서 change fail rate 와 change failure rate 가 함께 쓰입니다.

예시

GitLab 은 변경 실패율을 주어진 기간에 프로덕션 환경에서 인시던트를 일으킨 배포의 비율로 잽니다. 계산은 나눗셈 한 줄입니다.

변경 실패율 = 인시던트 수 / 프로덕션 환경으로 나간 배포 수

이 계산은 전제 셋 위에 섭니다. GitLab 인시던트가 추적되고 있어야 합니다. 환경과 무관하게 모든 인시던트를 프로덕션 인시던트로 봅니다. 하루 안의 인시던트와 배포는 묶여 하루치 비율로 합쳐집니다. 마지막 전제는 이 값을 주로 높은 수준의 안정성 추적에 쓰기 때문이라고 문서가 적습니다.

중복된 인시던트는 별개 항목으로 셉니다. 같은 일이 두 건으로 들어와 있으면 두 번 계산됩니다.

문서가 든 값은 이렇습니다. 하루 한 번씩 열 번 배포하고 첫날 인시던트가 둘, 마지막 날 하나면 변경 실패율은 0.3입니다.

값을 읽는 법

나온 값을 어떻게 읽는지도 같은 문서가 적습니다. 이 값으로 내보내는 코드의 품질을 들여다볼 수 있다고 적습니다. 값이 높으면 배포 과정이 비효율적이거나 자동화된 테스트 커버리지가 모자란 것일 수 있습니다.

경계

프로덕션 인시던트를 고치려고 계획에 없이 한 배포도 변경 실패율에 드는가. 아닙니다. DORA 는 그 배포를 배포 재작업률로 셉니다. 배포 재작업률은 계획에 없던 배포 가운데 프로덕션 인시던트의 결과로 일어난 것의 비율입니다. 변경 실패율이 세는 것은 배포 직후 즉각적인 개입이 필요했던 배포 자신입니다. 고치러 나간 배포는 그 개입의 결과입니다.

복구에 걸린 시간은 이 값에 안 듭니다. 그 자리는 배포 실패 복구 시간이 받습니다.

변경 실패율

상세

배경

예시

값을 읽는 법

경계

관련 항목

이 값과 함께 전달 성능을 재는 나머지 지표

이 값이 놓이는 상위 개념

이 값이 실패로 세는 사건과 그 대응

이 값이 걸친 배포 과정과 분야

이 값을 다룰 때 챙기는 원칙과 역량