• GitLab의 DORA 지표
• 배포 빈도
  • 배포 빈도 예측
  • 배포 빈도 개선 방법
• 변경 사항의 출시 시간
  • 변경 사항의 출시 시간 계산 방법
  • 변경 사항의 출시 시간 개선 방법
• 서비스 복원 시간
  • 서비스 복원 시간이 어떻게 계산됩니까
  • 서비스 복원 시간을 개선하는 방법
• 변경 실패율
  • 변경 실패율이 어떻게 계산됩니까
  • 변경 실패율을 개선하는 방법
  • Jira를 사용하여 DORA 지표 측정
  • 외부 사고를 사용하여 DORA 서비스 복원 시간 및 변경 실패율 측정
• DORA 지표의 가용성
  • DORA 지표 데이터 집계

DevOps Research and Assessment (DORA) 지표

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

DORA에는 DevOps의 두 가지 핵심 영역으로 나뉜 네 가지 주요 지표가 포함되어 있습니다.

• 배포 빈도 및 변경 사항의 출시 시간은 팀의 속도를 측정합니다.
• 변경 실패율 및 서비스 복구 시간은 안정성을 측정합니다.

소프트웨어 리더들은 품질 지표와 함께 속도를 추적하여 품질을 희생하지 않고 속도를 유지하도록 할 수 있습니다.

비디오 설명은 DORA 지표: 사용자 분석 및 GitLab 속도 런: DORA 지표을 참조하십시오.

GitLab의 DORA 지표

GitLab은 DORA 지표에 대한 다양한 분석 및 통찰을 제공하며, 이는 다음과 같은 분석 기능에서 이용할 수 있습니다:

• Value Streams 대시보드의 DORA 지표는 즉시 사용 가능하며, 경향, 패턴 및 개선 기회를 식별하는 데 도움이 됩니다.
  이러한 지표는 지표 비교 패널 및 DORA 성과 점수 패널에 표시됩니다.
• CI/CD 분석 차트의 DORA 지표는 파이프라인 성공률 및 지속 시간, 지표의 시간별 히스토리 등을 보여줍니다.
• 인사이트 보고서의 DORA 지표에서 DORA 쿼리 매개변수를 사용하여 사용자 정의 차트를 생성할 수 있습니다.
• (DORA) 주요 지표 API는 모든 지표를 포함합니다.

배포 빈도

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

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

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

배포 빈도 예측

배포 빈도 예측(이전에는 Value stream forecasting로 불림)은 통계적 예측 모델을 사용하여 생산성 지표를 예측하고 소프트웨어 개발 라이프사이클 전반에 걸친 이상 현상을 식별합니다.
이 정보는 제품 및 팀에 대한 기획 및 의사 결정을 개선하는 데 도움이 될 수 있습니다.

Value stream forecasting 개요를 시청하십시오.

배포 빈도 개선 방법

먼저, 그룹 및 프로젝트 간의 코드 릴리스 속도를 기준으로 설정해야 합니다. 다음으로 고려해야 할 사항은 다음과 같습니다:

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

변경 사항의 출시 시간

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

변경 사항의 출시 시간은 리드 타임과 동일한 것이 아닙니다. 가치 스트림에서 리드 타임은 이슈가 요청된 이후 (이슈 생성)부터 충족되고 전달될 때까지 걸리는 시간을 측정합니다.

소프트웨어 리더들에게 변경 사항의 출시 시간은 CI/CD 파이프라인의 효율성을 반영하며 작업이 고객에게 얼마나 신속하게 전달되는지 시각화합니다.
시간이 흐르면서 변경 사항의 출시 시간은 줄어들어야 하며, 팀의 성능은 증가해야 합니다. 낮은 변경 사항의 출시 시간은 보다 효율적인 CI/CD 파이프라인을 의미합니다.

변경 사항의 출시 시간 계산 방법

GitLab은 변경 사항의 출시 시간을 다음과 같이 계산합니다:
머지 요청의 머지 시간(머지 버튼을 클릭한 시점)부터 코드가 프로덕션에서 성공적으로 실행될 때까지의 시간으로, 이때 코딩 시간을 계산에 추가하지 않습니다.
데이터는 배포가 완료된 즉시 집계되며 약간의 지연이 있습니다.

