DevOps 리서치 및 평가 (DORA) 메트릭

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab 전용

DevOps Research and Assessment (DORA) 팀은 DevOps 성능을 측정하는 네 가지 메트릭을 식별했습니다. 이러한 메트릭을 사용하면 DevOps 효율성을 향상시키고 비즈니스 이해관계자에게 성능을 전달함으로써 비즈니스 결과를 가속화할 수 있습니다.

DORA에는 두 가지 주요 DevOps 영역으로 나뉜 네 가지 핵심 메트릭이 포함되어 있습니다:

소프트웨어 리더에게는 품질 메트릭과 함께 속도를 추적함으로써 품질을 희생하지 않는지 확인할 수 있습니다.

비디오 설명은 DORA 메트릭: 사용자 분석 및 GitLab 속도 런: DORA 메트릭를 참조하세요.

가치 스트림 분석에서의 DORA 메트릭

네 가지 DORA 메트릭은 가치 스트림 대시보드로 즉시 사용할 수 있습니다. 이를 통해 엔지니어링 작업을 종단 간 가치 전달의 맥락에서 시각화할 수 있습니다.

One DevOps Platform 가치 스트림 관리는 전체 소프트웨어 전달 수명주기의 시각화된 전체적인 가시성을 제공합니다. 이를 통해 팀과 관리자는 “도구 체인 부담” 없이 생산성, 품질 및 전달의 모든 측면을 이해할 수 있습니다.

배포 빈도

  • GitLab 16.0에서 all 및 monthly 간격에 대한 빈도 계산 공식 수정이 도입되었습니다.

배포 빈도는 주어진 기간에 프로덕션으로의 성공적인 배포 빈도(시간당, 매일, 매주, 매월 또는 매년)입니다.

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

배포 빈도 계산 방법

GitLab에서 배포 빈도는 주어진 환경별로 하루 평균 배포 횟수로 측정됩니다. 이는 배포의 완료 시간(마침날짜 속성)을 기반으로 합니다. GitLab은 주어진 날짜에 완료된 배포 횟수에 따라 배포 빈도를 계산합니다. 성공적인 배포(Deployment.statuses = success)만이 카운트됩니다.

계산은 프로덕션 환경 티어 또는 production/prod로 지정된 환경을 고려합니다. 해당 환경은 그래프에 해당 배포 정보가 나타나도록 프로덕션 배포 티어의 일부여야 합니다.

배포 빈도 향상 방법

첫 번째 단계는 그룹 및 프로젝트 간의 코드 릴리스 속도를 기준으로 설정하는 것입니다. 그 후 고려해야 할 사항은 다음과 같습니다:

  • 자동화된 테스트 추가.
  • 자동화된 코드 유효성 검사 추가.
  • 변경 사항을 작은 반복 단위로 분해하기.

변경의 리드 타임

변경의 리드 타임은 코드 변경이 프로덕션 환경으로 들어가는 데 걸리는 시간입니다.

변경의 리드 타임은 리드 타임과 같지 않습니다. 가치 스트림에서 리드 타임은 이슈에서 작업이 요청된 시점(이슈 생성)부터 수행되고 전달될 때까지 걸리는 시간을 측정합니다.

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

변경의 리드 타임 계산 방법

GitLab은 변경의 리드 타임을 코드가 프로덕션에서 성공적으로 실행되는데 걸리는 시간(Klik Merge 버튼이 클릭된 시점부터)으로 계산합니다. coding_time을 계산에 추가하지 않습니다. 데이터는 배포가 완료된 직후에 약간의 지연을 가지고 집계됩니다.

기본적으로 변경의 리드 타임은 기본 브랜치의 여러 배포 작업에서 한 번의 브랜치 작업만을 지원합니다(예: 기본 브랜치에서 개발에서 스테이징, 프로덕션까지). Merge Request가 스테이징에서 병합되고, 그런 다음 프로덕션에서 병합되면 GitLab은 두 번의 배포된 Merge Request로 해석하고 하나로 해석하지 않습니다.

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

첫 번째 단계는 그룹과 프로젝트 간의 CI/CD 파이프라인의 효율성을 평가하는 것입니다. 그 다음으로 고려해야 할 사항은:

  • 병목 현상을 식별하기 위해 가치 스트림 분석을 사용하는 것입니다.
  • 변경 사항을 작은 반복 단위로 분할하는 것입니다.
  • 자동화를 추가하는 것입니다.

서비스 복원 시간

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

