DevOps Research and Assessment (DORA) 메트릭은 DevOps 성능에 대한 증거 기반 인사이트를 제공합니다. 이 네 가지 핵심 측정은 팀이 변경 사항을 얼마나 빠르게 전달하고 해당 변경 사항이 프로덕션에서 얼마나 잘 수행되는지를 보여줍니다. 일관되게 추적하면 DORA 메트릭은 소프트웨어 전달 프로세스 전반에서 개선 기회를 강조합니다.

전략적 의사 결정, 이해관계자에게 프로세스 개선 투자를 정당화하거나 팀의 성능을 업계 벤치마크와 비교하여 경쟁 우위를 파악하는 데 DORA 메트릭을 사용합니다.

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

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

속도와 안정성 메트릭에 대한 이중 초점은 리더가 전달 워크플로에서 속도와 품질 사이의 최적 균형을 찾는 데 도움이 됩니다.

동영상 설명은 DORA metrics: User analytics 및 GitLab speed run: DORA metrics를 참조하세요.

배포 빈도#

히스토리

• GitLab 16.0에서 all 및 monthly 간격에 대한 빈도 계산 공식 수정 도입.

배포 빈도는 주어진 날짜 범위(시간별, 일별, 주별, 월별 또는 연별) 동안 프로덕션에 성공적인 배포의 빈도입니다.

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

배포 빈도 계산 방법#

GitLab에서 배포 빈도는 배포의 종료 시간(finished_at 속성 기준)을 기반으로 특정 환경에 하루 평균 배포 수로 측정됩니다. GitLab은 해당 날에 완료된 배포 수에서 배포 빈도를 계산합니다. 성공적인 배포만 계산됩니다(Deployment.statuses = success).

계산은 프로덕션 environment tier 또는 production/prod라는 이름의 환경을 고려합니다. 배포 정보가 그래프에 표시되려면 환경이 프로덕션 배포 티어의 일부여야 합니다.

.gitlab/insights.yml 파일의 environment_tiers 매개변수 아래에 other를 지정하여 다른 환경에 대한 DORA 메트릭을 구성할 수 있습니다.

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

첫 번째 단계는 그룹과 프로젝트 간의 코드 릴리스 케이던스를 벤치마킹하는 것입니다. 그다음 다음을 고려해야 합니다:

• 자동화된 테스트 추가.
• 자동화된 코드 유효성 검사 추가.
• 변경 사항을 더 작은 반복으로 나누기.

변경 사항의 리드 타임#

변경 사항의 리드 타임은 코드 변경이 프로덕션에 도달하는 데 걸리는 시간입니다.

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

소프트웨어 리더에게 변경 사항의 리드 타임은 CI/CD 파이프라인의 효율성을 반영하고 작업이 고객에게 얼마나 빠르게 전달되는지를 시각화합니다. 시간이 지남에 따라 변경 사항의 리드 타임은 감소하고 팀의 성능은 향상되어야 합니다. 변경 사항의 리드 타임이 낮으면 CI/CD 파이프라인이 더 효율적임을 의미합니다.

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

GitLab은 머지 리퀘스트 병합 시간(병합 버튼 클릭 시)부터 코드가 프로덕션에서 성공적으로 실행될 때까지, coding_time을 계산에 추가하지 않고 머지 리퀘스트를 프로덕션에 성공적으로 전달하는 데 걸리는 초 수를 기반으로 변경 사항의 리드 타임을 계산합니다. 데이터는 배포가 완료된 직후 약간의 지연과 함께 집계됩니다.

기본적으로 변경 사항의 리드 타임은 여러 배포 작업을 사용하는 단일 브랜치 작업만 측정을 지원합니다(예: 기본 브랜치에서 개발에서 스테이징으로, 그리고 프로덕션으로). 머지 리퀘스트가 스테이징에서 병합된 다음 프로덕션에서 병합될 때 GitLab은 이를 하나가 아닌 두 개의 배포된 머지 리퀘스트로 해석합니다.

병합 전에 완료되는 배포#

드물게 배포가 관련 머지 리퀘스트가 병합되기 전에 완료될 수 있습니다.

이 시나리오는 다음의 경우에 발생할 수 있습니다:

• 배포 프로세스가 병합 워크플로와 독립적으로 트리거되는 경우.
• 코드 검토 완료 전에 수동 배포 개입이 발생하는 경우.

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

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

첫 번째 단계는 그룹과 프로젝트 간의 CI/CD 파이프라인 효율성을 벤치마킹하는 것입니다. 그다음 다음을 고려해야 합니다:

• 밸류 스트림 분석을 사용하여 프로세스의 병목 현상을 파악합니다.
• 변경 사항을 더 작은 반복으로 나누기.
• 자동화 추가.
• 파이프라인의 성능 개선.

