DevOps Research and Assessment(DORA) 메트릭은 DevOps 성과에 대한 근거 기반 인사이트를 제공합니다. 이 네 가지 핵심 측정값은 팀이 변경 사항을 얼마나 빠르게 전달하는지, 그리고 그 변경 사항이 프로덕션에서 얼마나 안정적으로 동작하는지 보여 줍니다. DORA 메트릭을 꾸준히 추적하면 소프트웨어 전달 과정 전반에서 개선 기회를 찾을 수 있습니다.

DORA 메트릭은 전략적 의사 결정, 이해관계자를 대상으로 한 프로세스 개선 투자의 근거 제시, 업계 벤치마크와의 성과 비교를 통한 경쟁 우위 파악에 활용합니다.

네 가지 DORA 메트릭은 DevOps의 두 가지 핵심 측면을 측정합니다.

• 속도 메트릭은 조직이 소프트웨어를 얼마나 빠르게 전달하는지 추적합니다.
  • 배포 빈도: 코드가 프로덕션에 배포되는 빈도
  • 변경 사항의 리드 타임: 코드가 프로덕션에 도달하기까지 걸리는 시간
• 안정성 메트릭은 소프트웨어의 신뢰성을 측정합니다.
  • 변경 실패율: 배포가 프로덕션 장애를 유발하는 빈도
  • 서비스 복원 시간: 장애 이후 서비스가 복구되는 속도

속도와 안정성 메트릭을 함께 보면 전달 워크플로에서 속도와 품질 사이의 균형점을 찾는 데 도움이 됩니다.

영상 설명은 DORA metrics: User analytics와 GitLab speed run: DORA metrics를 참고합니다.

배포 빈도#

배포 빈도는 지정한 기간(시간별, 일별, 주별, 월별, 연도별) 동안 프로덕션에 성공적으로 배포한 빈도입니다.

소프트웨어 리더는 배포 빈도 메트릭으로 팀이 프로덕션에 소프트웨어를 얼마나 자주 성공적으로 배포하는지, 그리고 고객 요구나 새로운 시장 기회에 얼마나 빠르게 대응할 수 있는지 파악할 수 있습니다. 배포 빈도가 높으면 피드백을 더 일찍 받고 더 빠르게 반복하여 개선 사항과 기능을 전달할 수 있습니다.

배포 빈도 계산 방법#

GitLab에서 배포 빈도는 배포 종료 시각(finished_at 속성)을 기준으로, 특정 환경에 대한 하루 평균 배포 수로 측정합니다. GitLab은 해당 일자에 완료된 배포 수로 배포 빈도를 계산합니다. 성공한 배포(Deployment.statuses = success)만 집계됩니다.

계산에는 production environment tier 또는 이름이 production/prod 인 환경이 반영됩니다. 배포 정보가 그래프에 표시되려면 해당 환경이 production 배포 티어에 속해야 합니다.

.gitlab/insights.yml 파일의 environment_tiers 파라미터에 other를 지정하면 다른 환경에 대해서도 DORA 메트릭을 구성할 수 있습니다.

배포 빈도를 개선하는 방법#

첫 단계는 그룹과 프로젝트 사이의 코드 릴리스 주기를 벤치마킹하는 것입니다. 그다음에는 다음 방안을 고려합니다.

• 자동화된 테스트 추가.
• 자동화된 코드 검증 추가.
• 변경 사항을 더 작은 단위로 분할.

변경 사항의 리드 타임#

변경 사항의 리드 타임은 코드 변경이 프로덕션에 반영되기까지 걸리는 시간입니다.

변경 사항의 리드 타임은 리드 타임과 다릅니다. 밸류 스트림 분석에서 리드 타임은 이슈에 대한 작업이 요청된 시점(이슈 생성)부터 완료되어 전달되는 시점(이슈 종료)까지 걸리는 시간을 측정합니다.

소프트웨어 리더에게 변경 사항의 리드 타임은 CI/CD 파이프라인의 효율성을 보여 주고, 작업이 고객에게 얼마나 빠르게 전달되는지 드러냅니다. 시간이 지날수록 변경 사항의 리드 타임은 줄어들고 팀의 성과는 향상되어야 합니다. 변경 사항의 리드 타임이 짧다는 것은 CI/CD 파이프라인이 더 효율적이라는 뜻입니다.

변경 사항의 리드 타임 계산 방법#

GitLab은 머지 리퀘스트를 프로덕션까지 성공적으로 전달하는 데 걸린 초 수를 기준으로 변경 사항의 리드 타임을 계산합니다. 머지 리퀘스트가 병합된 시각(병합 버튼을 누른 시점)부터 코드가 프로덕션에서 정상적으로 실행되는 시점까지이며, coding_time은 계산에 포함하지 않습니다. 데이터는 배포가 끝난 직후 약간의 지연을 두고 집계됩니다.