소프트웨어 리더에게는 서비스 복원 시간이 조직이 프로덕션에서의 장애로부터 회복하는 데 걸리는 시간을 반영합니다. 낮은 서비스 복원 시간은 조직이 새로운 혁신적인 기능을 도입하여 경쟁 우위를 확보하고 비즈니스 결과를 향상시킬 수 있다는 것을 의미합니다.

서비스 복원 시간 계산 방법

GitLab에서는 서비스 복원 시간을 프로덕션 환경에서 장애가 발생한 기간의 중앙값으로 측정합니다. GitLab은 프로덕션 환경에서 장애가 발생한 기간을 초 단위로 계산합니다. 이것은 다음을 전제로 합니다.

  • GitLab 장애(GitLab incidents)가 추적되고 있다.
  • 모든 장애가 프로덕션 환경과 관련되어 있다.
  • 장애와 배포는 엄격한 일대일 관계를 갖습니다. 즉, 장애는 단 하나의 프로덕션 배포와 관련이 있으며, 어떠한 프로덕션 배포도 하나 이상의 장애와 관련이 없습니다.

서비스 복원 시간 개선 방법

첫 번째 단계는 그룹과 프로젝트 간의 팀 대응 및 서비스 중단 및 중단으로부터의 회복을 벤치마킹하는 것입니다. 그 다음으로 고려해야 할 사항은:

  • 프로덕션 환경으로의 가시성 향상.
  • 대응 워크플로우 개선.

변경 실패율

변경 실패율은 변경이 프로덕션에서 실패하는 빈도입니다.

소프트웨어 리더는 변경 실패율 지표를 사용하여 출시되는 코드의 품질에 대한 통찰력을 얻을 수 있습니다. 높은 변경 실패율은 비효율적인 배포 프로세스나 충분하지 않은 자동화된 테스트 범위를 나타낼 수 있습니다.

변경 실패율 계산 방법

GitLab에서는 변경 실패율을 특정 기간 내에 프로덕션에서 장애를 유발하는 배포의 백분율로 측정합니다. GitLab은 변경 실패율을 장애의 수를 프로덕션 환경으로의 배포 수로 나눈 것으로 계산합니다. 이 계산은 다음을 전제로 합니다.

  • GitLab 장애가 추적되고 있다.
  • 모든 장애는 환경과 관계없이 프로덕션 장애로 간주됩니다.
  • 변경 실패율은 주로 고수준 안정성 추적에 사용되며, 따라서 특정한 날에는 모든 장애 및 배포가하며 결합된 일일 비율로 집계됩니다. 특정 배포와 장애 사이의 구체적인 관계를 추가하는 것은 issue 444295에서 제안되었습니다.

예를 들어, 첫 번째 날에는 10개의 배포(하루에 한 번의 배표를 고려함) 중 2건의 장애가 발생하고, 마지막 날에는 1건의 장애가 발생한다면 변경 실패율은 0.3입니다.

변경 실패율 개선 방법

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

  • 안정성과 처리량(배포 빈도 및 변경 사항의 리드 타임) 사이의 적절한 균형을 찾고, 품질을 희생하지 않는 것입니다.
  • 코드 리뷰 프로세스의 효과성 향상.
  • 자동화된 테스트 추가.

DORA 사용자 정의 계산 규칙

Tier: Ultimate Offering: Self-managed Status: Experiment
  • GitLab 15.4에 도입되었습니다. dora_configuration라는 플래그로 기본적으로 비활성화됩니다. 이 기능은 실험입니다.

플래그: Self-managed GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 프로젝트별이나 인스턴스 전체에 이 기능을 활성화하려면 관리자가 dora_configuration이라는 기능 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab 전용에서는 이 기능을 사용할 수 없습니다.

이 기능은 실험입니다. 이 기능을 테스트하는 사용자 목록에 참여하려면, 여기에서 제안된 테스트 흐름을 따르세요. 버그를 발견하면 여기에 이슈를 오픈하세요. 귀하의 사용 사례 및 피드백을 공유하려면, epic 11490에 댓글을 남기세요.

변경 사항의 리드 타임을 위한 다중 브랜치 규칙

기본 변경 사항의 리드 타임 계산 방법과 다르게, 이 계산 규칙은 각 작업에 대해 단일 배포 작업으로 다중 브랜치 작업을 측정할 수 있도록 합니다. 예를 들어, 개발 브랜치의 개발 작업에서 스테이징 브랜치의 스테이징 작업, 프로덕션 브랜치의 프로덕션 작업으로의 작업입니다.

이 계산 규칙은 대상 브랜치가 개발 흐름의 일부임을 나타내는 dora_configurations 테이블을 업데이트함으로써 구현되었습니다. 이렇게 함으로써 GitLab은 해당 브랜치를 하나로 인식하고 다른 병합 요청을 필터링할 수 있습니다.