서비스 복원 시간#

히스토리

• GitLab 15.1에서 도입.

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

소프트웨어 리더에게 서비스 복원 시간은 조직이 프로덕션 실패에서 복구하는 데 걸리는 시간을 반영합니다. 서비스 복원 시간이 낮으면 조직이 경쟁 우위를 창출하고 비즈니스 결과를 높이기 위해 새로운 혁신적인 기능으로 위험을 감수할 수 있음을 의미합니다.

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

GitLab에서 서비스 복원 시간은 프로덕션 환경에서 인시던트가 열려 있었던 중앙값 시간으로 측정됩니다. GitLab은 주어진 기간 동안 프로덕션 환경에서 인시던트가 열려 있었던 초 수를 계산합니다. 이는 다음을 가정합니다:

• GitLab 인시던트가 추적됩니다.
• 모든 인시던트가 프로덕션 환경과 관련됩니다.
• 인시던트와 배포는 엄격히 일대일 관계입니다. 인시던트는 하나의 프로덕션 배포에만 관련되며, 프로덕션 배포는 최대 하나의 인시던트에만 관련됩니다.

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

첫 번째 단계는 그룹과 프로젝트 간의 서비스 중단 및 중단에서 팀 응답 및 복구를 벤치마킹하는 것입니다. 그다음 다음을 고려해야 합니다:

• 프로덕션 환경에 대한 관찰 가능성 개선.
• 응답 워크플로 개선.
• 수정 사항이 더 효율적으로 프로덕션에 도달할 수 있도록 배포 빈도 및 변경 사항의 리드 타임 개선.

변경 실패율#

변경 실패율은 변경이 프로덕션에서 얼마나 자주 실패를 유발하는지입니다.

소프트웨어 리더는 변경 실패율 메트릭을 사용하여 배포되는 코드의 품질에 대한 인사이트를 얻을 수 있습니다. 높은 변경 실패율은 비효율적인 배포 프로세스 또는 불충분한 자동화 테스트 커버리지를 나타낼 수 있습니다.

변경 실패율 계산 방법#

GitLab에서 변경 실패율은 주어진 기간 동안 프로덕션에서 인시던트를 유발하는 배포의 비율로 측정됩니다. GitLab은 변경 실패율을 프로덕션 환경 배포 수로 나눈 인시던트 수로 계산합니다. 이 계산은 다음을 가정합니다:

• GitLab 인시던트가 추적됩니다.
• 모든 인시던트는 환경에 관계없이 프로덕션 인시던트입니다.
• 변경 실패율은 주로 높은 수준의 안정성 추적으로 사용되며, 이것이 주어진 날에 모든 인시던트와 배포가 결합된 일별 비율로 집계되는 이유입니다. 배포와 인시던트 간의 특정 관계를 추가하는 것은 이슈 444295에서 제안됩니다.
• 변경 실패율은 중복 인시던트를 별도의 항목으로 계산하므로 이중 계산이 발생합니다. 이슈 480920에서는 더 정확한 계산을 위한 해결책을 제안합니다.

예를 들어 첫 번째 날에 두 건의 인시던트와 마지막 날에 한 건의 인시던트가 있는 10개의 배포(하루에 하나의 배포 고려)가 있는 경우 변경 실패율은 0.3입니다.

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

첫 번째 단계는 그룹과 프로젝트 간의 품질과 안정성을 벤치마킹하는 것입니다. 그다음 다음을 고려해야 합니다:

• 안정성과 처리량(배포 빈도 및 변경 사항의 리드 타임) 사이에서 올바른 균형을 찾고 속도를 위해 품질을 희생하지 않습니다.
• 코드 검토 프로세스의 효율성 개선.
• 자동화된 테스트 추가.

DORA 사용자 정의 계산 규칙#

히스토리

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

이 기능은 실험입니다. 이 기능을 테스트하는 사용자 목록에 참여하려면 여기 제안된 테스트 흐름이 있습니다. 버그를 발견하면 여기에 이슈를 여십시오. 사용 사례와 피드백을 공유하려면 에픽 11490에 댓글을 남기십시오.

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

변경 사항의 리드 타임의 기본 계산과 달리 이 계산 규칙은 각 작업에 단일 배포 작업이 있는 다중 브랜치 작업을 측정할 수 있습니다. 예를 들어 개발 브랜치의 개발 작업에서 스테이징 브랜치의 스테이징 작업으로, 그리고 프로덕션 브랜치의 프로덕션 작업으로.

이 계산 규칙은 개발 흐름의 일부인 대상 브랜치로 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 메트릭의 데이터 집계에 대한 개요를 제공합니다.