기본적으로 변경 사항의 리드 타임은 여러 배포 job을 가진 단일 브랜치 작업만 측정할 수 있습니다(예: 기본 브랜치에서 development, staging, production으로 이어지는 흐름). 머지 리퀘스트가 staging에서 병합된 뒤 production에서 다시 병합되면 GitLab은 이를 하나가 아니라 두 개의 배포된 머지 리퀘스트로 해석합니다.

병합 전에 완료되는 배포#

드물게 배포가 연관된 머지 리퀘스트보다 먼저 완료될 수 있습니다.

이런 상황은 다음과 같은 경우에 발생할 수 있습니다.

• 배포 절차가 병합 워크플로와 무관하게 실행되는 경우.
• 코드 리뷰가 끝나기 전에 수동 배포가 이루어지는 경우.

이 경우 GitLab은 GREATEST(0, deployment_finished_at - merge_request_merged_at) 공식을 사용합니다. GREATEST 함수는 음수 대신 0을 반환하여 리드 타임 값이 음수가 되지 않도록 합니다. 이 함수는 데이터 정합성을 유지하면서 데이터베이스 제약 조건 위반을 방지합니다.

변경 사항의 리드 타임을 개선하는 방법#

첫 단계는 그룹과 프로젝트 사이의 CI/CD 파이프라인 효율성을 벤치마킹하는 것입니다. 그다음에는 다음 방안을 고려합니다.

• 밸류 스트림 분석으로 프로세스의 병목 구간 파악.
• 변경 사항을 더 작은 단위로 분할.
• 자동화 추가.
• 파이프라인 성능 개선.

서비스 복원 시간#

서비스 복원 시간은 조직이 프로덕션 장애에서 복구하는 데 걸리는 시간입니다.

소프트웨어 리더에게 서비스 복원 시간은 조직이 프로덕션 장애에서 복구하기까지 얼마나 걸리는지 보여 줍니다. 서비스 복원 시간이 짧으면 조직은 경쟁 우위를 확보하고 사업 성과를 높이기 위해 새롭고 혁신적인 기능에 과감히 도전할 수 있습니다.

서비스 복원 시간 계산 방법#

GitLab에서 서비스 복원 시간은 인시던트가 production 환경에서 열려 있던 시간의 중앙값으로 측정합니다. GitLab은 지정한 기간에 인시던트가 production 환경에서 열려 있던 초 수를 계산합니다. 이때 다음을 전제로 합니다.

• GitLab 인시던트가 추적되고 있습니다.
• 모든 인시던트가 production 환경과 관련되어 있습니다.
• 인시던트와 배포가 엄격하게 일대일로 대응합니다. 하나의 인시던트는 하나의 production 배포에만 연결되고, 어떤 production 배포도 둘 이상의 인시던트와 연결되지 않습니다.

서비스 복원 시간을 개선하는 방법#

첫 단계는 그룹과 프로젝트 사이에서 서비스 중단과 장애에 대한 팀의 대응 및 복구를 벤치마킹하는 것입니다. 그다음에는 다음 방안을 고려합니다.

• production 환경에 대한 관측 가능성 개선.
• 대응 워크플로 개선.
• 수정 사항이 프로덕션에 더 효율적으로 반영되도록 배포 빈도와 변경 사항의 리드 타임 개선.

변경 실패율#

변경 실패율은 변경이 프로덕션 장애를 유발하는 빈도입니다.

소프트웨어 리더는 변경 실패율 메트릭으로 출시되는 코드의 품질을 파악할 수 있습니다. 변경 실패율이 높다면 배포 프로세스가 비효율적이거나 자동화된 테스트 커버리지가 부족하다는 신호일 수 있습니다.

변경 실패율 계산 방법#

GitLab에서 변경 실패율은 지정한 기간에 프로덕션 인시던트를 유발한 배포의 비율로 측정합니다. GitLab은 인시던트 수를 production 환경에 대한 배포 수로 나누어 변경 실패율을 계산합니다. 이 계산은 다음을 전제로 합니다.

• GitLab 인시던트가 추적되고 있습니다.
• 환경과 관계없이 모든 인시던트를 프로덕션 인시던트로 간주합니다.
• 변경 실패율은 주로 상위 수준의 안정성 추적에 사용되므로 하루 단위로 모든 인시던트와 배포를 합산하여 일별 비율을 산출합니다. 배포와 인시던트 사이의 구체적인 연결을 추가하는 방안은 이슈 444295에서 제안되었습니다.
• 변경 실패율은 중복 인시던트를 별개 항목으로 계산하므로 이중 집계가 발생합니다. 이슈 480920에서 더 정확한 계산 방안을 제안하고 있습니다.

예를 들어 배포가 10건(하루 1건 기준)이고 첫날 인시던트가 2건, 마지막 날 인시던트가 1건이라면 변경 실패율은 0.3입니다.

변경 실패율을 개선하는 방법#

첫 단계는 그룹과 프로젝트 사이의 품질과 안정성을 벤치마킹하는 것입니다. 그다음에는 다음 방안을 고려합니다.