기본 설정상 변경 사항의 출시 시간은 기본 브랜치에서 다중 배포 작업(예: 개발에서 스테이징으로, 스테이징에서 프로덕션으로)을 지원합니다. 개발 브랜치에서 스테이징, 그리고 프로덕션으로 머지 요청이 병합될 때, GitLab은 두 개의 배포된 머지 요청으로 해석하고 하나로 계산하지 않습니다.

변경 사항의 출시 시간 개선 방법

먼저, 그룹 및 프로젝트 간의 CI/CD 파이프라인의 효율성을 기준으로 설정해야 합니다. 다음으로 고려해야 할 사항은 다음과 같습니다:

• 프로세스에서 병목 현상을 식별하기 위해 Value Stream Analytics 사용.
• 변경 사항을 더 작은 반복으로 분할하기.
• 자동화 추가.

서비스 복원 시간

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

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

서비스 복원 시간이 어떻게 계산됩니까

GitLab에서는 서비스 복원 시간을 프로덕션 환경에서의 장애가 열려 있었던 중앙값 시간으로 측정합니다. GitLab은 주어진 시간 기간 내에 프로덕션 환경에서의 장애가 열려 있었던 시간(초)을 계산합니다. 이는 다음을 가정합니다:

• GitLab 장애가 추적됩니다.
• 모든 장애가 프로덕션 환경과 관련이 있습니다.
• 장애와 배포 간에 엄격히 일대일 관계가 있습니다. 장애는 하나의 프로덕션 배포와만 관련되며, 어떤 프로덕션 배포도 둘 이상의 장애와 관련되지 않습니다.

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

첫 번째 단계는 팀의 응답 및 서비스 중단 및 장애로부터의 복구를 벤치마킹하는 것입니다. 그 다음으로 고려해야 할 것은:

• 프로덕션 환경에 대한 관측 가능성을 향상시키기.
• 응답 워크플로우를 개선하기.

변경 실패율

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

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

변경 실패율이 어떻게 계산됩니까

GitLab에서 변경 실패율은 주어진 시간 기간 내에 프로덕션에서 장애를 일으킨 배포의 백분율로 측정됩니다. GitLab은 변경 실패율을 장애의 수를 프로덕션 환경으로의 배포 수로 나눈 백분율로 계산합니다. 이 계산은 다음을 가정합니다:

• GitLab 장애가 추적됩니다.
• 모든 장애가 환경과 관계없이 프로덕션 장애입니다.
• 변경 실패율은 주로 고수준 안정성 추적으로 사용되므로 특정 일에는 모든 장애와 배포가 결합된 하루별 비율로 집계됩니다. 특정 배포와 장애 간의 특정 관계를 추가하는 것은 issue 444295에서 제안되었습니다.

예를 들어, 하루에 2건의 장애가 발생한 첫째 날과 마지막 날에 1건의 장애가 발생한 경우, 변경 실패율은 0.3입니다.

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

먼저 품질 및 안정성을 기준으로 팀 간 및 프로젝트 간의 벤치마킹을 수행해야 합니다. 그 다음으로 고려해야 할 것은:

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

Jira를 사용하여 DORA 지표 측정

• 배포 빈도 및 변경 사항의 작업 시간은 GitLab CI/CD 및 병합 요청(MRs)을 기반으로 계산되며 Jira 데이터는 필요로 하지 않습니다.
• 서비스 복원 시간 및 변경 실패율은 계산을 위해 GitLab 사고가 필요합니다. 자세한 정보는 외부 사고를 사용하여 DORA 서비스 복원 시간 및 변경 실패율 측정 및 Jira 사고 복제기 안내서를 참조하세요.

외부 사고를 사용하여 DORA 서비스 복원 시간 및 변경 실패율 측정

PagerDuty를 사용하면 PagerDuty 사고마다 GitLab 사고를 자동으로 생성하기 위해 웹훅을 설정할 수 있습니다. 이 구성에는 PagerDuty와 GitLab에서 변경 사항을하는 것이 필요합니다.

다른 사고 관리 도구의 경우 HTTP 통합을 설정하고 자동으로 다음을 수행 할 수 있습니다.

1. 경보가 트리거 될 때 사고 생성.
2. 회복 경보를 통한 사고 닫기.

DORA 지표의 가용성

아래 표는 프로젝트 및 그룹에서 DORA 지표의 가용성을 개요로 제공합니다.

DORA 지표 데이터 집계

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