이 구성은 선택한 프로젝트에 대한 매일 DORA 메트릭을 계산하는 방식을 변경하지만, 다른 프로젝트, 그룹 또는 사용자에는 영향을 주지 않습니다.

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

이를 수행하려면 Rails 콘솔에서 다음 명령을 실행하세요: 

Dora::Configuration.create!(project: my_project, branches_for_lead_time_for_changes: ['master', 'main'])

DORA 메트릭 데이터 검색

DORA 데이터를 검색하려면 GraphQL 또는 REST API를 사용하세요.

다음 예제는 GraphQL API를 사용하여 특정 기간에 대한 월간 배포 빈도를 검색하는 방법을 보여줍니다: 

{
  project(fullPath: "gitlab-org/gitlab") {
    dora {
      metrics(
        metric: DEPLOYMENT_FREQUENCY
        startDate: "2023-12-01"
        endDate: "2024-02-01"
        interval: MONTHLY
      ) {
        date
        value
      }
    }
  }
}

대화형 GraphQL 탐색기로 GraphQL API 리소스를 탐색할 수 있습니다.

DORA 메트릭 측정

GitLab CI/CD 파이프라인을 사용하지 않고 DORA 메트릭 측정

배포 빈도는 전형적인 푸시 기반 배포에 대해 만들어진 배포 기록을 기반으로 계산됩니다. 이러한 배포 기록은 Container Images가 에이전트와 연결된 경우와 같이 풀 기반 배포에 대해 만들어지지 않습니다.

이러한 경우 DORA 메트릭을 추적하려면 배포 기록을 생성하여야 합니다. 배포 변수가 배포뿐 아니라 특정 환경에 대해 지정되기 때문에, 환경 이름을 설정해야 합니다. 자세한 내용은 외부 배포 도구의 배포 추적을 참조하세요.

Jira를 사용한 DORA 메트릭 측정

외부 장애와 같이 DORA 서비스 복구 시간 및 변경 실패율 측정

PagerDuty의 경우, PagerDuty 장애 당마다 GitLab 장애를 자동으로 생성하는 웹훅을 설정할 수 있습니다. 이 구성에는 PagerDuty와 GitLab에서 모두 변경해야 합니다.

기타 장애 관리 도구의 경우 HTTP 통합을 설정하고 자동으로 다음을 수행할 수 있습니다:

  1. 알림이 트리거될 때 장애를 생성.
  2. 회복 알림을 통해 장애를 자동으로 닫기.

GitLab의 DORA 메트릭

GitLab은 다음과 같은 DORA 메트릭을 지원합니다:

메트릭 레벨 API UI 차트 Comments
deployment_frequency 프로젝트 GitLab 13.7 이상 GitLab 14.8 이상 이전 API 엔드포인트는 13.10에서deprecated되었습니다.
deployment_frequency 그룹 GitLab 13.10 이상 GitLab 13.12 이상  
lead_time_for_changes 프로젝트 GitLab 13.10 이상 GitLab 13.11 이상 시간은 초 단위입니다. 집계 방법은 중앙값입니다.
lead_time_for_changes 그룹 GitLab 13.10 이상 GitLab 14.0 이상 시간은 초 단위입니다. 집계 방법은 중앙값입니다.
time_to_restore_service 프로젝트 및 그룹 GitLab 14.9 이상 GitLab 15.1 이상 시간은 일 단위입니다. 집계 방법은 중앙값입니다.
change_failure_rate 프로젝트 및 그룹 GitLab 14.10 이상 GitLab 15.2 이상 배포의 백분율입니다.

DORA 메트릭 차트

DORA 메트릭은 다음 차트에 표시됩니다:

DORA 지표 데이터 집계

아래 표는 다양한 차트에서 DORA 지표의 데이터 집계를 제공합니다.

지표 이름 측정된 값 Value Streams 대시보드의 데이터 집계 CI/CD 분석 차트의 데이터 집계 사용자 정의 인사이트 보고서의 데이터 집계
배포 빈도 성공적인 배포 횟수 월 평균 일별 일일 평균 일(기본값) 또는 월
변경 사항의 리드 타임 프로덕션으로 커밋을 성공적으로 전달하는 데 걸린 시간(초) 월 평균 일별 중간값 중간 시간 일(기본값) 또는 월
서비스 복원 시간 인시던트가 열려 있었던 시간(초) 월 평균 일별 중간값 일일 중간값 일(기본값) 또는 월
변경 실패율 프로덕션에서 인시던트를 발생시키는 배포의 백분율 월 평균 일별 중간값 실패한 배포의 백분율 일(기본값) 또는 월