• 안정성과 처리량(배포 빈도, 변경 사항의 리드 타임) 사이의 균형을 찾고 속도를 위해 품질을 희생하지 않기.
• 코드 리뷰 프로세스의 실효성 개선.
• 자동화된 테스트 추가.

DORA 사용자 정의 계산 규칙#

히스토리

• GitLab 15.4에서 dora_configuration이라는 이름의 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다. 이 기능은 실험 기능입니다.

이 기능은 실험 기능입니다. 이 기능을 테스트하는 사용자 목록에 참여하려면 권장 테스트 흐름을 참고합니다. 버그를 발견하면 여기에서 이슈를 생성합니다. 사용 사례와 피드백을 공유하려면 에픽 11490에 의견을 남깁니다.

변경 사항의 리드 타임에 대한 다중 브랜치 규칙#

기본 변경 사항의 리드 타임 계산과 달리, 이 계산 규칙은 각 작업마다 배포 job이 하나씩 있는 다중 브랜치 작업을 측정할 수 있습니다. 예를 들어 development 브랜치의 development job, staging 브랜치의 staging job, production 브랜치의 production job으로 이어지는 흐름입니다.

이 계산 규칙은 개발 흐름에 포함되는 대상 브랜치를 dora_configurations 테이블에 반영하는 방식으로 구현되었습니다. 이렇게 하면 GitLab이 해당 브랜치들을 하나로 인식하고 다른 머지 리퀘스트를 걸러 냅니다.

이 구성은 선택한 프로젝트의 일별 DORA 메트릭 계산 방식을 바꾸지만, 다른 프로젝트나 그룹, 사용자에게는 영향을 주지 않습니다.

이 기능은 프로젝트 수준 전파만 지원합니다.

이를 설정하려면 Rails 콘솔에서 다음 명령을 실행합니다.

my_project = Project.find_by_full_path('group/subgroup/project')
Dora::Configuration.create!(project: my_project, branches_for_lead_time_for_changes: ['master', 'main'])

기존 구성을 업데이트하려면 다음 명령을 실행합니다.

my_project = Project.find_by_full_path('group/subgroup/project')
record = Dora::Configuration.where(project: my_project).first
record.branches_for_lead_time_for_changes = ['development', 'staging', 'master', 'main']
record.save!

DORA 메트릭 측정#

GitLab CI/CD 파이프라인을 사용하지 않고#

배포 빈도는 일반적인 푸시 기반 배포에서 생성되는 배포 레코드를 기준으로 계산됩니다. 컨테이너 이미지가 에이전트로 GitLab에 연결된 경우처럼 풀 기반 배포에서는 이러한 배포 레코드가 생성되지 않습니다.

이러한 경우에도 DORA 메트릭을 추적하려면 배포 API로 배포 레코드를 생성할 수 있습니다. 배포 티어 변수는 배포가 아니라 환경에 지정되므로, 배포 티어가 구성된 환경 이름을 설정해야 합니다. 자세한 내용은 외부 배포 도구의 배포 추적 방법을 참고합니다.

Jira와 함께#

• 배포 빈도와 변경 사항의 리드 타임은 GitLab CI/CD와 머지 리퀘스트(MR)를 기준으로 계산되며 Jira 데이터가 필요하지 않습니다.
• 서비스 복원 시간과 변경 실패율은 계산에 GitLab 인시던트가 필요합니다. 자세한 내용은 외부 인시던트와 함께 이 메트릭을 측정하는 방법과 Jira 인시던트 리플리케이터 가이드를 참고합니다.

외부 인시던트와 함께#

인시던트 관리에 대해 서비스 복원 시간과 변경 실패율을 측정할 수 있습니다.

PagerDuty를 사용한다면 웹훅을 설정하여 각 PagerDuty 인시던트마다 GitLab 인시던트를 자동으로 생성할 수 있습니다. 이 구성은 PagerDuty와 GitLab 양쪽에서 설정을 변경해야 합니다.

다른 인시던트 관리 도구를 사용한다면 HTTP 통합을 설정하여 다음 작업을 자동화할 수 있습니다.

1. 알림이 발생할 때 인시던트 생성.
2. 복구 알림으로 인시던트 종료.

분석 기능#

DORA 메트릭은 다음 분석 기능에 표시됩니다.

• 밸류 스트림 대시보드에는 DORA 메트릭 비교 패널과 DORA 성과 점수 패널이 포함됩니다.
• CI/CD 분석 차트는 시간에 따른 DORA 메트릭의 이력을 보여 줍니다.
• 인사이트 리포트에서는 DORA 쿼리 파라미터로 사용자 정의 차트를 만들 수 있습니다.
• GraphQL API(대화형 GraphQL 탐색기 포함)와 REST API는 메트릭 데이터 조회를 지원합니다.

프로젝트 및 그룹 가용성#

다음 표는 프로젝트와 그룹에서 DORA 메트릭을 사용할 수 있는 범위를 정리한 것입니다.

데이터 집계#

다음 표는 차트별 DORA 메트릭의 데이터 집계 방식을 정리한 것입니다.